Blog

Inside the SOC

Using Self-Learning AI to defend against zero-day and N-day attacks

Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
26
Jul 2022
26
Jul 2022
N-days are often overlooked by security teams yet often attract just as much attention as their zero-day counterpart. This blog explores both a zero-day and n-day attack on two different customer’s SonicWall VPN server and Atlassian Confluence server, respectively, detailing how Darktrace was able to detect and intervene before any irreparable damage occurred.

Key Terms:

Zero-day | A recently discovered security vulnerability in computer software that has no currently available fix or patch. Its name come from the reality that vendors have “zero days” to act and respond.

N-day | A vulnerability that emerges in computer software in which a vendor is aware and may have already issued (or are currently working on) a patch or fix. Active exploits often already exist and await abuse by nefarious actors.

Traditional security solutions often apply signature-based-detection when identifying cyber threats, helping to defend against legacy attacks but consequently missing novel ones. Therefore, security teams often lend a lot of focus to ensuring that the risk of zero-day vulnerabilities is reduced [1]. As explored in this blog, however, organizations can face just as much of a risk from n-day attacks, since they invite the most attention from malicious actors [2]. This is due in part to the reduced complexity, cost and time invested in researching and finding new exploits compared with that found when attackers exploit zero-days. 

This blog will examine both a zero-day and n-day attack that two different Darktrace customers faced in the fall of 2021. This will include the activity Darktrace detected, along with the steps taken by Darktrace/Network to intervene. It will then compare the incidents, discuss the possible dangers of third-party integrations, and assess the deprecation of legacy security tools.

Revisiting zero-day attacks 

Zero-days are among the greatest concerns security teams face in the era of modern technology and networking. Defending critical systems from zero-day compromises is a task most legacy security solutions are often unable to handle. Due to the complexity of uncovering new security flaws and developing elaborate code that can exploit them, these attacks are often carried out by funded or experienced groups such as nation-state actors and APTs. One of history’s most prolific zero-days, ‘Stuxnet’, sent security teams worldwide into a global panic in 2010. This involved a widespread attack on Iranian nuclear infrastructure and was widely accepted to be a result of nation-state actors [3]. The Stuxnet worm took advantage of four zero-day exploits, compromising over 200,000 devices and physically damaging around 10% of the 9,000 critical centrifuges at the Natanz nuclear site. 

More recently, 2021 saw the emergence of several critical zero-day vulnerabilities within SonicWall’s product suite [4]. SonicWall is a security hardware manufacturer that provides hardware firewall devices, unified threat management, VPN gateways and network security solutions. Some of these vulnerabilities lie within their Secure Mobile Access (SMA) 100 series (for example, CVE-2019-7481, CVE-2021-20016 and CVE-2021-20038 to name a few). These directly affected VPN devices and often allowed attackers easy remote access to company devices. CVE-2021-20016 in particular incorporates an SQL-Injection vulnerability within SonicWall’s SSL VPN SMA 100 product line [5]. If exploited, this defect would allow an unauthenticated remote attacker to perform their own malicious SQL query in order to access usernames, passwords and other session related information. 

The N-day underdog

The shadow cast by zero-day attacks often shrouds that of n-day attacks. N-days, however, often pose an equal - if not greater - risk to the majority of organizations, particularly those in industrial sectors. Since these vulnerabilities have fixes available, all of the hard work around research is already done; malicious actors only need to view proof of concepts (POCs) or, if proficient in coding, reverse-engineer software to reveal code-changes (binary diffing) in order to exploit these security flaws in the wild. These vulnerabilities are typically attributed to opportunistic hackers and script-kiddies, where little research or heavy lifting is required.  

August 2021 gave rise to a critical vulnerability in Atlassian Confluence servers, namely CVE-2021-26084 [6]. Confluence is a widely used collaboration wiki tool and knowledge-sharing platform. As introduced and discussed a few months ago in a previous Darktrace blog, this vulnerability allows attackers to remotely execute code on internet-facing servers after exploiting injection vulnerabilities in Object-Graph Navigation Language (OGNL). Whilst Confluence had patches and fixes available to users, attackers still jumped on this opportunity and began scanning the internet for signs of critical devices serving this outdated software [7]. Once identified, they would  exploit the vulnerability, often installing crypto mining software onto the device. More recently, Darktrace explored a new vulnerability (CVE-2022-26134), disclosed midway through 2022, that affected Confluence servers and data centers using similar techniques to that found in CVE-2021-26084 [8]. 

SonicWall in the wild – 1. Zero-day attack

At the beginning of August 2021, Darktrace prevented an attack from taking place within a European automotive customer’s environment (Figure 1). The attack targeted a vulnerable internet-facing SonicWall VPN server, and while the attacker’s motive remains unclear, similar historic events suggest that they intended to perform ransomware encryption or data exfiltration. 

Figure 1: Timeline of the SonicWall attack 

