This blog post outlines how Darktrace helps security operations centre (SOC) teams become more efficient by drastically cutting down the time needed to investigate incidents. This is illustrated by an example encountered in a recent Proof of Value where over 350 client devices had been infected by a stealthy banking trojan.
Identifying and investigating a compromise of this size would usually take a SOC team several hours if not days using disparate traditional security tools. Employing Darktrace, the most important questions were answered within 90 minutes. The main reason for this is that Darktrace provides full visibility and context into network activity for all devices monitored on a single, unified platform.
Alert fatigue & the cyber security skill gap
Getting cyber security right is difficult and time-consuming. Complexity is one of the main challenges the cyber security community is facing. These days, networks are only vaguely defined with digital supply chains, outsourcing, the push into the cloud and the advent of micro-virtualisation like Docker. The amount of data stored, devices connected to internal networks, connections made by devices and the heterogeneity in IT adds to this complexity. Managing it is difficult at best and securing it with traditional tools can be a daunting task.
Our industry is struggling with what has been labelled the ‘cyber security skill gap’. The demand for skilled, experienced security practitioners consistently outstrips supply. SOC teams struggle to find the right people for the job and to keep their analysts motivated in the face of a rapidly evolving threat landscape. Alert fatigue and burnout are common symptoms for SOC analysts working long hours and graveyard shifts.
Any incident responder will always begin by asking some high-level questions concerning the incident under investigation – regardless of it being an adware infection, a banking trojan, ransomware, an active intrusion or any other form of cyber security incident.
The most important questions usually are:
- How did the infection occur? (To prevent the same initial infection vector in the future)
- What behaviour is the infected device exhibiting? (To understand the threat and the risk of the infection)
- What Indicators of Compromise (IoC) are seen? (To update other security tools and to use for further investigation)
- Are other devices infected as well? (To assess the extent of the infection)
We did a recent Proof of Value with an IT service provider in EMEA. Darktrace entered an environment which had already succumbed to a widespread compromise – over 350 client devices had been infected with banking trojans. Let’s walk through how we identified, triaged and investigated this infection using Darktrace.
Identifying the incident
Darktrace came into the environment after the initial infection had taken place already. Darktrace instantly identified several devices exhibiting unexpected HTTP beaconing to unusual, rare external IP addresses. The devices made HTTP POST requests without prior GET requests along other suspicious behaviour. Darktrace created several high-severity alerts for this, e.g. ‘Compromise / Suspicious HTTP Beacons to Dotted Quad’ and ‘Compromise / Possible Malware HTTP Comms’:
Triaging the incident
Darktrace then provides context around this alert - e.g. the external IP the beaconing was made to, the internal device including the associated user, and the suspicious behaviour:
A quick investigation of the external IP reveals that it is a recently discovered command and control (C2) IP address for the Dridex banking trojan.
Drilling deeper into this, Darktrace provides PCAPs for every connection seen. A PCAP for the C2 connection above confirms this incident as active, successful, encoded beaconing to a malicious C2 IP:
Investigating the incident
At this stage, we want to further examine the behaviour of the infected device around the time of the incident. Darktrace provides full visibility into past activity, including all network connection made by any device - regardless of whether the incident occurred on the device or not.
We attend to all external connections made by the infected device around the time of the incident and immediately identify more suspicious C2 communication:
By now we have identified 6 different C2 IP addresses.
We can use Darktrace’s ‘External Sites Summary’ to view all devices that have connected to a specific IP or domain in the recent past. Doing this for the initial C2 IP yields the following result (excerpt):
We immediately identify 5 additional devices that made successful connections to the C2 IP address. In fact, the list above is abridged as we actually saw over 350 devices connecting to this and other C2 IP addresses. Notably, all observed devices appear to have a similar naming structure - this will become important in the next part of the analysis.
At this point we have answered all but the first question: ‘How did the infection occur?’
Darktrace started monitoring the network after the initial infection occurred and spread. Further research into the C2 IP addresses shows that they are associated with the Emotet trojan. This sophisticated malware often precedes banking trojan (e.g. Dridex) infections and is spread via phishing. We can thus assume that phishing was a likely initial infection vector.
How then did the infection manage to spread to so many devices?
Surely not all users clicked on suspicious phishing emails? Recent versions of Emotet have limited lateral movement capabilities. They mainly propagate via SMB brute forcing - trying administrative accounts and hard-coded password lists. The naming convention on the infected devices is very similar - this could indicate a similar build-process and setup of the devices. If a vulnerability - such as an administrative account with a weak password - existed on one of the devices, it might be present in all of the devices with a similar build.
Using Darktrace, the security team has now a solid understanding of the nature and size of the infection, the IoCs available to update firewalls and other preventive security controls and outstanding remediation-activities.
What would this investigation look like with traditional tools, not using Darktrace?
Detecting these covert banking trojans in the first place, let alone triaging them fully, can be a difficult challenge in itself. Current banking Trojan strains such as Dridex, Fedeo or Vawtrak keep updating the malware with new C2 addresses to avoid blacklisting. Initial detection could be at any stage of the attack lifecycle – likely it will be in the latter stages though, when considerable damage has already been done.
An analyst will have to log into various security devices to get close to the same level of visibility provided in Darktrace – web proxy logs, anti-virus logs, running PCAPs on infected hosts, SIEM logs. Having to switch between all those disparate security tools is not time-efficient and produces a fragmentary picture of what actually transpired.
A working hypothesis is that a single device was initially infected via phishing, allowing Emotet to spread to over 350 internal devices via SMB brute forcing. It took no longer than 90 minutes to come from an initial detection of the incident to this conclusion, which forms the basis for an actionable report.
The last thing a SOC needs is yet another tool producing a profusion of alerts. Using Darktrace’s machine learning and unrivalled network visibility, you can focus on the small set of relevant alerts and rapidly investigate those incidents according to their severity and priority.
Darktrace can reduce costs even if you bring in a third-party incident response team. You will be able to significantly speed up their ongoing investigation if they have access to Darktrace. Third-party incident response teams are expensive – their daily rates ranging between £2,000 and £3,000 per day. Cutting their work down from days to hours will result in cost and efforts saved.
Darktrace recently detected two rogue devices on the network of a major healthcare provider. They were brought onto the network by a trusted employee, who – for reasons still unknown – was attempting to harvest user credentials and profile the network’s defenses.
Darktrace’s AI algorithms had built a detailed understanding of the organization’s normal network activity and digital infrastructure. When the two new devices entered the network and sent ‘Redirect Datagram for the host’ messages to the subnet router, Darktrace identified the anomaly and raised an alert in real time. This represented the first of three anomalies:
- Two unknown Raspberry Pis are introduced to the network
Based on the MAC addresses, the newly introduced devices were determined to be two Raspberry Pis. Once on the network, they began acting like gateways, which use remote hosts to send data packets on alternative routes.
It was initially believed that the insider was using the devices to engage in ARP spoofing. However, the subnet router did not respond to the messages.
- The devices attempt to redirect users to a fake security survey
The second anomaly occurred when the devices began beaconing to a rare external endpoint, which resolved to Amazon cloud services. This activity is typically seen in attempted communications with a command-and-control center, but there was no returning inbound traffic.
Instead, the rare destination turned out to be a website, which was identical to an internal website being used to host a security survey. Before accessing the survey, employees needed to enter their user credentials.
In addition to harvesting user credentials, the survey was asking a series of questions that would have been extremely useful for an attacker. The survey included questions designed to learn the status of their anti-virus and firewalls, and whether users were using the same passwords across multiple services.
- The insider tries to hide the devices via DHCP allocation requests
The final anomaly came when one of the devices made a DHCP allocation request for an IP address on a separate subnet. It had the same hostname of the infringing device, but a new MAC address.
Essentially, the insider was attempting to hide the devices by manually changing their IP addresses through DHCP release and allocation requests.
Each of these anomalies represented a subtle deviation from the organization’s normal ‘pattern of life’. By correlating these weak indicators of threat, Darktrace was able to discover a larger pattern that revealed the whole story: a malicious insider had smuggled Raspberry Pis onto the network to lure users to a fake website, steal their credentials, and test the network’s defenses, all while remaining hidden from network defenses.
By raising alerts in real time, Darktrace helped ensure that no users fell victim to the attack. Soon after, the Pis disappeared from the network. While the culprit was never caught, the organization has yet to experience a similar threat, indicating that the insider either left the organization, or remains in hiding.
Since the incident, the healthcare provider has undergone a restructuring of its network, and they’ve adopted a host of new IoT devices. Darktrace’s algorithms are continuously learning and re-learning normal, so if the malicious insider were to re-emerge, Darktrace would immediately detect their presence on the network.
Download our 2017 Global Threat Report to learn more about the subtle threats that Darktrace finds, including an IoT fish tank that was remotely hacked by an unknown sophisticated attacker.
Earlier this year, Darktrace detected a new botnet engaged in a large-scale reflection and amplification attack targeting organizations around the world, including several governmental bodies. While covered in our 2017 Threat Report, this attack is more pertinent than ever in light of potentially new, bigger, and more sophisticated IoT hacks, in the likes of the recently reported ‘Reaper Botnet’ , we can increasingly expect to see in 2018.
This new type of botnet we detected earlier this year wasn’t using desktop computers to power its attacks – like Srizbi did when it was sending out 60 billion spam emails per day – and its methodology was distinct from Mirai – which uses DRVs and routers to generate DNS DDoS attacks with speeds of up to 1Tbps.
Instead, this new botnet was commandeering an unlikely assortment of devices made up of, among other things, IoT drawing pads. It contained far fewer devices than typical botnets, but through reflection and amplification techniques using SNMP, it was attempting to launch a powerful denial-of-service attack.
The threat began in a familiar fashion. An architectural firm introduced smart drawing into their network pads without alerting the IT team, and their internal security controls had no way of identifying the vulnerable devices. As such, the devices’ user credentials were never changed from the factory defaults.
Those credentials, along with their public string for SNMP authentication, were publicly available on Shodan, which also revealed that the devices had open ports for HTTP, HTTPS, Telnet, and SIP.
Darktrace detected the vulnerability when hundreds of external IP addresses from around the world made several thousand of SNMP connections to the devices over UDP port 161. Over 99 percent of these connections contained at least one “GetBulkRequest”, an SNMP operation used for the retrieval of large amounts of data.
In response to these requests, the devices issued an exponentially larger number of replies via “GetResponse”, some of which contained as many as 397,000 “GetResponse” objects. In 64 cases, the devices uploaded over 1MB of data.
A sample of this SNMP activity as observed by Darktrace’s AI algorithms:
Normal network activity for these devices involved very occasional use of “GetBulkRequests” and “GetResponses.” Therefore, these spikes in activity were deemed highly anomalous by Darktrace’s AI algorithms, which had built a deep understanding of normal activity for the devices. By detecting the threat in real time, the security team discovered the threat while it was still in its early stages, and Darktrace’s network visibility provided detailed analytics on the incident.
The use of SNMP version 2c and “GetBulkRequests” were telltale signs of a reflection and amplification attack, which use scant resources to generate large attacks. All told, 273.2MiB left the devices on port 161.
The external data transfers on port 80 indicated that the attack went even further, as numerous external devices were attempting to access the devices’ HTTP resources, many of which were administrative PHP files.
A sample of resources that external devices attempted to access via HTTP:
Finally, Shodan also revealed that the devices were running an accessible SIP server on port 5060. Packet analysis showed that external devices “dialed” the devices and attempted to place a VoIP – strange behavior on the attacker’s part that remains unexplained.
The target IP addresses were likely spoofed. By sending hundreds of “GetBulkRequests” from the spoofed IPs of the target networks, the IoT drawing pads were forced to send back more than 100 times the number of “GetResponses.” This is testament to the power of reflection and amplification attacks. It’s unclear what other devices were used in this attack, but even a small number of IoT devices at the architectural firm were able to generate an alarming amount of traffic.
The target IPs belonged to websites owned by entertainment and design companies, and even governmental bodies. By reporting on the anomalous SNMP requests as soon as they began, the firm’s security team was able to take the drawing pads offline before damage was done.
Had the attack succeeded in sabotaging the target networks, the firm could have been subject to legal action. The company revamped their security policies and made strides to secure all the IoT devices on their network to minimize risk of future incidents.
To learn more about how Darktrace can uniquely identify and neutralize in-progress, subtle IoT threats, don’t miss Justin Fier appear on VICELAND’s Cyberwar show tomorrow, October 31st, at 7 PM PST/10 PM EST.
This blog post describes the currently circulating ransomware called BadRabbit and how Darktrace’s machine learning technology detects it. BadRabbit is a self-propagating piece of malware that uses SMB to spread laterally. The campaign is reminiscent of the WannaCry and NotPetya attacks seen earlier this year. Some of the functionality in BadRabbit and the modus operandi of how it infects the targets is similar to the NotPetya attack.
The attack initially hit companies in Russia and Ukraine on October 24th, 2017. Since, the ransomware has spread to other countries across the world as well.
The initial infection vector appears to be via drive-by downloads and social engineering using fake Adobe Flash player files. Various news and media websites predominantly but not exclusively in Russia and Ukraine served their visitors with pop-up alerts asking them to download Adobe Flash player software updates. It is unclear at this point if the websites were compromised, or if the advertisement networks were leveraged to display the fake Adobe Flash downloads.
This technique of presenting users with fake updates, commonly Adobe Flash, containing ransomware, adware or other forms of malware, has gained traction in the last six months. The same approach is often applied to trick users into inadvisable actions, such as downloading malware when browsing TV streaming websites, or torrent websites.
Once downloaded, a user has to execute the fake Adobe Flash player with administrative credentials manually. No exploits are used to automatically execute the malware. The malware creates a scheduled task for another file upon execution. The ransomware then encrypts files on the compromised devices using a hard-coded list of file extensions using a RSA 2048 key. The criminals demand a Bitcoin payment for decrypting the files. Users are pointed to a .onion website, which has to be accessed via Tor, to pay the ransom.
BadRabbit can brute-force its way over SMB to other devices on the network using a hard-coded list of common credentials. The malware appears to contain a stripped-down version of the Mimikatz tool which is used to gather credentials on Windows machines. This is likely used to further enhance its lateral movement capabilities using SMB.
Update (October 30, 2017): As the investigation of BadRabbit capabilities continued over the weekend, new details about how BadRabbit spreads have been uncovered. BadRabbit appears to be using the EternalRomance exploit that targets CVE-2017-0145, patched by Microsoft in March 2017, to propagate within the internal network over SMB. As Darktrace’s AI does not rely on identifying individual exploits to detect breaches, this latest discovery does not affect Darktrace’s capability to identify BadRabbit infections. All of the previously identified detection capabilities still hold true.
Darktrace instantly detects BadRabbit
Darktrace has strong detection capabilities for this campaign without the use of any signatures. In fact, we alerted a number of our customers within seconds of the initial fake Flash Player download on their respective networks, and well before the extent of the campaign was publicly known.
The initial fake Adobe Flash Player download from 1dnscontrol[.]com is immediately detected as a suspicious download:
If the early signs of BadRabbit go undetected, the infected devices start brute-forcing access to other devices on the network using SMB - causing thousands of SMB session login attempts per endeavored lateral movement over port 445. This highly anomalous behavior marks a sharp departure from customers’ normal ‘pattern of life’, making BadRabbit very easy to detect for Darktrace’s machine learning technology. Within seconds, Darktrace alerted the affected organizations about this attack flagging it as ‘SMB Session Brute Force’. The below shows an ongoing lateral movement attempt from an infected device to another client device using SMB session brute-force.
Infected devices make connection attempts to one or two seemingly randomly generated IP addresses on the internet over port 445 and also port 139. Examples of these failed connection attempts are displayed below. Darktrace instantly recognized this as unusual behavior for the infected device:
Compromised devices will attempt to move laterally on the network in a search for other devices to infect. Darktrace’s AI algorithms can swiftly recognize this anomalous behavior, alerting the affected organization in real time about these ‘Unusual Internal Connections’, as well as potential ‘Network Scans’.
The below model breaches seen in Darktrace are expected in a BadRabbit infection. Please be aware that not all models listed below are expected to breach in every infection - this depends on the actual behavior observed by Darktrace.
Anomalous File / EXE from Rare External Destination
Device / SMB Session Brute Force
Unusual Activity / Unusual Internal Connections
Device / Network Scan
Unusual Activity / Sustained Unusual Activity
Anomalous Connection / Suspicious Read / Write Ratio
Compliance / Tor Usage
The Darktrace ‘Omnisearch’ and ‘Advanced Search’ features can be used to identify any connections made to the known network Indicators of Compromise:
|1dnscontrol[.]com||(hosting the fake Adobe Flash player file)|
|185.149.120[.]3||(static IP observed, victims HTTP POSTing to the IP)|
BadRabbit is a machine-speed ransomware attack that exhibits some of the functionality and infection mechanics of the WannaCry and NotPetya breaches observed earlier this year. The BadRabbit malware masks itself as an ‘Adobe Flash’ software update, tempting unsuspecting users to initiate a download. After the initial impact, the attack can spread from machine to machine without human intervention.
Darktrace’s AI algorithms are quick to detect the highly anomalous patterns of behavior that BadRabbit triggers on a network, alerting the security team in real time. We have seen BadRabbit bypass traditional security controls around the globe, demonstrating once again the futility of attempting to identify and stop threats with rules and signatures. As Darktrace’s machine learning technology doesn’t rely on any assumptions of what ‘bad’ looks like and detects unfolding attacks not by what they are but by what they do, it is very powerful at catching and stopping ransomware attacks like BadRabbit in real time.