Published: 19th February
Fusing advanced threat detection technologies with deep forensic expertise, we help you join all the dots to rapidly distel threats. Our innovative solutions give you all the confidence and proactive control you need – whatever comes your way.
We’re here to help you keep your people and your reputation safe. It’s what we do for companies around the world every day.
With Cyberseer, you’re no longer on your own.
Within this threat findings report we detail some example anomalies detected in customer’s operational environments, where Cyberseer prevented or limited the damage these cyber threats can inflict. Informing customers about relevant threats as early as possible gives them the best chance to proactively address security weaknesses and take actions to prevent data loss, brand damage or system failure.
Complete the short form below to gain access to the full threat findings report.
Published: 15th February
In this report, Cyberseer reviews the issues of 2020:
During 2020, there was monumental change both within organisations and how consumers interact with these organisations. Within this paper we review how you can secure the cloud, the remote workforce (those users connecting to the cloud), how cybercrime has taken advantage of COVID-19 and the increased number of attacks on supply chain security. Complete the short form below to gain access to the full report.
Published: 6th November
The pandemic has set huge challenges for organisations worldwide. Overnight, organisations have had to rapidly transform just to function, and the demand on digital infrastructures have skyrocketed. Some organisations kept continuity by shifting business entirely online, creating demand for virtual processes and remote collaboration on a scale we have never seen.
Cyberseer have compiled some observations to consider below:
Lessons from Covid-19 have permanently changed society and to a lesser extent the way we think about cyber security. Our practices must evolve. By making the entire system easier to protect and manage, it is also much easier to recover.
By Elizabeth Gladen
Published: 10th August
Google Chronicle solves the three main security data challenges that enterprises face today. Those of scalability, visibility and cost. With a multitude of security solutions being deployed within an enterprise, the rich security telemetry data from these devices are ingested by a SIEM which should then provide a single source of truth for the enterprise.
Most SIEM’s have a pricing model based on the amount of data ingested. Although this model initially worked decades ago, the amount of event data that can be generated from services such as IaaS, PaaS, SaaS through to the rich telemetry from EDR makes this consumption model prohibitively expensive.
Existing solutions designed for terabytes don’t have the ability to scale to today’s petabyte world. With this legacy consumption model most customers have to limit the number of data sources and make do with short retention timeframes. This results in limited incident investigations as you only have limited history and visibility.
Chronicle overcomes this by allowing customers to store a year’s worth of data that is immediately searchable. When an incident occurs, you are no longer limited to searching back through a week or months’ worth of data.
You now have a year’s worth of rich security data to search through, allowing you to ingest unlimited amounts of high volume telemetry data from sources such as web proxies, EDR and firewall logs, without the need to worry about which logs to filter or drop.
It is often the case when responding to an incident it is the data you don’t have that you actually need, with Chronicle you will have this rich data immediately available.
Chronicle uses Google core infrastructure to perform searches, meaning that even though a year’s worth of data has been stored, Chronicle is able to quickly search through petabytes of data in milliseconds.
As part of the searching process, Chronicle reduces the amount of pivoting that analysts have to do as part of an investigation by stitching events together into a timeline, meaning that analysts can quickly review the information and make an informed decision.
Google Chronicle utilises the threat intelligence feeds of third parties as well as Google. Every day 25 – 40% of all internet traffic transits Googles backbone. This enables Google to gain incredible insights into the malware landscape. This information and intelligence is fed back into the platform and made available through threat detection rules using YARA-L.
As well as advanced security analytics searching, Chronicle also continuously applies this threat intel to both real time telemetry and historical telemetry. Meaning that your data can be retrospectively searched automatically for newly published IOC’s and incidents investigated quickly as most released IOC’s are often a result of historical campaigns.
Providing this unlimited scale and visibility doesn’t come at an unobtainable cost. In fact, Google Chronicle is licensed per head which means your cost is fixed no matter how much data is stored. And because it’s SaaS, there are no management costs associated with the infrastructure either.
Watch the webinar to learn more and see a demonstration >>
Published: 5th August
Burpsuite is a graphical tool for testing Web application security and vulnerabilities that can be used for penetration testing. It’s a framework which allows an adversary not only to carry out reconnaissance but also gives them the ability to intercept and manipulate traffic from a victim, meaning it can be used for a Man-in-The-Middle (MiTM) style of attack.
It comes with a heap of built-in functions and is included in the Kali Operating System. It should also be noted that not all usage of Burpsuite is a bad thing, for example, it can be legitimately used by web developers in order to test robustness of web applications. This article covers how Cyberseer implement models to detect potential use of this framework on the network.
The usage of Burpsuite can leave some key indicators of compromise (IOCs) within the network traffic. In the following scenario we’re going to take a look and see what happens when the intercept function is used against a victim’s computer. This is a common use case for Burpsuite as it offers the attacker the ability to view, edit and choose which web requests are forwarded onto the destination.
It’s possible to demonstrate its power by showing what happens when we use the intercept function on a sample login page over HTTP. In this example the victim’s PC is configured to use our machine as a proxy server, so when the victim attempts to authenticate their credentials are passed through in headers ‘user’ and ‘pwd’ and we can see this in the clear.
The introduction of HTTPS makes it a little harder, in the example above a warning was displayed on the victim’s PC similar to below. This would have required them to click through to proceed past the warning.
The introduction of HTTP Strict Transport Security (HSTS) will cause this method of intercepting traffic over HTTPS to fail. HSTS allows websites to force HTTPS connections and also dictates none of the traffic ever be sent in clear text.
When modern browsers detect a self-signed certificate on a website that uses HSTS they will close the connection because it is deemed to be insecure and can be a sign that a MiTM attack is occurring. It is a common misconception that all HTTPS sites are secure, however, the major players such as Google, Facebook etc will all enforce HSTS. Read more about HSTS here
When we analyse relevant network traffic, we can clearly see the following Burpsuite related IOCs.
Proxy headers Burpsuite on our attacker’s machine is acting as a proxy server which means when the victim makes an HTTP connection a proxy request is placed in the HTTP headers:
1556870587.8471 CiolERuBKC2hvIx00 172.17.255.11 58776 192.168.110.101 8080 — — spclient.wg.spotify.com 1 [PROXY-CONNECTION -> keep-alive] spclient.wg.spotify.com:443 0 [HOST,PROXY-CONNECTION,USER-AGENT] Spotify/1.1.0 OSX/OS X 10.14.2 [x86 8] 1.0 Connection established CONNECT 200 0
In this scenario the device does not usually connect through a proxy server meaning this is abnormal activity; this can be verified by looking at the historical logs for the device.
Using the included the proxy destination (192.168.110.101) it is possible to verify if this is normal behaviour for the environment by seeing what other devices connect to this device on the proxy port (8080). This can be achieved using the Advanced Search function in Darktrace with the following query:
@fields.dest_ip:192.168.110.101 AND @fields.dest_port:8080
A ‘scoring’ of the source IP addresses connecting to this device around this timeframe shows us which device connected the most. While there was a connection from another device the percentage figure shows us that this device makes up the majority of the connections.
Using this information we’re able to further refine the search, limiting it to that source IP address we are presented with the following graph:
The graph above is set to show week’s view and the spike shows us that these type of connections are not normal for the device – so we need to dig deeper into why this is occurring.
We mentioned earlier about Burpsuite using self-signed certificates, we can see that as well. Burpsuite is developed by PortSwigger, so looking for the default certificate included in Burpsuite we can see the following:
03/05 08:03:06×5091556870586.5859 CJF1f24MkvKZd9pp00 172.17.255.11 58775 192.168.110.101 8080 — — 1163420158 1794140158 FATGIu3olCPvv4Ss00 [email protected],CN=PortSwigger,OU=PortSwigger,O=PortSwigger,L=London,ST=London,C=GB rsa sha1WithRSAEncryption 1024 rsaEncryption [email protected],CN=PortSwigger,OU=PortSwigger,O=PortSwigger,L=London,ST=London,C=GB 65537 3 00 true
Furthermore, we can also see the untrusted certificate warning that is presented back to the client:
03/05 07:59:27notice1556870367.3719 CN71ua4450TyTbhG00 172.17.255.11 58356 192.168.110.101 8080 tcp — SSL::Invalid_Server_Cert dt-534–01–172.31.10.3 192.168.110.101 SSL certificate validation failed with (self signed certificate) 172.17.255.11 [email protected],CN=PortSwigger,OU=PortSwigger,O=PortSwigger,L=London,ST=London,C=GB 8080 950
As Burpsuite is also acting as a proxy server for HTTPS, we can see that Darktrace has identified that the attacker’s machine is now acting as a server:
03/05 07:59:31notice1556870371.5329 CWqx9SspmubsLeP00 172.17.255.11 58354 192.168.110.101 8080 tcp — ProtocolDetector::Server_Found dt-534–01–172.31.10.3 192.168.110.101 192.168.110.101: SSL server on port 8080/tcp 192.168.110.101 SSL 8080 950
From an analyst’s perspective this would immediately raise suspicions as to why a device has started serving other devices.
The Darktrace technology is constantly assessing device traffic to determine if a device is acting outside of its normal pattern of behaviour. All of the IOCs above clearly show that this device is deviating from its typical network behaviour.
Machine learning based anomaly analytics interprets this, tracks it and incorporates it into a mathematic model. When we look at the relevant timeframe in the device’s graph, the system identified the above as unusual activity for this device as it was observed making a large volume of connections over a short period of time:
Cyberseer’s analysts build custom models to detect this type of activity and push them out across our customer base. Analysts can combine factual and unusualness components in to models. The unusualness of a connection is determined through the machine learning process.
Darktrace constantly assesses connections to determine if the activity is anomalous for the device and devices similar to it. This is made available to an analyst in the form of a score for how unusual the connection is.In our initial investigation steps, we used 2 queries to determine what was normal behaviour for the device.
We could have also achieved the same results, in a single step if we looked for the unusualness score. This reduces the amount of manual triage required; it means the model can filter out connections that are normal (ie, a lower score of unusualness) which reduces the possibility for false positive breaches where the connections are legitimate.
For the example used in the post, Cyberseer analysts built a model with the following components:
• Anomalous Connections over a strength of 50%.
• Common Proxy Ports (3128, 8080, 8443).
• PortSwigger Signed Certificates.
• When a destination is first observed with “PROXY-CONNECTION” in the packet header.
• The first time “ProtocolDetector::Server_Found” is observed.
With this combination, Cyberseer were able to re-test using a different device and Darktrace placed a high priority model at the top of the threat tray.
Given the nature of Burpsuite and that is has very few reasons to be legitimately used in an organisation, analysts are able to quickly report the activity to the customer so that they can investigate the source of the activity and understand why Burpsuite is being used within the environment.
By Nathan Webb
In the wake of COVID-19 we now have new breeds of remote workers. Businesses have always had a small proportion of remote workers however, pre COVID-19 these were normally field based personnel connecting to specific corporate applications and resources via VPN.
Along with the mass migration of workers to home environments, shortfalls in corporate laptops, PC’s and tablets with which to arm the expanded remote workforce means organisations are relaxing remote working policies to allow the use of personal devices (BYOD), with varying security postures, to access a much broader set of internal corporate applications than ever before. Now, more than ever, it is essential that companies have the ability to identify malicious activity originating from their remote access channels.
The majority of organisations already had varying degrees of remote access monitoring in place. However, these organisations are finding that they have to rapidly scale up their remote access infrastructures to cater for the new normal.
Rolling out functional SaaS services and VPN connectivity quickly often introduces multiple blind spots that existing solutions weren’t designed to address. This may be a result of using new technologies or simply that the vast increase in traffic has resulted in scaling issues with existing monitoring solutions.
When scaling out infrastructure and applications we need to ensure that we have visibility into these new environments as well as have capacity within existing systems. We therefore need to review and ensure that we ingest the appropriate data sources to provide insights into these environments, as well as ensuring that we have the capacity to store the additional raw data.
Finally, it is essential that you have an efficient SOC to actively monitor and respond to an increase in alerts.
Published: 8th July
Published: 8th July
Industry Sector: Financial
Threat source: External
Cyberseer utilises machine learning models to detect a device behaving abnormally. Analysts monitoring for this activity discovered a corporate device beaconing to a newly generated domain. The suspect device was being redirected from a trusted domain to a malicious domain ‘kw9vf.ugdfftp [.] top’, which was hosting a malicious flash executable. Machine learning identified it was abnormal for this device to be redirected from other sites and also to download flash executables.
Being quickly alerted to this activity, the analyst carried out an in-depth analysis of the network traffic, the executable and timeline which then identified the infamous RIG Exploit Kit in the payload which is known to distribute an array of malicious software such as Worms, RAT’s (Remote Access Tools) and Ransomware.
Exploit Kits bundle known vulnerability exploits together so that an attacker has multiple paths to achieve their goal; these commonly include operating system vulnerabilities and applications, with Flash player being a high-risk target as it is often left in an outdated state. In this case, the user had been redirected from a legitimate looking site; luring the user that the download was legitimate.
In this incident, the download was not stopped by the organisation’s web security gateway, showing the clear advantage of machine learning compared to static rules and signatures. Cyberseer promptly identified and reported this incident to the customer and with a built timeline of events could quickly identify any other devices which could be affected.
Industry Sector: Retail
Threat Source: Internal
Using Tor within an enterprise straight away raises suspicious, furthermore can increase security risk by making a device more exposed to malicious sites. While Tor does provide anonymity for the user, the purpose of this software is to obscure the user’s communications by distributing it through multiple network nodes thus resulting in heightened amounts of traffic to obscure destinations.
As a result, Tor outbound traffic becomes obvious to an analyst when looking for known indicators, such as onion domains, ports used and certificates.
When Cyberseer analysts detected a corporate device making use of the Tor network this can an indication of a user or malicious software attempting to obfuscate the destination. In this example, Cyberseer observed onion domains present in the web traffic.
Analysts identified the purpose of the destination onion site was to access ‘dark web’ online market stores where users could buy and sell information. that the actor then used to sell stolen PII (Personal Identifiable) data.
Cyberseer analysts could also correlate this malicious activity by observing abnormal amounts of data being sent to known Tor infrastructure. With high confidence of malicious activity, Cyberseer can then alert the customer immediately and provided a comprehensive report which enabled them to contain and inspect the user and device involved.
Industry Sector: Financial
Threat Source: Internal
Cyberseer utilise tools which machine learning profiles of the devices on the network by observing their characteristics and normal behaviours. When a ‘rogue’ device/s gets added to the network, it will not conform these normal behaviours making it easier to spot. In this case, the analysts were instantly alerted to a device generating abnormal network traffic.
The device was seen making a large volume of unusual DNS requests to domains that are associated with the security assessment tool “Cobalt Strike”. Cyberseer could then formulate a timeline of how and when the anomalous activity started.
Cobalt Strike’s primary usage is to simulate adversary and ‘Red Team’ operations. The software is able to simulate the methods and tactics used by a threat actor to laterally move through a network. One of Cobalt Strikes features is the ability to communicate through the DNS protocol which remains unfiltered on the vast majority of corporate networks.
Unlike other toolsets, Cobalt strike can also use a vast array of techniques to emulate post-exploitation actions in conjunction with other tools such as Metasploit. On identification of the tool, immediately identified helping the customer to stop the tool in its tracks.
When investigating this incident, Cyberseer was able to identify the key execution characteristics of the data exfiltration, log collection and enumeration through identifying key changes in the network traffic. As soon as the threat was noticed, analysts could convey the severity of this threat to the customer.
Industry Sector: Financial
Threat Source: External
Coinhive was a cryptocurrency mining service that enables website owners to profit from their visitors. This was achieved by embedding scripts into a webpage that then instruct the browsers to execute scripts which can start the ‘cryptomining’ process.
Due to the computation power required to mine, the performance of the victim’s device can be severely impacted, despite the fact most victims often only mine a piece of the cryptocurrency. Attackers also see the opportunity to compromise a legitimate website where resulting in an unsuspecting user unknowingly contributing to the mining process.
Cyberseer analysts leverage various tools that identify rarity and anomalous characteristics within network traffic. Together with custom models, an analyst discovered a corporate device deviating from its normal behavioural pattern as it was seen making an unusual volume of external connections to a retail site.
Making use of various intel sources, the analyst was able to determine that the website had been compromised to mine the ‘Monero’ cryptocurrency. When discovered, the customer was notified of the activity and was provided with a detailed report which advised the implementation of stricter web controls of endpoints on the network, ensuring users were unable to visit the site; stopping any future infection.
Industry sector: Financial
Threat source: External
Photo-miner is a complex example of a piece of malware which can use multiple methods to propagate from device to device. The initial infection is downloaded, commonly through a compromised FTP server where the attacker has previously been able to upload malicious files. The malware then takes two routes to propagate; attacking FTP servers from the affected machine and also attempting to propagate on the local network of the compromised machine.
Why FTP? FTP not being a secure protocol using unencrypted methods to transmit username and passwords combined with weak security implementation, such as a simple password and unlimited login attempts.
When a user navigated to one of these sites, Cyberseer analysts immediately questioned why the user would need to be using this insecure protocol? After digging deeper, an analyst determined the FTP site had an obscure domain and that it was the first time this domain had been accessed within the organisation.
This was made possible down to machine learning keeping a baseline not only of that device but also for the organisation. Using this information, analysts classified objects on the site to be related to the photo-miner malware.
With an accurate classification, the analyst could then use open source intelligence to identify the methods this malware uses to propagate to other internal devices to determine if were being observed.
Furthermore, Cyberseer used this information to create meta models and raise the severity pertaining to any usage of the legacy FTP protocol.
Published 24th June 2020
The cloud provider protects the underlying infrastructure of the cloud from vulnerabilities, intrusions, fraud, and abuse, and provide its customers with adequate security capabilities.
However, it is the customer’s responsibility to ensure that they make the most of these security capabilities. Eg: In the case of AWS, it is the customer’s responsibility to enforce necessary access control policies using AWS IAM, configure Security Groups, enable CloudTrial, etc.
What about native tools?
Cloud service providers all offer their own native security tools that can easily be configured and deployed. These tools normally reside within the same console as the infrastructure services and hence the tool can be easily used.
For organisations with very minimal security aspirations, such tools works perfectly. However, for an organisation that has greater security requirements and operates in a regulated industry such tools are not effective.
Cloud providers native tools do not offer the depth of coverage that Cloud Control offers. What’s more the portability across multiple clouds is impossible meaning a separate interface and configuration per cloud provider is required. By using Cloud Control, a consistent policy can be rolled out across multiple cloud providers using a single interface.Below is a comparison between the native security tools offered by the cloud service providers and Cloud Control
Published 23rd June