Darktrace was unable to confirm the definite tactics, techniques and procedures (TTPs) used by the attacker to compromise the customer’s environment, as the device was compromised before Darktrace installation and coverage. However, from looking at recently disclosed SonicWall VPN vulnerabilities and patterns of behaviour, it is likely CVE-2021-20016 played a part. At some point after this initial infection, it is also believed the device was able to move laterally to a domain controller (DC) using administrative credentials; it was this server that then initiated the anomalous activity that Darktrace detected and alerted on. 

On August 5th 2021 , Darktrace observed this compromised domain controller engaging in unusual ICMP scanning - a protocol used to discover active devices within an environment and create a map of an organization’s network topology. Shortly after, the infected server began scanning devices for open RDP ports and enumerating SMB shares using unorthodox methods. SMB delete and HTTP requests (over port 445 and 80 respectively) were made for files named delete.me in the root directory of numerous network shares using the user agent Microsoft WebDAV. However, no such files appeared to exist within the environment. This may have been the result of an attacker probing devices in the network in an effort to see their responses and gather information on properties and vulnerabilities they could later exploit. 

Soon the infected DC began establishing RDP tunnels back to the VPN server and making requests to an internal DNS server for multiple endpoints relating to exploit kits, likely in an effort to strengthen the attacker’s foothold within the environment. Some of the endpoints requested relate to:

-       EternalBlue vulnerability 

-       Petit Potam NTLM hash attack tool

-       Unusual GitHub repositories

-       Unusual Python repositories  

The DC made outgoing NTLM requests to other internal devices, implying the successful installation of Petit Potam exploitation tools. The server then began performing NTLM reconnaissance, making over 1,000 successful logins under ‘Administrator’ to several other internal devices. Around the same time, the device was also seen making anonymous SMBv1 logins to numerous internal devices, (possibly symptomatic of the attacker probing machines for EternalBlue vulnerabilities). 

Interestingly, the device also made numerous failed authentication attempts using a spoofed credential for one of the organization’s security managers. This was likely in an attempt to hide themselves using ‘Living off the Land’ (LotL) techniques. However, whilst the attacker clearly did their research on the company, they failed to acknowledge the typical naming convention used for credentials within the environment. This ultimately backfired and made the compromise more obvious and unusual. 

In the morning of the following day, the initially compromised VPN server began conducting further reconnaissance, engaging in similar activity to that observed by the domain controller. Until now, the customer had set Darktrace RESPOND to run in human confirmation mode, meaning interventions were not made autonomously but required confirmation by a member of the internal security team. However, thanks to Proactive Threat Notifications (PTNs) delivered by Darktrace’s dedicated SOC team, the customer was made immediately aware of this unusual behaviour, allowing them to apply manual Darktrace RESPOND blocks to all outgoing connections (Figure 2). This gave the security team enough time to respond and remediate before serious damage could be done.

Figure 2: Darktrace RESPOND model breach showing the manually applied “Quarantine Device” action taken against the compromised VPN server. This screenshot displays the UI from Darktrace version 5.1

Confluence in the wild – 2. N-day attack

Towards the end of 2021, Darktrace saw a European broadcasting customer leave an Atlassian Confluence internet-facing server unpatched and vulnerable to crypto-mining malware using CVE-2021-26084. Thanks to Darktrace, this attack was entirely immobilized within only a few hours of the initial infection, protecting the organization from damage (Figure 3). 

Figure 3: Timeline of the Confluence attack

On midday on September 1st 2021, an unpatched Confluence server was seen receiving SSL connections over port 443 from a suspicious new endpoint, 178.238.226[.]127.  The connections were encrypted, meaning Darktrace was unable to view the contents and ascertain what requests were being made. However, with the disclosure of CVE-2021-26084 just 7 days prior to this activity, it is likely that the TTPs used involved injecting OGNL expressions to Confluence server memory; allowing the attacker to remotely execute code on the vulnerable server.

Immediately after successful exploitation of the Confluence server, the infected device was observed making outgoing HTTP GET requests to several external endpoints using a new user agent (curl/7.61.1). Curl was used to silently download and configure multiple suspicious files relating to XMRig cryptocurrency miner, including ld.sh, XMRig and config.json. Subsequent outgoing connections were then made to europe.randomx-hub.miningpoolhub[.]com · 172.105.210[.]117 using the JSON-RPC protocol, seen alongside the mining credential maillocal.confluence (Figure 4). Only 3 seconds after initial compromise, the infected device began attempting to mine cryptocurrency using the Minergate protocol but was instantly and autonomously blocked by Darktrace RESPOND. This prevented the server from abusing system resources and generating profits for the attacker.

Figure 4: A graph showing the frequency of external connections using the JSON-RPC protocol made by the breach device over a 48-hour window. The orange-red dots represent models that breached as a result of this activity, demonstrating the “waterfall” effect commonly seen when a device suffers a compromise. This screenshot displays the UI from Darktrace version 5.1

In the afternoon, the malware persisted with its infection. The compromised server began making successive HTTP GET requests to a new rare endpoint 195.19.192[.]28 using the same curl user agent (Figures 5 & 6). These requests were for executable and dynamic library files associated with Kinsing malware (but fortunately were also blocked by Darktrace RESPOND). Kinsing is a malware strain found in numerous attack campaigns which is often associated with crypto-jacking, and has appeared in previous Darktrace blogs [9].

Figure 5: Cyber AI Analyst summarising the unusual download of Kinsing software using the new curl user agent. This screenshot displays the UI from Darktrace version 5.1

The attacker then began making HTTP POST requests to an IP 185.154.53[.]140, using the same curl user agent; likely a method for the attacker to maintain persistence within the network and establish a foothold using its C2 infrastructure. The Confluence server was then again seen attempting to mine cryptocurrency using the Minergate protocol. It made outgoing JSON-RPC connections to a different new endpoint, 45.129.2[.]107, using the following mining credential: ‘42J8CF9sQoP9pMbvtcLgTxdA2KN4ZMUVWJk6HJDWzixDLmU2Ar47PUNS5XHv4Kmfdh8aA9fbZmKHwfmFo8Wup8YtS5Kdqh2’. This was once again blocked by Darktrace RESPOND (Figure 7). 

Figure 6: VirusTotal showing the unusualness of one of these external IPs [10]
Figure 7: Log data showing the action taken by Darktrace RESPOND in response to the device breaching the “Crypto Currency Mining Activity” model. This screenshot displays the UI from Darktrace version 5.1

The final activity seen from this device involved the download of additional shell scripts over HTTP associated with Kinsing, namely spre.sh and unk.sh, from 194.38.20[.]199 and 195.3.146[.]118 respectively (Figure 8). A new user agent (Wget/1.19.5 (linux-gnu)) was used when connecting to the latter endpoint, which also began concurrently initiating repeated connections indicative of C2 beaconing. These scripts help to spread the Kinsing malware laterally within the environment and may have been the attacker's last ditch efforts at furthering their compromise before Darktrace RESPOND blocked all connections from the infected Confluence server [11]. With Darktrace RESPOND's successful actions, the customer’s security team were then able to perform their own response and remediation. 

Figure 8: Cyber AI Analyst revealing the last ditch efforts made by the threat actor to download further malicious software. This screenshot displays the UI from Darktrace version 5.1

Darktrace Coverage: N- vs Zero-days

In the SonicWall case the attacker was unable to achieve their actions on objectives (thanks to Darktrace's intervention). However, this incident displayed tactics of a more stealthy and sophisticated attacker - they had an exploited machine but waited for the right moment to execute their malicious code and initiate a full compromise. Due to the lack of visibility over attacker motive, it is difficult to deduce what type of actor led to this intrusion. However, with the disclosure of a zero-day vulnerability (CVE-2021-20016) not long before this attack, along with a seemingly dormant initially compromised device, it is highly possible that it was carried out by a sophisticated cyber criminal or gang. 

On the other hand, the Confluence case engaged in a slightly more noisy approach; it dropped crypto mining malware on vulnerable devices in the hope that the target’s security team did not maintain visibility over their network or would merely turn a blind eye. The files downloaded and credentials observed alongside the mining activity heavily imply the use of Kinsing malware [11]. Since this vulnerability (CVE-2021-26084) emerged as an n-day attack with likely easily accessible POCs, as well as there being a lack of LotL techniques and the motive being long term monetary gain, it is possible this attack was conducted by a less sophisticated or amateur actor (script-kiddie); one that opportunistically exploits known vulnerabilities in internet-facing devices in order to make a quick profit [12].

Whilst Darktrace RESPOND was enabled in human confirmation mode only during the start of the SonicWall attack, Darktrace’s Cyber AI Analyst still offered invaluable insight into the unusual activity associated with the infected machines during both the Confluence and SonicWall compromises. SOC analysts were able to see these uncharacteristic behaviours and escalate the incident through Darktrace’s PTN and ATE services. Analysts then worked through these tickets with the customers, providing support and guidance and, in the SonicWall case, quickly helping to configure Darktrace RESPOND. In both scenarios, Darktrace RESPOND was able to block abnormal connections and enforce a device’s pattern of life, affording the security team enough time to isolate the infected machines and prevent further threats such as ransomware detonation or data exfiltration. 

Concluding thoughts and dangers of third-party integrations 

Organizations with internet-facing devices will inevitably suffer opportunistic zero-day and n-day attacks. While little can be done to remove the risk of zero-days entirely, ensuring that organizations keep their systems up to date will at the very least help prevent opportunistic and script-kiddies from exploiting n-day vulnerabilities.  

However, it is often not always possible for organizations to keep their systems up to date, especially for those who require continuous availability. This may also pose issues for organizations that rely on, and put their trust in, third party integrations such as those explored in this blog (Confluence and SonicWall), as enforcing secure software is almost entirely out of their hands. Moreover, with the rising prevalence of remote working, it is essential now more than ever that organizations ensure their VPN devices are shielded from external threats, guidance on which has been released by the NSA/CISA [13].

These two case studies have shown that whilst organizations can configure their networks and firewalls to help identify known indicators of compromise (IoC), this ‘rearview mirror’ approach will not account for, or protect against, any new and undisclosed IoCs. With the aid of Self-Learning AI and anomaly detection, Darktrace can detect the slightest deviation from a device’s normal pattern of life and respond autonomously without the need for rules and signatures. This allows for the disruption and prevention of known and novel attacks before irreparable damage is caused- reassuring security teams that their digital estates are secure. 

Thanks to Paul Jennings for his contributions to this blog.

Appendices: SonicWall (Zero-day)

Darktrace model detections

·      AIA / Suspicious Chain of Administrative Credentials

·      Anomalous Connection / Active Remote Desktop Tunnel

·      Anomalous Connection / SMB Enumeration

·      Anomalous Connection / Unusual Internal Remote Desktop

·      Compliance / High Priority Compliance Model Breach

·      Compliance / Outgoing NTLM Request from DC

·      Device / Anomalous RDP Followed By Multiple Model Breaches

·      Device / Anomalous SMB Followed By Multiple Model Breaches

·      Device / ICMP Address Scan

·      Device / Large Number of Model Breaches

·      Device / Large Number of Model Breaches from Critical Network Device

·      Device / Multiple Lateral Movement Model Breaches (PTN/Enhanced Monitoring model)

·      Device / Network Scan

·      Device / Possible SMB/NTLM Reconnaissance

·      Device / RDP Scan

·      Device / Reverse DNS Sweep

·      Device / SMB Session Bruteforce

·      Device / Suspicious Network Scan Activity (PTN/Enhanced Monitoring model)

·      Unusual Activity / Possible RPC Recon Activity

Darktrace RESPOND (Antigena) actions (as displayed in example)

·      Antigena / Network / Manual / Quarantine Device

MITRE ATT&CK Techniques Observed
IoCs

Appendices: Confluence (N-day)

Darktrace model detections

·      Anomalous Connection / New User Agent to IP Without Hostname

·      Anomalous Connection / Posting HTTP to IP Without Hostname

·      Anomalous File / EXE from Rare External Location

·      Anomalous File / Script from Rare Location

·      Compliance / Crypto Currency Mining Activity

·      Compromise / High Priority Crypto Currency Mining (PTN/Enhanced Monitoring model)

·      Device / Initial Breach Chain Compromise (PTN/Enhanced Monitoring model)

·      Device / Internet Facing Device with High Priority Alert

·      Device / New User Agent

Darktrace RESPOND (Antigena) actions (displayed in example)

·      Antigena / Network / Compliance / Antigena Crypto Currency Mining Block

·      Antigena / Network / External Threat / Antigena File then New Outbound Block

·      Antigena / Network / External Threat / Antigena Suspicious Activity Block

·      Antigena / Network / External Threat / Antigena Suspicious File Block

·      Antigena / Network / Significant Anomaly / Antigena Block Enhanced Monitoring

MITRE ATT&CK Techniques Observed
IOCs

References:

[1] https://securitybrief.asia/story/why-preventing-zero-day-attacks-is-crucial-for-businesses

[2] https://electricenergyonline.com/energy/magazine/1150/article/Security-Sessions-More-Dangerous-Than-Zero-Days-The-N-Day-Threat.htm

[3] https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/

[4] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=SonicWall+2021 

[5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20016

[6] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-26084

[7] https://www.zdnet.com/article/us-cybercom-says-mass-exploitation-of-atlassian-confluence-vulnerability-ongoing-and-expected-to-accelerate/

[8] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26134

[9] https://attack.mitre.org/software/S0599/

[10] https://www.virustotal.com/gui/ip-address/195.19.192.28/detection 

[11] https://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/

[12] https://github.com/alt3kx/CVE-2021-26084_PoC

[13] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/2791320/nsa-cisa-release-guidance-on-selecting-and-hardening-remote-access-vpns/

INSIDE THE SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
AUTHOR
ABOUT ThE AUTHOR
Lewis Morgan
Cyber Analyst
Book a 1-1 meeting with one of our experts
share this article
USE CASES
PRODUCT SPOTLIGHT
No items found.

More in this series

No items found.

Blog

Cloud

Securing the cloud: Using business context to improve visibility and prioritize cyber risk

Default blog imageDefault blog image
26
Mar 2024

Why are businesses shifting to the cloud?

Businesses are increasingly migrating to cloud, due to its potential to streamline operations, reduce costs, and enhance scalability and flexibility. By shifting their infrastructure to the cloud, either as a whole or, more commonly in a hybrid model, organizations can access a wide array of services, such as storage, compute and software applications, without the need for extensive on-premises hardware. However, this transition isn't without challenges.  

Security challenges of cloud migration

Data security, compliance, integration with existing systems, and ensuring consistent performance are critical concerns that need to be addressed. Therefore, companies must develop robust oversight, implement comprehensive security measures, and invest in staff training to successfully navigate the transition to the cloud all while minimizing potential disruptions.

Implementing security measures within a company, however, is a complex endeavour that involves coordination among numerous internal stakeholders two of the most pivotal players involved in cloud security investment, are the security team, entrusted with crafting a business's defensive strategy, and the DevOps engineering team, architects of the infrastructure underpinning the organization's business operations.

Key questions to ask when securing the cloud

Which team is responsible for maintaining the application?  

What do they consider normal?  

How are potential misconfigurations increasing the potential risk of an incident?

Best practices of cloud security

Contextual awareness of the business is a crucial facet for securing a company's cloud infrastructure, as it enables organizations to align security measures with specific business objectives, risks, and regulatory requirements. Understanding the context of the business operations, its goals, critical assets, and compliance obligations, allows security teams to tailor their strategies and controls accordingly.

How does Darktrace help secure the cloud?

In response to the difficulties outlined above, Darktrace has adopted a holistic approach to security with an ActiveAI security platform that is context-aware. This platform enables stakeholders to effectively detect and respond to threats that may arise within their cloud or on premises environments.  

By monitoring your network and identity activity, Darktrace can identify what is considered “normal” within your organization. This however doesn’t tell the whole story. It is also important to understand where these actions are occurring within the context of the business.  

Visibility in the cloud

Without visibility into the individual assets that make up the cloud environment, how these are configured, and how they operate at run time, security is incredibly difficult to maintain. Visibility allows security teams to identify potential vulnerabilities, misconfigurations, or unauthorized access points that could be exploited by malicious actors. It enables proactive monitoring and rapid response to security incidents, ensuring that any threats are promptly identified and mitigated before they can cause significant damage.  

Building architecture diagrams

The cornerstone of our strategy lies in the architecture diagrams, which serve as a framework for organizing resources within our cloud environment. An architecture comprises of interconnected resources governed by access controls and network routing mechanisms. Its purpose is to logically group these resources into the applications they support.  

Achieving this involves compiling a comprehensive inventory of the cloud environment, analyzing resource permissions—including both outbound and inbound access—and considering any overarching organizational policies. For networked devices, we delve into route tables, firewalls, and subnet access control policies. This information is then utilized to build a graph of interconnected assets, wherein each resource constitutes a node, and the possible connections between resources are represented as edges.

Once we have built up an inventory of all the resources within your environments, we can then start building architectures based on the graph. We do this by selecting distinct starting points for graph traversal, which we infer from our deep understanding of the cloud, an example would be a Virtual Private Cloud (VPC) - A VPC is a virtual network that closely resembles a traditional network that you'd operate in your own data center.  

All networked devices are usually housed within a VPC, with applications typically grouped into one or more VPCs. If multiple VPCs are detected with peering connections between them, we consider them as distinct parts of the same system. This approach enables us to comprehend applications across regions and accounts, rather than solely from the isolated viewpoint of a single VPC.

However, the cloud isn’t all about compute instances, serverless is a popular architecture. In fact, for many developers serverless architectures offer greater scalability and flexibility. Reviewing prevalent serverless architecture patterns, we've chosen some common fundamental resources as our starting point, Lambda functions and Elastic Container Service (ECS) clusters are prime examples, serving as crucial components in various serverless systems with distinct yet similar characteristics.

Prioritize risk in the cloud

Once we have built up an inventory of all the cloud asset, Darktrace/Cloud utilizes an ‘outlier’ detection machine learning model. This looks to categorize all the assets and identifies the ones that look different or ‘odd’ when compared with the assets around it, this is based on a wide range of characteristics some of which will include, Name, VPC ID, Host Region etc, whilst also incorporating contextual knowledge of where these assets are found, and how they fit into the architecture they are in.  

Once outliers are identified, we can use this information to assess the potential risk posed by the asset. Context plays a crucial role in this stage, as incorporating observations about the asset enables effective scoring. For instance, detecting a misconfiguration, anomalous network connections, or unusual user activity can significantly raise the asset's score. Consequently, the architecture it belongs to can be flagged for further investigation.

Adapting to a dynamic cloud environment

The cloud is incredibly dynamic. Therefore, Darktrace does not see architectures as fixed entities. Instead, we're always on the lookout for changes, driven by user and service activity. This prompts us to dive back in, update our architectural view, and keep a living record of the cloud's ever-changing landscape, providing near real-time insights into what's happening within it.  

Darktrace/Cloud doesn’t just consider isolated detections, it identifies assets that have misconfigurations and anomalous activity across the network and management plane and adjusts the priority of the alerting to match the potential risk that these assets could be leveraged to enable an attack.  

While in isolation misconfigurations don’t have much meaningful impact, when they are combined with real time updates and anomaly detection within the context of the architecture you see a very important and impactful perspective.  

Combining all of this into one view where security and dev ops teams can collaborate ensures continuity across teams, playing a vital role in providing effective security.

Continue reading
About the author
Adam Stevens
Analyst Technical Director

Blog

Inside the SOC

Socks5Systemz: How Darktrace’s Anomaly Detection Unraveled a Stealthy Botnet

Default blog imageDefault blog image
22
Mar 2024

What are botnets?

Although not a recent addition to the threat landscape, botnets persist as a significant concern for organizations, with many threat actors utilizing them for political, strategic, or financial gain. Botnets pose a particularly persistent threat to security teams; even if one compromised device is detected, attackers will likely have infected multiple devices and can continue to operate. Moreover, threat actors are able to easily replace the malware communication channels between infected devices and their command-and-control (C2) servers, making it incredibly difficult to remove the infection.

Botnet example: Socks5Systemz

One example of a botnet recently investigated by the Darktrace Threat Research team is Socks5Systemz. Socks5Systemz is a proxy-for-rent botnet, whereby actors can rent blocks of infected devices to perform proxying services.  Between August and November 2023, Darktrace detected indicators of Socks5Systemz botnet compromise within a cross-industry section of the customer base. Although open-source intelligence (OSINT) research of the botnet only appeared in November 2023, the anomaly-based approach of Darktrace DETECT™ allowed it to identify multiple stages of the network-based activity on affected customer systems well before traditional rules and signatures would have been implemented.

Darktrace’s Cyber AI Analyst™ complemented DETECT’s successful identification of Socks5Systemz activity on customer networks, playing a pivotal role in piecing together the seemingly separate events that comprised the wider compromise. This allowed Darktrace to build a clearer picture of the attack, empowering its customers with full visibility over emerging incidents.

In the customer environments highlighted in this blog, Darktrace RESPOND™ was not configured to operate autonomously. As a result, Socks5Systemz attacks were able to advance through their kill chains until customer security teams acted upon Darktrace’s detections and began their remediation procedures.

What is Socks5Systemz?

The Socks5Systemz botnet is a proxy service where individuals can use infected devices as proxy servers.

These devices act as ‘middlemen’, forwarding connections from malicious actors on to their intended destination. As this additional connectivity conceals the true origin of the connections, threat actors often use botnets to increase their anonymity. Although unauthorized proxy servers on a corporate network may not appear at first glance to be a priority for organizations and their security teams, complicity in proxy botnets could result in reputational damage and significant financial losses.

Since it was first observed in the wild in 2016, the Socks5Systemz botnet has grown steadily, seemingly unnoticed by cyber security professionals, and has infected a reported 10,000 devices worldwide [1]. Cyber security researchers noted a high concentration of compromised devices in India, with lower concentrations of devices infected in the United States, Latin America, Australia and multiple European and African countries [2]. Renting sections of the Socks5Systemz botnet costs between 1 USD and 4,000 USD, with options to increase the threading and time-range of the rentals [2]. Due to the lack of affected devices in Russia, some threat researchers have concluded that the botnet’s operators are likely Russian [2].

Darktrace’s Coverage of Socks5Systemz

The Darktrace Threat Research team conducted investigations into campaign-like activity across the customer base between August and November 2023, where multiple indicators of compromise (IoCs) relating to the Socks5Systemz proxy botnet were observed. Darktrace identified several stages of the attack chain described in static malware analysis by external researchers. Darktrace was also able to uncover additional IoCs and stages of the Socks5Systemz attack chain that had not featured in external threat research.

Delivery and Execution

Prior research on Socks5Systemz notes how the malware is typically delivered via user input, with delivery methods including phishing emails, exploit kits, malicious ads, and trojanized executables downloaded from peer-to-peer (P2P) networks [1].

Threat actors have also used separate malware loaders such as PrivateLoader and Amadey deliver the Socks5Systemz payload. These loaders will drop executable files that are responsible for setting up persistence and injecting the proxy bot into the infected device’s memory [2]. Although evidence of initial payload delivery did not appear during its investigations, Darktrace did discover IoCs relating to PrivateLoader and Amadey on multiple customer networks. Such activity included HTTP POST requests using PHP to rare external IPs and HTTP connections with a referrer header field, indicative of a redirected connection.

However, additional adjacent activity that may suggest initial user execution and was observed during Darktrace’s investigations. For example, an infected device on one deployment made a HTTP GET request to a rare external domain with a “.fun” top-level domain (TLD) for a PDF file. The URI also appears to have contained a client ID. While this download and HTTP request likely corresponded to the gathering and transmission of further telemetry data and infection verification [2], the downloaded PDF file may have represented a malicious payload.

Advanced Search log details highlighting a device infected by Socks5Systemz downloading a suspicious PDF file.
Figure 1: Advanced Search log details highlighting a device infected by Socks5Systemz downloading a suspicious PDF file.

Establishing C2 Communication  

Once the proxy bot has been injected into the device’s memory, the malware attempts to contact servers owned by the botnet’s operators. Across several customer environments, Darktrace identified infected devices attempting to establish connections with such C2 servers. First, affected devices would make repeated HTTP GET requests over port 80 to rare external domains; these endpoints typically had “.ua” and “.ru” TLDs. The majority of these connection attempts were not preceded by a DNS host lookup, suggesting that the domains were already loaded in the device’s cache memory or hardcoded into the code of running processes.

Figure 2: Breach log data connections identifying repeated unusual HTTP connections over port 80 for domains without prior DNS host lookup.

While most initial HTTP GET requests across investigated incidents did not feature DNS host lookups, Darktrace did identify affected devices on a small number of customer environments performing a series of DNS host lookups for seemingly algorithmically generated domains (DGA). These domains feature the same TLDs as those seen in connections without prior DNS host lookups.  

Figure 3: Cyber AI Analyst data indicating a subset of DGAs queried via DNS by infected devices.

These DNS requests follow the activity reported by researchers, where infected devices query a hardcoded DNS server controlled by the threat actor for an DGA domain [2]. However, as the bulk of Darktrace’s investigations presented HTTP requests without a prior DNS host lookup, this activity indicates a significant deviation from the behavior reported by OSINT sources. This could indicate that multiple variations of the Socks5Systemz botnet were circulating at the time of investigation.

Most hostnames observed during this time of investigation follow a specific regular expression format: /[a-z]{7}\.(ua|net|info|com|ru)/ or /[a-z0-9]{15}\.(ua)/. Darktrace also noticed the HTTP GET requests for DGA domains followed a consistent URI pattern: /single.php?c=<STRING>. The requests were also commonly made using the “Mozilla/5.0 (Windows; U; MSIE 9.0; Windows NT 9.0; en-US)” user agent over port 80.

This URI pattern observed during Darktrace’s investigations appears to reflect infected devices contacting Socks5Systemz C2 servers to register the system and details of the host, and signal it is ready to receive further instructions [2]. These URIs are encrypted with a RC4 stream cipher and contain information relating to the device’s operating system and architecture, as well as details of the infection.

The HTTP GET requests during this time, which involved devices made to a variety a variety of similar DGA domains, appeared alongside IP addresses that were later identified as Socks5Systemz C2 servers.

Figure 4: Cyber AI Analyst investigation details highlighting HTTP GET activity whereby RC4 encrypted data is sent to proxy C2 domains.

However, not all affected devices observed by Darktrace used DGA domains to transmit RC4 encoded data. Some investigated systems were observed making similar HTTP GET requests over port 80, albeit to the external domain: “bddns[.]cc”, using the aforementioned Mozilla user agent. During these requests, Darktrace identified a consistent URI pattern, similar to that seen in the DGA domain GET requests: /sign/<RC4 cipher text>.  

Darktrace DETECT recognized the rarity of the domains and IPs that were connected to by affected devices, as well as the usage of the new Mozilla user agent.  The HTTP connections, and the corresponding Darktrace DETECT model breaches, parallel the analysis made by external researchers: if the initial DGA DNS requests do not return a valid C2 server, infected devices connect to, and request the IP address of a server from, the above-mentioned domain [2].

Connection to Proxy

After sending host and infection details via HTTP and receiving commands from the C2 server, affected devices were frequently observed initiating activity to join the Sock5Systemz botnet. Infected hosts would first make HTTP GET requests to an IP identified as Socks5Systemz’s proxy checker application, usually sending the URI “proxy-activity.txt” to the domain over the HTTP protocol. This likely represents an additional validation check to confirm that the infected device is ready to join the botnet.

Figure 5: Cyber AI Analyst investigation detailing HTTP GET requests over port 80 to the Socks5Systemz Proxy Checker Application.

Following the final validation checks, devices would then attempt TCP connections to a range of IPs, which have been associated with BackConnect proxy servers, over port 1074. At this point, the device is able to receive commands from actors who login to and operate the corresponding BackConnect server. This BackConnect server will transmit traffic from the user renting the segment of the botnet [2].

Darktrace observed a range of activity associated with this stage of the attack, including the use of new or unusual user agents, connections to suspicious IPs, and other anomalous external connectivity which represented a deviation from affected devices’ expected behavior.

Additional Activities Following Proxy Addition

The Darktrace Threat Research team found evidence of the possible deployment of additional malware strains during their investigation into devices affected by Socks5Systemz. IoCs associated with both the Amadey and PrivateLoader loader malware strains, both of which are known to distribute Socks5Systemz, were also observed on affected devices. Additionally, Darktrace observed multiple infected systems performing cryptocurrency mining operations around the time of the Sock5Systemz compromise, utilizing the MinerGate protocol to conduct login and job functions, as well as making DNS requests for mining pools.

While such behavior would fall outside of the expected activity for Socks5Systemz and cannot be definitively attributed to it, Darktrace did observe devices affected by the botnet performing additional malicious downloads and operations during its investigations.

Conclusion

Ultimately, Darktrace’s anomaly-based approach to threat detection enabled it to effectively identify and alert for malicious Socks5Systemz botnet activity long before external researchers had documented its IoCs and tactics, techniques, and procedures (TTPs).  

In fact, Darktrace not only identified multiple distinct attack phases later outlined in external research but also uncovered deviations from these expected patterns of behavior. By proactively detecting emerging threats through anomaly detection rather than relying on existing threat intelligence, Darktrace is well positioned to detect evolving threats like Socks5Systemz, regardless of what their future iterations might look like.

Faced with the threat of persistent botnets, it is crucial for organizations to detect malicious activity in its early stages before additional devices are compromised, making it increasingly difficult to remediate. Darktrace’s suite of products enables the swift and effective detection of such threats. Moreover, when enabled in autonomous response mode, Darktrace RESPOND is uniquely positioned to take immediate, targeted actions to contain these attacks from the onset.

Credit to Adam Potter, Cyber Security Analyst, Anna Gilbertson, Cyber Security Analyst

Appendices

DETECT Model Breaches

  • Anomalous Connection / Multiple Failed Connections to Rare Endpoint
  • Anomalous Connection / Multiple Connections to New External TCP Port
  • Compromise / Beaconing Activity To External Rare
  • Compromise / DGA Beacon
  • Compromise / Beacon to Young Endpoint
  • Compromise / Slow Beaconing Activity To External Rare
  • Compromise / HTTP Beaconing to Rare Destination
  • Compromise / Quick and Regular Windows HTTP Beaconing
  • Compromise / Agent Beacon (Medium Period)
  • Compromise / Agent Beacon (Long Period)
  • Device / New User Agent
  • Device / New User Agent and New IP

Cyber AI Analyst Incidents

  • Possible HTTP Command and Control
  • Possible HTTP Command and Control to Multiple Endpoints
  • Unusual Repeated Connections
  • Unusual Repeated Connections to Multiple Endpoints
  • Multiple DNS Requests for Algorithmically Generated Domains

Indicators of Compromise

IoC - Type - Description

185.141.63[.]172 - IP Address - Socks5Systemz C2 Endpoint

193.242.211[.]141 - IP Address - Socks5Systemz C2 Endpoint

109.230.199[.]181 - IP Address - Socks5Systemz C2 Endpoint

109.236.88[.]134 - IP Address - Socks5Systemz C2 Endpoint

217.23.5[.]14 - IP Address - Socks5Systemz Proxy Checker App

88.80.148[.]8 - IP Address - Socks5Systemz Backconnect Endpoint

88.80.148[.]219 - IP Address - Socks5Systemz Backconnect Endpoint

185.141.63[.]4 - IP Address - Socks5Systemz Backconnect Endpoint

185.141.63[.]2 - IP Address - Socks5Systemz Backconnect Endpoint

195.154.188[.]211 - IP Address - Socks5Systemz Backconnect Endpoint

91.92.111[.]132 - IP Address - Socks5Systemz Backconnect Endpoint

91.121.30[.]185 - IP Address - Socks5Systemz Backconnect Endpoint

94.23.58[.]173 - IP Address - Socks5Systemz Backconnect Endpoint

37.187.148[.]204 - IP Address - Socks5Systemz Backconnect Endpoint

188.165.192[.]18 - IP Address - Socks5Systemz Backconnect Endpoint

/single.php?c=<RC4 data hex encoded> - URI - Socks5Systemz HTTP GET Request

/sign/<RC4 data hex encoded> - URI - Socks5Systemz HTTP GET Request

/proxy-activity.txt - URI - Socks5Systemz HTTP GET Request

datasheet[.]fun - Hostname - Socks5Systemz C2 Endpoint

bddns[.]cc - Hostname - Socks5Systemz C2 Endpoint

send-monitoring[.]bit - Hostname - Socks5Systemz C2 Endpoint

MITRE ATT&CK Mapping

Command and Control

T1071 - Application Layer Protocol

T1071.001 – Web protocols

T1568 – Dynamic Resolution

T1568.002 – Domain Generation Algorithms

T1132 – Data Encoding

T1132 – Non-Standard Encoding

T1090 – Proxy

T1090.002 – External Proxy

Exfiltration

T1041 – Exfiltration over C2 channel

Impact

T1496 – Resource Hijacking

References

1. https://www.bleepingcomputer.com/news/security/socks5systemz-proxy-service-infects-10-000-systems-worldwide/

2. https://www.bitsight.com/blog/unveiling-socks5systemz-rise-new-proxy-service-privateloader-and-amadey

Continue reading
About the author
Adam Potter
Cyber Analyst
Our ai. Your data.

Elevate your cyber defenses with Darktrace AI

Start your free trial
Darktrace AI protecting a business from cyber threats.