On Dec. 8, 2020, one of the leading cybersecurity companies in the industry, FireEye, reported a breach and data exfiltration unlike any that we have seen previously. What makes this attack unique is not only the target, FireEye being a well-known cybersecurity company, but that the stolen data contains the internal, custom-crafted red-team and penetration testing tools used by the company to imitate different threat actors during customer security consultations. FireEye’s blog provided a wealth of information for defenders to implement security controls and mitigations for defense against the stolen tools. This data is being used by Palo Alto Networks to help ensure our customers are protected if the attackers choose to utilize the tools for malicious purposes.
It is important to note that these custom tools were not released into the wild, they were stolen by a sophisticated threat actor and we likely will not see a sudden widespread use of them. That being said, FireEye went beyond what was required – and what companies have done in the past – in releasing detection techniques. Providing defenders access to the Yara rules, indicators of compromise (IOCs), Snort signatures and other threat data is a class act and very much appreciated by defenders and researchers at Palo Alto Networks – and surely across the industry as a whole.
Protecting Our Customers
Palo Alto Networks has been working diligently to ensure the protections released by FireEye are implemented in a timely manner. The Github repository shared by FireEye contains a list of rules and 16 vulnerability CVE identifiers. The vulnerabilities appear to have been included because sufficient protections against these can help limit the effectiveness of the red-team tools.
Palo Alto Networks has ensured the protections within our products are either already in place or are being prioritized for the provided vulnerabilities and their exploitation. These vulnerabilities range from a wide variety of products, and as always, we highly recommend our customers stay current with their updates and patch all vulnerable software.
The Github repository that provided the protections also contains rules for direct product implementation as well as hunting. Palo Alto Networks is analyzing the efficacy of and applying all stable rules to our respective products. Gap analysis and threat hunting leveraging the FireEye-provided Yara and Snort signatures have enabled Palo Alto Networks researchers to identify potential malware samples that we are now tagging, analyzing, tracking and building protections around within WildFire. Continual verdict efficacy checks of identified malware samples is ongoing within Palo Alto Networks products. Customers leveraging the Palo Alto Networks AutoFocus tool can track initially identified samples and tools under the Fireye_RedTeam_Tools, Rubeus, AndrewSpecial, KeeFarce, SafetyKatz, InveighZero, GadgetToJScript, SeatBelt, RuralBishop, SharpView, and SharpZeroLogon tags. Our Cortex XDR Managed Threat Hunting Team (MTH) has proactively searched all Cortex XDR Pro customer logs to identify potentially impacted organizations and provide them an assessment of their risk.
Cortex XDR customers are protected using the product’s WildFire integration as well as through Local Analysis, the Password theft prevention module, and the behavioral threat protection (BTP) engine. In addition, multiple Behavioural Indicators of Compromise (BIOCs) are available in XDR Server to detect malicious techniques exhibited by the stolen tools.
Threat Prevention provides protection against command and control beacons and exploitation of network vulnerabilities used by the stolen tools. The following table provides an overview of the mapping between Palo Alto Networks Universal Threat IDs (UTIDs) and the provided FireEye SIDs.
Snort Rule
PANW UTID
FireEye SID
Backdoor.HTTP.BEACON.[CSBundle Original Stager]
86215
25879
Backdoor.HTTP.BEACON.[CSBundle MSOffice POST]
86216
25889
Backdoor.HTTP.BEACON.[CSBundle USAToday GET]
86217
25892
Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]
86219
25888
Backdoor.HTTP.BEACON.[CSBundle Original GET]
86220
25877
Backdoor.HTTP.GORAT.[Build ID]
86221
25850
Backdoor.HTTP.BEACON.[CSBundle Original POST]
86222
25878
Backdoor.HTTP.GORAT.[SID1]
86223
25848
Backdoor.HTTP.BEACON.[CSBundle Original Server]
86225
25874
Backdoor.HTTP.BEACON.[CSBundle Original Server 3]
86227
25876
Table 1. PANW UTIDs to FYE Signature Mapping
CVE
PANW UTID
CVE-2019-0708
55815
CVE-2017-11774
56002
CVE-2018-15961
38319
CVE-2019-19781
57570, 57497 and 57625
CVE-2019-3398
55567
CVE-2019-11580
56036
CVE-2018-13379
56365
CVE-2020-0688
57947 and 57766
CVE-2019-11510
56280
CVE-2019-0604
55411, 57462 and 56363
CVE-2020-10189
57801
CVE-2019-8394
59061
CVE-2020-1472
59336
CVE-2018-8581
55152
CVE-2016-0167
392102205
CVE-2014-1812
90128
Table 2: CVE to UTID Mapping
Conclusion
The protections in place for our customers are continually being updated for this breach and for all threats that are identified in the wild. Palo Alto Networks appreciates the information disclosure from FireEye, but we also want to emphasize that at the time this report is published, the tools, hashes of the tools and associated samples have not been disclosed to the public. From the perspective of Palo Alto Networks security researchers, the biggest threat from this breach is the actor and the techniques they were able to utilize in order to infiltrate the FireEye infrastructure. Currently, there has not been any information released on the breach or the threat actor’s tactics, techniques, and procedures (TTPs). Customers should know that Palo Alto Networks researchers are working diligently to ensure protections are in place for our entire product ecosystem.
Cryptojacking (or simply malicious coin mining) is a common way for malware authors to monetize their operations. While the underlying mining protocols and techniques remain fairly standard, malware actors tend to seek out and find smarter ways to hack into a victim's machines. Recently, Unit 42 researchers uncovered a novel Linux-based cryptocurrency mining botnet that exploits a disputed PostgreSQL remote code execution (RCE) vulnerability that compromises database servers for cryptojacking. We named the cryptocurrency mining botnet "PGMiner" after its delivery channel and mining behavior. At its core, PGMiner attempts to connect to the mining pool for Monero mining. Because the mining pool is not active anymore, we could not recover information about the actual profit of this malware family.
PostgreSQL, also known as Postgres, is among the most-used open source relational database management systems (RDBMS) for production environments. According to DB-Engines, PostgreSQL ranks fourth among all database management systems (DBMS) as of November 2020 and has seen a steady increase in popularity since 2013. In particular, PostgreSQL was named database of the year in 2017 and 2018 by DB-Engines.
The feature in PostgreSQL under exploitation is "copy from program," which was introduced in version 9.3 on Sept. 9, 2013. In 2018, CVE-2019-9193 was linked to this feature, naming it as a "vulnerability." However, the PostgreSQL community challenged this assignment, and the CVE has been labeled as "disputed."
We believe PGMiner is the first cryptocurrency mining botnet that is delivered via PostgreSQL. It is notable that malware actors have started to weaponize not only confirmed CVEs, but also disputed ones.
At the time of this writing, none of the vendors on VirusTotal detect PGMiner. WildFire, a cloud-based malware analysis platform, detects it by dynamic analysis with the observation of self-deletion and process impersonation. Besides the delivery channel, PGMiner’s coin mining codebase reassembles some of the characteristics from the the SystemdMiner family and its variants 1, 2 and 3, but with the following notable changes:
Delete the PostgreSQL table right after code launch to achieve fileless execution.
Collect system information and send it to the command and control (C2) server for victim identification.
Employ traditional and novel approaches to download curl binary in case the command is not available on the victim’s machine.
Impersonate the "tracepath" process to hide its presence.
Attempt to kill competitor programs for better monetization.
Attack Process Overview
A high-level overview of PGMiner’s execution flow is depicted in Figure 1. As explained before, the malicious payload is delivered via PostgreSQL, which communicates to the backend C2 servers through SOCKS5 proxies. After that, it downloads the coin mining payloads based on the system architecture.
Figure 1. Structure of PGMiner exploiting a disputed PostgreSQL RCE vulnerability.
During our analysis, we found that PGMiner constantly reproduces itself by recursively downloading certain modules. To better illustrate this process, we show the payload relationship in Figure 2. Each box links to a sample identified in the infection chain. The record contains filename, abbreviated SHA256 value and file type information. Note that whenever the architecture information is in the filename, we iterate through all other possible architectures and add the samples in the graph if successfully downloaded. The abbreviated C2 for each stage is marked with dark green. Also, the samples in light blue boxes have been extensively studied in previous research work (SystemdMiner and its variants 1, 2 and 3). Here, we’ll focus on the samples that appear in light red boxes and provide a summary of the rest.
Figure 2. PGMiner payload relationship.
Initial Compromise via PostgreSQL Exploit
The root sample that triggered our investigation is 55698654f0fbcf5a6d52f3f44bc0f2257e06835e76fb7142d449a2d1641d7e4b, which is an AARCH64 ELF file that is static linked and stripped. At the time of this writing, none of the vendors on VirusTotal is able to detect this malware, as shown in Figure 3.
Figure 3. None of the vendors on VirusTotal detect PGMiner.
The sample above works as an exploit tool that attempts to exploit a controversial feature in PostgreSQL that allows RCE on the server’s operating system (OS). By reverse engineering the binary as shown in Figure 4, we found the sample has the libpq postgresql client library statically linked. This is used for communicating with the target database servers. The attacker scans port 5432 (0x1538), used by PostgreSQLql of the hosts in the private/local network (i.e., 172.16.0.0, 192.168.0.0 and 10.0.0.0 subnets). The malware randomly picks a public network range (e.g., 190.0.0.0, 66.0.0.0) in an attempt to perform RCE on the PostgreSQL server. With the user "postgres", which is the default user of the database, the attacker performs a brute-force attack iterating over a built-in list of popular passwords such as "112233" and "1q2w3e4r" to crack the database authentication.
Figure 4. PostgreSQL exploit code flow in PGMiner.
Once the malware successfully breaks into the database, it uses the PostgreSQL "copy from program" feature to download and launch the coin mining scripts. The "copy from program" feature has been controversial since its debut in PostgreSQL 9.3. The feature allows the local or remote superuser to run shell script directly on the server, which has raised wide security concerns. In 2019, a CVE-2019-9193 was assigned to this feature, naming it as a "vulnerability." However, the PostgreSQL community challenged this assignment, and the CVE has been labeled as "disputed." The main argument against defining the feature as a vulnerability is that the feature itself does not impose a risk as long as the superuser privilege is not granted to remote or untrusted users and the access control and authentication system works well. On the other side, security researchers worry that this feature indeed makes PostgreSQL a stepping stone for remote exploit and code execution directly on the server’s OS beyond the PostgreSQL software, if the attacker manages to own the superuser privilege by brute-forcing password or SQL injection.
Figure 5. PGMiner’s exploit content to PostgreSQL.
While this CVE is still being disputed, malware authors apparently have started to use it to stay under the detection radar by making the attack payload fileless. The actual exploit content from PGMiner is shown in Figure 5, which can be broken down to the following steps:
Step
SQL command
Clear the “abroxu” table if it exists.
DROP TABLE IF EXISTS abroxu;
Create the table with a text column.
CREATE TABLE abroxu(cmd_output text);
Save the malicious payload to table "abroxu".
COPY abroxu FROM PROGRAM “shell command”;
Execute the payload on the PostgreSQL server.
SELECT * FROM cmd_exec;
Clear the created table.
DROP TABLE IF EXISTS abroxu;
The malicious script payload saved in the "abroxu" table reassembles some of the characteristics from the known SystemdMiner malware family and its variants. Here we only highlight the major ways that PGMiner evolves from SystemdMiner, as well as overlooked functionalities. We have also added annotation to the script shown in the figures below to make this clear.
Downloading Curl
In the case that the curl command is not available on the victim’s machine, the malicious script tries multiple approaches (see Figure 6) to download the curl binary and add it to the execution paths:
Direct installation from official package management utilities like apt-get and yum.
Download static curl binary from GitHub.
Download using /dev/tcp in case the normal ways don’t work.
Figure 6. PGMiner’s multiple attempts to download curl binaries.
While the first two approaches are well-known, the third one is quite unique. What’s more interesting is the target IP address: 94[.]237[.]85[.]89. It is connected to the domain newt[.]keetup[.]com. While its parent domain, keepup[.]com, seems like a legitimate business website, this particular subdomain is redirecting port 80 to 443, which is used to host a couchdb named newt. Although port 8080 is not open to the public, we believe it has been configured to allow Cross-Origin Resource Sharing (CORS), as shown in Figure 7.
Figure 7. newt[.]keetup[.]com is hosting a couchdb for curl binary downloading.
Resolving SOCKS5/TOR Relay Server Name
The C2 host name has been updated to nssnkct6udyyx6zlv4l6jhqr5jdf643shyerk246fs27ksrdehl2z3qd[.]onion. PGMiner also utilizes the SOCKS5 proxy technique to communicate with the C2, as described in this SystemdMiner variant. However, as shown in Figure 8, the DNS server list has been expanded.
Figure 8. Updated C2 and expanded DNS server list observed in PGMiner.
Fetch Payloads From C2 and Launch PGMiner
After resolving the SOCKS5 proxy server IP address, PGMiner rotates through a list of folders to find the first one that allows permission to create a new file and update its attributes. This ensures the downloaded malicious payload can successfully execute on the victim’s machine. This function has been observed in the previous research on the SystemdMiner variant, but the author of the research did not provide an explanation of its purpose.
The malware family also evolves with client tracking functionality. It concatenates the IP address, username, architecture, hostname and md5 of all inet IP ranges, as well as the base64 encoding of the crontab content, to formulate the client’s unique identifier, which it reports to the C2 server. The code snippet is highlighted in Figure 9.
Figure 9. PGMiner featches payloads from C2 and executes them.
Multi-Architecture Payloads
With different architectures supplied to the C2 server mentioned above, we were able to recover the following list of payloads. The downloads for other architectures failed.
6d296648fdbc693e604f6375eaf7e28b87a73b8405dc8cd3147663b5e8b96ff0 pg.x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header
Interestingly, the payload for x86_64 is an ELF executable, while for aarch64 and armv7l, the payload is an identical shell script.
x86_64 ELF Payload
The x86_64 ELF payload shares the majority of behaviors seen in the previous SystemdMiner variant, yet evolves with additional capabilities:
Environment Preparation:
Download and install curl binary as explained above.
Install crontab.
Remove cloud security monitor tools such as Aegis, and Qcloud monitor utilities such as Yunjing.
Virtual Machine Checking: PGMiner checks the existence of VBoxGuestAdditions to infer whether it is being analyzed in a virtual environment.
Competitors Removal:
Remove other known miner scripts, processes and crontab records.
Kill miner cleanup processes.
Kill all other CPU intensive processes such as ddg, system updates and so on.
Kill processes connected to known mining IP addresses.
armv7l/aarch64 Shell Script Payload
From the x86_64 ELF payload, we were able to recover the CPU file from C2 jk5zra7b3yq32timb27n4qj5udk4w2l5kqn5ulhnugdscelttfhtoyd[.]onion, which is the coin mining module for PGMiner. However, the other cmd and bot modules are unavailable from the C2. Here, the armv7l/aarch64 shell script connects to a different C2, reambusweduybcp[.]onion. It also attempts to download the cmd file. This time, it succeeds. This indicates that the C2 server for this malware family is constantly updating. Different modules are distributed across different C2s.
The cmd module first attempts to kill the tracepath process. Then, it downloads additional payload from the same C2 address. The downloaded malware impersonates the tracepath process to hide its presence. After analyzing the aarch64 payload, we recovered the same shell script initially used to run on PostgreSQL servers, which completes the analysis.
Mitigations and Recommendations
Palo Alto Networks Next-Generation Firewall customers are protected against PGMiner via the WildFire and Threat Prevention security subscriptions. At the same time, we urge PostgreSQL users to remove the “pg_execute_server_program” privilege from untrusted users, which makes the exploit impossible. Moreover, we continue to recommend that users download software from trusted sources, manage strong and secure passwords and apply patches in a timely manner.
To remove the impact of PGMiner on the PostgreSQL server, the user can search and kill the “tracepath” process, which this malware impersonates, and kill the processes whose process IDs (PIDs) have been tracked by the malware in “/tmp/.X11-unix/”.
Conclusion
In this research, we unveiled PGMiner, a new cryptocurrency mining botnet delivered via a disputed PostgreSQL RCE vulnerability. The fact that PGMiner is exploiting a disputed vulnerability helped it remain unnoticed until we recently uncovered it at Palo Alto Networks.
PGMiner can potentially be disruptive, as PostgreSQL is widely adopted in PDMS. With additional effort, the malware could target all major operating systems. For example, PostgreSQL is available for all major platforms, including macOS, Windows and Linux. Theoretically, the malware actors could implement another version of PGMiner by targeting a new platform, such as Windows, and deliver it using PostgreSQL.
During our analysis, we observed new techniques, such as embedding victim identification in the request, impersonating a trusted process name, downloading curl binary via multiple approaches and more and aggressively killing all competitor programs. We also analyzed how the malware seeks to better track victims, execute, hide itself and monetize. Other traits, such as the malware recursively downloading itself and frequently changing C2 addresses, also indicate PGMiner is still rapidly evolving.
The vulnerability requires network access to the administrative configurator on port 8443 (though this can be configured to be any port) and a valid password for the configurator admin account. If these conditions exist, a malicious actor could execute commands with unrestricted privileges on the underlying operating system.
Mitigation Actions
First and foremost, patch the vulnerable software if at all possible. If, for some reason, the vulnerable software cannot be patched, then refer to the following workarounds:
Warning:
This workaround is applicable ONLY to VMware Workspace ONE Access, VMware Identity Manager and VMware Identity Manager Connector. Do not apply this workaround to other VMware products.
To implement the workaround for CVE-2020-4006, perform the following steps below. Please note the operating system.
1. Implement workaround for Linux-based appliances:
Use SSH to connect to appliance using “sshuser” credentials configured during installation or updated later.
Switch to root by typing su and provide “root” credentials configured during installation or updated later.
Run the following commands:
cd /opt/vmware/horizon//workspace mkdir webapps.tmp mv webapps/cfg webapps.tmp mv conf/Catalina/localhost/cfg.xml webapps.tmp service horizon-workspace restart
Repeat steps for all Linux-based appliances affected by CVE-2020-4006.
2. Implement workaround for Windows-based servers:
Log in as Administrator.
Open a Command Prompt window and run the following commands:
Net stop “VMwareIDMConnector” cd \VMware\VMwareIdentityManager\Connector\opt\vmware\horizon\workspace mkdir webappstmp move webapps\cfg webappstmp move conf\Catalina\localhost\cfg.xml webappstmp net start “VMwareIDMConnector”
Repeat steps for all Windows-based servers affected by CVE-2020-4006.
To remove the workaround for CVE-2020-4006, perform the following steps:
1. Revert workaround for Linux-based appliances.
Use SSH to connect to appliance using “sshuser” credentials configured during installation or updated later.
Switch to root by typing su and provide “root” credentials configured during installation or updated later.
Run the following commands:
cd /opt/vmware/horizon/workspace mv webapps.tmp/cfg webapps mv webapps.tmp/cfg.xml conf/Catalina/localhost rmdir webapps.tmp service horizon-workspace restart
Repeat steps for all Linux-based appliances affected by CVE-2020-4006.
2. Revert workaround for Windows-based servers
Log in as Administrator.
Open a Command Prompt window and run the following commands:
net stop "VMwareIDMConnector" cd \VMware\VMwareIdentityManager\Connector\opt\vmware\horizon\workspace move webappstmp\cfg webapps move webappstmp\cfg.xml conf\Catalina\localhost rmdir webappstmp net start "VMwareIDMConnector"
Repeat steps for all Windows-based servers affected by CVE-2020-4006.
Conclusion
Palo Alto Networks is continuing efforts to identify a proof of concept (PoC) or other relevant information that would allow specific coverage for exploitation of this vulnerability. Due to the lack of specific attack details related to exploitation, Palo Alto Networks highly recommends patching your vulnerable software when possible and/or implementing the workaround provided by VMWare. This blog will be updated when more information becomes available.
In observations collected since October 2020, Unit 42 researchers have found that malware authors have been leveraging njRAT (also known as Bladabindi), a Remote Access Trojan, to download and deliver second-stage payloads from Pastebin, a popular website that is well-known to be used to store data anonymously. Attackers are taking advantage of this service to post malicious data that can be accessed by malware through a shortened URL, thus allowing them to avoid the use of their own command and control (C2) infrastructure and therefore increasing the possibility of operating unnoticed.
In this blog, we will introduce different scenarios and data transformations that we have found in the wild, and describe the relationship between the downloader component and its second-stage malware.
Pastebin's C2 tunnel is actively used by attackers as a hosting service for malicious payloads that can be downloaded by keyloggers, backdoors or Trojans.
The hosted data differs in its form and shape. The different data encodings and transformations that can be found include traditional base64 encoding, hexadecimal and JSON data, compressed blobs, and plain-text data with embedded malicious URLs. It is believed that this use of Pastebin is intended to evade detection by security products.
In the following sections, we will introduce different scenarios and data transformations that we have found in the wild, and describe the relationship between the downloader component and its second-stage malware.
Second-Stage Malware Dropped by base64 Encoding Response
The downloader (91f4b53cc4fc22c636406f527e3dca3f10aea7cc0d7a9ee955c9631c80d9777f) requests Pastebin C2 data and uses the less evasive version of stored data, which corresponds to traditional base64 encoding.
base64: Encoded data
base64: Decoded / Binary dumped
Figure 1. base64 encoded data and its transformation to an executable file.
Once decoded, the final payload is revealed as a 32-bit .NET executable, which makes use of several Windows API functions including GetKeyboardState(), GetAsynckeyState(), MapVirtualKey(), etc. These are commonly used by keyloggers and Trojans, as well as by functions used to potentially exfiltrate user data. It is also worth noting that the downloader and second-stage executables are similar in their functionality and code.
The following image presents a screen capture of the decompiled code of the second-stage sample.
Figure 2. Windows API functions related to keylogger functionalities.
Second-Stage Malware Dropped by base64 Encoding Reverse Evasion
In this version, the base64 data was reversed, presumably as a measure to avoid detection for automated systems.
Reversed base64 string
Transformed base64 data
Figure 3. base64 encoded reversed string and its transformation to base64 format.
After proper transformation and decoding of data, the final second-stage 32-bit .NET executable was found to be a similar sample, which exhibits keylogging and Trojan capabilities as well. Three data transformation layers were required to get the final payload.
Second-Stage Malware Dropped by ASCII and base64 Response
In this version, the base64 data was presented in hex characters.
Hex encoded string
Hex decoded and encoded base64 data
Figure 4. Hex encoded string and its transformation to base64 format.
After proper decoding of Hex and base64 data, the dumped program is also a 32-bit.NET executable file sharing the same malicious characteristics as the previous example.
Second-Stage Malware Dropped by base64 Encoded and Compressed Data Response
This 32-bit .NET launcher sample, unlike the others, works with compressed data fetched from Pastebin.
Figure 5. Decompression and execution of base64 compressed data.
The downloader performs the following actions:
The base64 encoded and compressed data is downloaded by the execution of the DownloadString() function by passing as an argument, a string that was generated by the concatenation of the variables str, str2, str3 and str4 that form the target URL.
The base64 and compressed data are now decoded by the FromBase64String() function and decompressed by the DecompressGZip() function. The result is an executable file stored in a byte array in the rawAssembly variable.
Finally, a call to the Load().EntryPoint.Invoke() function is made by passing the rawAssembly variable to the executable file in memory in order to position itself within the system and release the malicious payload.
The following picture shows the decompressed 32-bit .NET executable data residing in memory before its execution.
Figure 6. Decompressed second-stage malware in memory.
This .NET downloader uses the traditional method of grabbing an executable file from a remote URL. The target address points to hxxp://textfiles[.]us/driverupdate0.exe.
According to VirusTotal, this malware sample was identified by several vendors as malicious.
Figure 7. VirusTotal and its detection rate on driverupdate0.exe executable file.
In this version, JSON formatted data was used. One of the key names, “downlodLink” (misspelled on purpose by the malware author), indicates that the value will be a URL, where additional components can be downloaded. No further information was given regarding the objective of this particular file, but it could potentially be used as a configuration file.
This malware parses the HTML page in order to get the link to prepare for further attacks. For this particular sample, Pastebin data is used to provide links for software downloads.
Figure 9. Link pointing to Proxy Scraper software.
The download link points to a compressed file called Simple+Scraper.zip containing two files: MaterialSkin.dll and Proxy Scraper.exe. By statically inspecting the code using .NET Decompiler software, we found that the downloader malware uses Pastebin as a repository to host links to updates related to the Proxy Scraper software.
Figure 10. .NET code used to check for updates related to the Proxy Scraper software.
The downloader version (“v2.0”) is shown at code level, but the second-stage malware code doesn’t indicate a version. However, based on VirusTotal information, the executable file has been submitted under different names, including “Lithium proxy scraper v2.6”.
Conclusion
The Pastebin C2 tunnel is still alive and being used by njRAT to deliver malicious payloads by downloading data hosted in Pastebin, allowing this and other malware families in the wild to take advantage of paste-based public services. Based on our research, malware authors are interested in hosting their second-stage payloads in Pastebin and encrypting or obfuscating such data as a measure to evade security solutions. There is a possibility that malware authors will use services like Pastebin for the long term.
At the time of this writing, the following samples were not publicly available. However, we have created all the required coverage against their behavior and communication.
Since September 2020, Unit 42 researchers have observed Egregor ransomware affecting multiple industries globally, including those within the U.S, Europe, Asia Pacific and Latin America, following the decline in operations utilizing the Maze ransomware. Egregor operations mimic that of Maze operations, leading us to believe that although Maze operators announced a shutdown of the “Maze Team Project,” the operators behind those activities have simply developed a new ransomware to move their objectives forward.
Due to the surge in Egregor ransomware activity, we’ve created this general threat assessment for overall threat awareness. Full visualization of the techniques observed and their relevant courses of action can be viewed in the Unit 42 ATOM Viewer.
Malware Overview
Egregor is a variant of the Sekhmet ransomware family. It has been observed since at least September 2020, around the same time when Maze ransomware operators announced an intent to shut down their operations. Affiliates who utilized the Maze ransomware to conduct their activities now appear to have likely moved on to Egregor to avoid disrupting their operations.
Maze ransomware leveraged malware such as Trickbot, and Egregor has followed suit, using commodity malware such as Qakbot, IcedID and Ursnif for initial access. Ryuk ransomware also leveraged both Trickbot and BazaLoader in a similar fashion to gain initial access to a victim system.
After initial infection, scripts are used to modify victim firewalls and enable Remote Desktop Protocol (RDP). Cobalt Strike is used to conduct network reconnaissance, move laterally across the network, exfiltrate data and prepare for execution.
During our analysis, we observed a ZIP file containing a PowerShell script (Figure 1) that attempts to uninstall a McAfee endpoint agent. It then uses BITS to download the Egregor DLL from a malicious server and execute the payload using Rundll32.
Figure 1.PowerShell script used to download Egregor ransomware.
Egregor uses multiple anti-analysis and evasion techniques, such as disabling a system’s antivirus software and heavily obfuscating the payload. Also, the payload can only be executed with a key using the expected command-line argument, in this case “-passegregor10”. When run on the victim’s system, Egregor changes the files’ extensions to a random set of characters. When the encryption of files is complete, the ransomware creates the ransom note file “RECOVER-FILES.txt” in all folders that contain encrypted files.
Figure 2. Egregor’s “Hall of Shame.”
The ransom note provides instructions with a three-day deadline to pay the ransom. If no contact is made within that timeframe, the victim risks exposure of all exfiltrated data on the Egregor “Hall of Shame” (Figure 2). Visible on the Hall of Shame is a visitor number and a progress percentage apparently referring to uploading data. We suspect that these numbers are used to aid the threat actors’ ransom negotiations.
This section documents relevant tactics, techniques and procedures (TTPs) used with Egregor 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.
The below courses of action mitigate the following techniques: Spearphishing Attachment [T1566.001], Valid Accounts [T1078], PowerShell [T1059.001], DLL Side-Loading [T1574.002], Process Injection [T1055], Obfuscated Files or Information [T1027], Rundll32 [T1218.011]
NGFW
Set up File Blocking
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
Threat Prevention†
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 that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned and set to appropriate actions
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
The below courses of action mitigate the following techniques:
Account Discovery [T1087], Domain Trust Discovery [T1482], File and Directory Discovery [T1083]
NGFW
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
Cortex XDR
Configure Behavioral Threat Protection under the Malware Security Profile
Impact
The below courses of action mitigate the following techniques:
Data Encrypted for Impact [T1486]
Cortex XSOAR
Deploy XSOAR Playbook - Ransomware Manual for incident response.
Table 1. Courses of Action for Egregor ransomware. †These capabilities are part of the NGFW security subscriptions service.
Conclusion
In the short period of its observed activities, Egregor ransomware has compromised industries globally, including those within the U.S, Europe, Asia Pacific and Latin America. Organizations should be aware of and monitor the use of commodity malware, such as Qakbot, IcedID and Ursnif, that could end up delivering Egregor ransomware as a second-stage payload. Like Maze and other current variants, Egregor ransomware affiliates use double extortion. They host an extortion website called the “Hall of Shame” site to create additional pressure and shame their victims into paying the ransom.
With the fall of Maze ransomware and the rise of Egregor, we suspect the group behind this ransomware will remain active in the following months and will continue their efforts to target high-profile organizations.
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.
In addition to the above courses of action, AutoFocus customers can review additional activity by using the tag Egregor.
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 May 2019, Microsoft released an out-of-band patch update for remote code execution (RCE) vulnerability CVE-2019-0708, which is also known as “BlueKeep” and resides in code for Remote Desktop Services (RDS). Over the last year, researchers had proved the exploitability of BlueKeep and proposed countermeasures to detect and prevent it. However, RDP is still one of the most popular attack vectors used by attackers today. To make it harder for RDP attacks to succeed and to better protect Windows users and our customers, we will disclose detailed information in this blog about how attackers might exploit BlueKeep on Windows RDP endpoints.
In August 2019, Unit 42 researchers published a blog on CVE-2019-0708, covering how Bitmap Cache protocol data unit (PDU), Refresh Rect PDU and RDPDR Client Name Request PDU can be used to write data into the Windows kernel memory. Additionally, in October 2019, Unit 42 researchers presented three new Windows kernel pool Feng Shui techniques with RDP PDUs and two different exploit techniques of BlueKeep at Microsoft’s BlueHat Seattle 2019 Security Conference. This blog discusses how to combine Refresh Rect PDU and RDPDR Client Name Request PDU to get remote code execution RCE with system privilege.
Palo Alto Networks Next-Generation Firewall customers with the Threat Prevention security subscription are protected from this vulnerability, and Cortex XDR customers can prevent exploitation of this vulnerability on Windows XP, Windows 7 and Windows Server 2003 and 2008.
Quick Review of Refresh Rect PDU and RDPDR Client Name Request PDU
Our last blog about BlueKeep introduced Refresh Rect PDU and RDPDR Client Name Request PDU in Windows RDP protocols in detail. Here is a quick review of those two PDUs.
Refresh Rect PDU can be used to spray many 0x828-sized kernel pools by sending PDUs multiple times. Those 0x828-sized kernel pools will be aligned by 0x1000 offset, and there are eight bytes of data controlled by RDP Client at offset 0x2c in each 0x828-sized kernel pool. The start address of eight bytes-controlled data looks like 0x8xxxx02c. During our testing, the 0x828-sized kernel pools are groomed consecutively from the address 0x86000000 to 0x8a000000 with the 0x1000-sized kernel pool aligned on our VMware virtual machine. In the exploitation proof of concept (PoC), we used 0x86c1002c as the fixed address to store a function pointer and got a very high success rate when re-exploiting multiple times and when restarting systems. The address 0x88xxx02c and 0x89xxx02c are also good candidates that perform very well in high memory consumption targets, such as RDP servers running a lot of applications at the same time.
RDPDR Client Name Request PDU can be used to reclaim the freed channel object with controlled data by sending PDUs multiple times. The size and data of the kernel pool allocated when the RDP server parses Client Name Request PDU are both controllable. We can make the RDP server allocate the 0xd0-sized kernel pool to claim the freed MS_T120 channel object. By spraying the kernel pool with the specifically crafted data, we can control the reuse route to execute a function call with a controllable function pointer and thus control extended instruction pointer (EIP). We can also use Client Name Request PDU to write the shellcode into the kernel pool since the size and data of Client Name Request PDU are both controllable by the RDP client. All the details about how those two PDUs are used in the exploit will be discussed in the following sections.
Vulnerability Overview
To make the exploitation clear, we will briefly introduce the root cause of CVE-2019-0708. CVE-2019-0708 is a Use After Free (UAF) vulnerability related to a dangling object, the MS_T120 virtual channel. The MS_T120 virtual channel is one of two default channels (MS_T120 and CTXTW) used by the RDP server internally that are initialized when the RDP connection is established. However, the RDP client can also create a customized virtual channel named “MS_T120” by adding the “MS_T120” item to channelDefArray in Client MCS Connect Initial PDU, as shown in Figure 1.
Figure 1. Customized MS_T120 channel in channelDefArray.
The RDP server receives that request and creates a reference for the MS_T120 object in the ChannelPointerTable object. Figure 2 shows that there are two “MS_T120” channel object references in the ChannelPointerTable object. The first one is created for the Client MCS Connect Initial PDU request, and the second one is created for internal use by the RDP server.
After joining the customized MS_T120 channel using MCS Channel Join Request, the MS_T120 channel can be opened successfully by the RDP client. If the RDP client sends crafted data into the MS_T120 channel as shown in Figure 3, the MCSPortData function in rdpwx.dll module will be invoked.
Figure 3. PDU used to free MS_T120 channel object.
In the function MCSPortData, the data starting from 0x74 offset of the first argument lpAddend are controlled by the RDP client, and MCSChannelClose will be called to free the MS_T120 channel object when the variable “v2” is equal to the value “2”, as shown in Figure 4.
Figure 4. Close channel in MCSPortData.
After the MS_T120 channel object is freed, there is still one dangling pointer left pointing to the freed MS_T120 channel object in the slot 0x1f of the ChannelPointerTable object, as shown in Figure 5.
When the RDP client disconnects from the connection, the function RDPWD!SignalBrokenConnection is invoked, and then the function termdd!IcaChannelInput will be called to access the freed MS_T120 object in the slot 0x1f, as shown in Figure 6.
Figure 6. Reuse freed MS_T120 object call stack.
Reuse After Free
We have discussed how the MS_T120 channel object is freed, leaving a dangling pointer to the MS_T120 channel object in the ChannelPointerTable object. Now we will cover how to reuse the freed object. In the function termdd!IcaChannelInput, the function IcaFindChannel will be called to find the channel object. When the RDP client terminates the connection, the second argument slot_base will be 0x05 and the third argument slot_index will be 0x1f, and so the function IcaFindChannel will set the freed MS_T120 channel object as the return value. If the freed MS_T120 channel object is reclaimed with a fake MS_T120 channel object, the following function execution route can be controlled with a function call (call [eax]) in which the function pointer (register eax) is obtained from inside the fake MS_T120 channel object, as shown in Figure 7.
Figure 7. Reuse route in IcaChannelInputInternal.
Reclaim the Freed MS_T120 Channel Object With RDPDR Client Name Request PDU and Control EIP
In this section, details about how to reclaim the freed MS_T120 channel object to control EIP will be discussed. The size of the freed MS_T120 Channel is 0xc8 (0xd0 including 8 bytes pool header), as shown in Figure 5. The termdd!IcaChannelInputInternal function will allocate channel_data_size+0x20-sized kernel pool, as shown in Figure 19 of our previous blog. The size of the Client Name Request PDU needs to be set to 0xa8 (0xc8-0x20), and the ComputerNameLen field needs to be set to 0x98 accordingly if we want the function termdd!IcaChannelInputInternal to allocate the 0xc8-sized kernel pool. Considering that there is a memory copy operation after successful pool allocation, by sending those Client Name Request PDUs multiple times, we ensure the freed MS_T120 pool slot has been occupied by the Client Name Request PDU data. Moreover, the first 0x20 bytes of the 0xc8-sized kernel pool is for the internal use of the termdd module, which means the first 0x20 bytes are not controllable, and the following 0x10 bytes that are for the Client Name Request PDU header are also not controllable, so the controllable data size is 0x98 (0xc8-0x20-0x10) in total. Figure 8 shows how the RDP client constructs the RDPDR Client Name Request PDU.
Figure 8. RDPDR Client Name Request to reclaim the freed MS_T120 channel object.
Figure 9 shows the memory dump of the fake MS_T120 channel object created by sending RDPDR Client Name Request PDU. Several important fields in the fake MS_T120 channel object are labeled in different colors. The 4 bytes (DWORD) value of 0x00000000 in green is set to prevent service from crashing in hal!KeAcquireInStackQueuedSpinLockRaiseToSynch, which is called by ExEnterCriticalRegionAndAcquireResourceExclusive. The DWORD value of 0x00000000 in light blue is set to ensure condition check and make the function route arrive at the function call (call [eax]) with the controlled function pointer eax, as shown in Figure 7.
Figure 9. Fake MS_T120 channel object.
The DWORD value 0x86c10030 in purple is set at the offset 0x8c of the fake MS_T120 channel object, as shown in Figure 9. The debug log in Figure 10 shows how to get the fake object address at the offset 0x8c and make a function call (call [eax]) to control EIP.
Figure 10. Function call with controlled function pointer in IcaChannelInputInternal.Now that we've shown how the EIP is controlled, we will discuss why the eax is set to the address 0x86c10030 and the EIP is set to the address 0x86c1002c. With the technique described in the previous section, we are able to get a stable spray from the address 0x86xxxxxx to 0x8axxxxxx. There are 8 bytes data controllable at the offset 0x002c in each aligned 0x1000 address, as shown in Figure 11.
Figure 11. Stable spray with Refresh Rect PDU.
The code snippet in Figure 12 shows how the RDP client constructs the Refresh Rect PDUs and how many times it needs to send them to the RDP server.
Figure 12. How to construct Refresh Rect PDU to spray in the RDP client.
In the 8 bytes of controllable data in each aligned 0x1000 sized kernel pool, 4 bytes at offset 0x0030 (0x86c10030) are set to 0x86c1002c, which is the hard-coded address of stage 0 shellcode. The other 4 bytes at offset 0x002c (0x86c1002c) are used to store the stage 0 shellcode. The next section will introduce more details about the several stages of shellcodes.
Shellcode
Since there are only 4 bytes that can be used for the stage 0 shellcode, we used a trick of 4 bytes shellcode slipper “add bl,al; jmp ebx” instead of “call/jmp ebx+30h” to jump to stage one of shellcode. When termdd!IcaChannelInputInternal executes “call dword ptr [eax]” assembly instruction, the al is 0x30 and ebx points to the fake MS_T120 channel object in which the RDP client can fill the controlled data. Stage one shellcode is put into the kernel pool from the address faked_MS_T120_channel_object+0x30 (0x867b3590). The whole process is shown in Figure 13.
Figure 13. Stage 0 shellcode.
Something worth mentioning: 2 bytes assembly code “add bl, al” is used because only 4 bytes shellcode can be used to implement “jmp ebx+0x30”. This is not perfect, since when “bl” is greater than 0xd0, there is an overflow in “add bl, al”, enabling “jmp ebx” to jump to a wrong address, causing the exploitation to fail. However, this will be good enough, since the success rate will theoretically be 81.25% (0xd/0x10).
Before talking about stage one shellcode, we’d like to discuss stage two, or the final shellcode. We noticed that the RDPDR Client Name Request PDU can also be used to send arbitrary-sized final kernel shellcodes to the kernel pool in the RDP server. As an example, we constructed an RDPDR Client Name Request PDU with the data length of 0x5c8 and the payload embedded, as shown in Figure 14.
Figure 14. Final shellcode sent by RDPDR Client Name Request PDU.
When the RDPDR Client Name Request PDU embedded with the shellcode is sent to the RDP server, PDMCS - Hydra MCS Protocol Driver will store the data in the kernel pool. Interestingly, that kernel pool has a reference maintained on the stack, which can be used by stage one shellcode to locate the final shellcode. Specifically, the ECX register here points to the stack, and the address ECX+0x28 stores the kernel pool address. The final shellcode is located at the 0x434 offset of the kernel pool, as shown in Figure 15.
Figure 15. Stage one shellcode.
The offset 0x434 may vary in different Windows versions. However, it is easy to craft the stage one shellcode as an egg hunter to make it universal by searching the final shellcode in the kernel pool.
Patch Kernel to Avoid Crash
The following work is now a routine for kernel exploitation. The final shellcode first fixes the return value and patches the kernel to avoid crash after the shellcode finishes, and then it executes the kernel shellcode to insert the APC to lsass.exe or spoolsv.exe and execute user mode shellcode. Figure 16 shows how the final shellcode fixes the ChannelPointerTable object, modifies the return address and emulates the execution of the ExReleaseResourceAndLeaveCriticalRegion function to inc a WORD value in KTHREAD.
Figure 16. Final shellcode patch the kernel.
After patching the kernel, the functional part of the kernel shellcode is executed. To illustrate the exploitation, we used a kernel shellcode template released by Sleepya for the eternalblue exploit. A userland shellcode of WinExec(‘calc’) for the demo is shown in Figure 17.
Figure 17. Final shellcode usermode shellcode.
Putting It All Together
Now that we have solved all the problems of exploitation, the whole exploitation chain can be described as follows:
Establish the connection to the victim.
Spray with Refresh Rect PDU.
Send the crafted PDU, forcing the MS_T120 channel object to be freed.
Occupy the freed MS_T120 channel object with multiple RDPDR Client Name Request PDUs.
Send the final shellcode with RDPDR Client Name Request PDU.
Terminate the connection to reuse the freed MS_T120 channel object, control EIP and execute several stages of shellcode.
Conclusion
This blog outlines how to get system privilege RCE with Refresh Rect PDU and RDPDR Client Name Request PDU for the Windows RDP vulnerability CVE-2019-0708 (BlueKeep). The 4 bytes shellcode slider in shellcode stage 0 and the shellcode egg hunter in shellcode stage one are general exploit techniques and could be used in all Windows RDP vulnerability exploitations. The deep research on the kernel pool Feng Shui techniques with RDP PDUs and Windows RDP exploit techniques will help defenders to better protect all Windows users from Windows RDP attacks.
Palo Alto Networks customers are protected from BlueKeep:
Cortex XDR prevents exploitation of this vulnerability on Windows XP, Windows 7 and Windows Server 2003 and 2008.
Data leakage from mobile applications is a known problem in the industry. Leaked data violates users' privacy and can be used for further attacks by cybercriminals, such as collecting a phone’s location or retrieving called numbers. Leaking data can be defined as transferring certain information from a users' device without their knowledge and collecting it at the receiver’s side, potentially exposing this data to third parties on the transmission channel in the process.
With the help of a machine learning (ML)-based spyware detection system, Unit 42 researchers identified multiple Android applications on Google Play that were leaking data, including Baidu Search Box and Baidu Maps, which had been downloaded a combined 6 million times in the U.S. The leaked data made users trackable, potentially over their lifetime. Previous Unit 42 research has outlined examples of how this type of data can be used by attackers once leaked.
While not a definitive violation of Google’s policy for Android apps, the collection of identifiers, such as the IMSI or MAC address, is discouraged based on Android's best practice guide. Unit 42 notified Baidu of this discovery. Unit 42 also notified Google’s Android team, who confirmed the findings, identified unspecified violations and removed the applications from Google Play globally on Oct. 28, 2020. A compliant version of Baidu Search Box became available on Google Play globally on Nov. 19, 2020, while Baidu Maps remains unavailable globally.
Google’s Android team said, “We appreciate the work of the research community, and companies like Palo Alto Networks, who work to strengthen the security of the Play Store. We look forward to collaborating with them on more research in the future."
Behavior that is typically found in Android malware was also discovered in applications that can be downloaded from official app stores (such as Google Play) and have millions of monthly active users.
Palo Alto Networks Next-Generation Firewall customers are protected by threat and spyware identification, as well as by file analysis with a WildFire security subscription.
To prevent data leakage, Android app developers should follow Android’s best practices guide and correctly handle users’ data. Android users should stay informed about the required permissions requested by applications on their devices.
Android Applications Can Leak Sensitive Information
Some Android applications are known to leak data from a user's device. This data can potentially be sensitive, depending on the type of information being transmitted. Data that is often leaked by Android applications include:
Phone model.
Screen resolution.
Phone MAC address.
Carrier (Telecom Provider).
Network (Wi-Fi, 2G, 3G, 4G, 5G).
Android ID.
IMSI (International Mobile Subscriber Identity).
IMEI (International Mobile Equipment Identity).
While some of this information, such as screen resolution, is rather harmless, data such as the IMSI can be used to uniquely identify and track a user, even if that user switches to a different phone and takes the number. The IMEI is a unique identifier of the physical device and denotes information such as the manufacturing date and hardware specifications.
The IMSI uniquely identifies a subscriber to a cellular network and is typically associated with a phone’s SIM card, which can be transferred between devices. Both identifiers can be used to track and locate users within a cellular network.
Android applications that collect data, such as the IMSI, are able to track users over the lifetime of multiple devices. For example, if a user switches their SIM card to a new phone and installs an application that previously collected and transmitted the IMSI number, the app developer is able to uniquely identify that user.
Data such as the IMSI or the IMEI are desirable for cybercriminals, who can use methods such as active and passive IMSI catchers to overhear this information from cell phone users. Once this data is acquired, cybercriminals can profile users and further extract sensitive information about them. For example, if a cybercriminal gets hold of a phone’s IMEI number, they could use it to report the phone as stolen and trigger the provider to disable the device and block its access to the network.
This data can also be misused by cybercriminals or state actors to violate a user’s privacy and take advantage of the leaked information to intercept phone calls or text messages. Users can be put further at risk if cybercriminals or state actors intercept messages that transfer information in plain text or with weak encryption.
The sensitivity of device-specific information, such as IMEI, IMSI or the MAC address of a phone, is further highlighted by Android’s best practices guide for app developers on how to handle unique user identifiers. In particular, the guide points out the importance of avoiding usage of hardware-specific identifiers that are not resettable by the user, including the IMSI or Android ID.
Discovery of Android Applications Leaking Data
To provide an example of data leakage, our ML-based spyware detection system identified the following message from the Android malware UmengAdware (SHA256: 49d7a7c4a2e6afe1feb3642f8aabe314f8c8fa156658e3f3bc0bf6926950d0c1), which was sent to a destination IP address in China (202[.]108.23.105) from an Android application executed in our malware sandbox, WildFire.
The data of interest is in the devinfo field, as shown in the highlighted part of the message above. After in-depth research on the contents of the message and analyzing multiple Android applications, we identified Baidu’s Android push SDK as the source of the message. The SDK is widely used by some of the largest Baidu applications, such as Baidu Maps or Baidu Search Box, as listed in Table 1 below.
The reverse-engineered Android code in Figure 1 below reflects the message structure and shows the collection of various information about the device, including the phone’s MAC address, carrier information and IMSI number, which is extracted in the function shown in Figure 2.
Figure 1. Android code showing message structure from Baidu Maps v10.24.8.Figure 2. Android function extracting IMSI number from Baidu Maps v10.24.8.
The reverse-engineered code snippets in Figure 2 were found in the Baidu Maps application version 10.24.8, which Unit 42 downloaded from Google Play in the U.S. to analyze. We investigated multiple Android applications for data leakage. The two largest applications we discovered leaking data were Baidu Search Box and Baidu Maps. In Nov. 2020, Baidu reported “Baidu App's daily active users ("DAUs") reached 206 million and its monthly active users ("MAUs") reached 544 million in September 2020.”
Other applications available in Google Play in the U.S. that we analyzed include the Homestyler - Interior Design & Decorating Ideas app, which uses the framework GrowingIO, as shown in Table 1. The app collects private information from a user’s device. This app has not been taken down by Google.
Table 1. Largest Android apps analyzed by Unit 42 that collect private information, in order by the number of downloads in Google Play in the U.S.
While not a definitive violation of Google’s policy for Android apps, the collection of identifiers, such as the IMSI or MAC address, is discouraged based on Android's best practice guide. Unit 42 notified Baidu of this discovery. We also reported our findings to Google’s Android team. After a detailed analysis of the reported applications, Google confirmed our findings and identified unspecified violations in the reported Baidu applications. This led to the removal of Baidu Search Box and Baidu Maps from Google Play globally on Oct. 28, 2020. A compliant version of Baidu Search Box became available on Google Play globally on Nov. 19, 2020, while Baidu Maps remains unavailable globally.
Another example for Android SDK that collects sensitive information from a user's phone is ShareSDK from the Chinese vendor MobTech. ShareSDK supports more than 40 social media platforms. It helps third-party app developers easily access social media sharing and registration. It also allows them to acquire users' information, friends lists and other social functions. Currently, ShareSDK is offering service for over 37,500 applications, and it has become China's largest developer service platform.
Figure 3 below is the source code of ShareSDK, which collects device data including MAC address, Android ID and Advertising ID and stores it in a HashMap structure.
Figure 3. Android ShareSDK collects various device information, such as the MAC address or the Android ID.
Further code examples from ShareSDK in Figures 4 and 5 show the collection of the IMEI and IMSI data, which are provided in the Android TelephonyManager by calling the functions getDeviceId() and getSubscriberId() respectively.
Figure 4. Source code from ShareSDK collecting IMEI data.Figure 5. Source code from ShareSDK collecting IMSI data.
Similar Behavior Observed in Android Malware
Analysis of Android malware shows that SDKs, such as the Baidu Push SDK or ShareSDK, are frequently used by malicious applications to extract and transmit device data. The sample communication below shows a message extracted from the malware AndroidSudo (SHA256: 3135f8118c55f2a1ca84f69899e330d7ac63c09e77e0c7baff088a0bb185063c), which collects and transmits device data such as the Android ID, IMEI and MAC address.
This behavior is equivalent to the functionalities observed in the SDKs and applications previously mentioned in this blog. (Sensitive information in the message is redacted.)
Using Machine Learning to Detect Spyware Traffic
Analyzing traffic patterns for malicious behavior or data leakage is traditionally done based on signatures that make a true/false decision as to whether a traffic pattern matches a signature. To improve our detection capabilities and identify network traffic that is rarely detected by signatures, Unit 42 researchers developed an ML-based spyware detection system able to identify novel and unknown types of malicious traffic by considering over 1,000 features in the network traffic, while maintaining a negligible false positive rate. This new approach shows a considerable increase in detected novel spyware traffic compared to existing intrusion prevention systems.
Our novel spyware detection system identified the findings discussed in this blog by applying models trained on known characteristics, as well as features previously not considered to identify malicious and suspicious network traffic.
Conclusion
Data leakage from Android applications and SDKs represents a serious violation of users' privacy. Detection of such behavior is vital in order to protect the privacy rights of mobile users.
In mobile devices, it is typical to ask a user to grant a list of permissions upon installation of an application or to prompt a user to allow or deny a permission while the application is running. Disallowing permissions can often result in a non-working application, which leads to a bad user experience and might tempt a user to click on “allow” just to be able to use an application. Even if a certain permission is granted, it is often up to the app developers whether it is used in accordance with the official guidelines. For example, reading the phone identifiers such as the Android ID or IMEI requires the permission “read phone status and identity” on Android. While this permission is often used for basic functionality, like detecting an incoming phone call, it also allows access to crucial information such as the IMEI. Once this permission is granted, it is difficult for a user to determine whether the permission is misused by cybercriminals to steal private information.
Palo Alto Networks identifies data leakage by leveraging ML techniques that monitor network traffic for malicious and suspicious behavior during application analysis in WildFire. The advantage of such techniques is that they do not only rely on known traffic patterns, but are also able to identify previously unknown types of data-leaking traffic.
Palo Alto Networks Next-Generation Firewall customers are protected by threat and spyware identification, as well as by file analysis with a WildFire security subscription.
To prevent data leakage, Android app developers should follow Android’s best practices guide and correctly handle users’ data. Android users should stay informed about the required permissions requested by applications on their devices.
In a recent blog, “Information Leakage in AWS Resource-Based Policy APIs,” Unit 42 researchers disclosed a class of Amazon Web Services (AWS) APIs that can be abused to find existing users and Identity and Access Management (IAM) roles in arbitrary accounts. The root cause of the issue is that the AWS backend validates all resource-based policies and raises alerts if a specified principal does not exist. One can abuse this feature to check whether a user or role exists in a targeted account. An attacker can keep asking this question with different names and eventually map out all the users/roles in a targeted account – a process that can be made easier if the attacker first collects public information about the target and uses this to build a wordlist to test. Once an attacker obtains the roster of an organization, it becomes possible to launch other targeted attacks, such as searching for misconfigured IAM roles, sending spear-phishing emails, etc.
Based on those findings, Unit 42 developed IAMFinder, a custom open-source tool that currently implements APIs of four AWS services: Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS), Amazon Simple Queue Service (SQS) and AWS Identity and Access Management (IAM). With only the AWS account number of the targeted account, IAMFinder is able to identify users and roles in that environment. Organizations can use IAMFinder to identify the information leaked from IAM reconnaissance. With this tool, organizations can then adjust and reinforce their IAM configuration to mitigate the potential impact of an attacker knowing the users and roles in their AWS account.
Key features of IAMFinder:
Realistically simulates attacker behavior. Just as would be true in the case of a malicious attack, a targeted account won't notice that its users or roles are being enumerated. Because the enumeration is performed in your accounts, the logs only show up in your accounts. However, a targeted account will notice if IAMFinder attempts to assume roles.
High enumeration rate. IAMFinder can quickly enumerate users or roles in a targeted account by:
Concurrently invoking APIs of multiple AWS services (e.g., S3, KMS and IAM) in the account used to perform the test.
Concurrently using multiple AWS accounts to perform the test.
Modularized and extensible. One can implement and integrate additional AWS APIs described in our previous blog on information leakage.
Cross-partitions. IAMFinder has been tested in all three AWS partitions: AWS Standard (aws), AWS GovCloud U.S. (aws-us-gov) and AWS China (aws-cn).
Zero cost. The resources that IAMFinder creates in each service don’t have actual workloads and should not incur any costs.
Use Cases
Search for misconfigured IAM trust policies. This tool can assist in the enumeration of IAM users and roles. Upon identification of these IAM entities, the process of testing for misconfigurations can begin. In a recent Red Team exercise, Unit 42 researchers gained privileged access to a cloud account with tens of thousands of workloads through a misconfigured IAM role. Researchers identified a misconfigured role in the targeted account that allowed anonymous users to assume the role. This could result in any number of attacks against an organization, including ransomware, or even open a door for an advanced persistent threat (APT) adversary.
Know where strong credentials are needed most. Our most recent Unit 42 Cloud Threat Report shows that 46% of IAM users in the Americas do not enforce multi-factor authentication (MFA). Considering that tens or hundreds of users typically exist in a cloud account, an attacker can identify the existing users in a cloud account without MFA enabled and attempt credential cracking or credential stuffing. Organizations can use IAMFinder to gain a hacker's view of their cloud infrastructure. Because users found by IAMFinder are likely to be poked more often, they should always have strong passwords and MFA in place.
Cloud environment reconnaissance. System administrators typically name an IAM role based on its functionalities. For example, “ecsTaskExecutionRole” is used for executing AWS Lambda functions, “AWSCodeDeployRole” is used for managing AWS CodeDeploy and “S3Access” is used for accessing S3 buckets. By observing the existing roles, adversaries can learn the types of workloads and their functionalities in a cloud account. Organizations can use IAMFinder to identify common role names in their cloud infrastructure. A few random characters can be added to the role names so that they become less likely to be found.
CI/CD pipeline integration. Users and roles in a cloud environment are frequently updated to accommodate different applications' requirements. It is crucial to monitor IAM drift and identify any newly introduced insecure configurations. IAMFinder can be integrated into a CI/CD pipeline to perform an unauthenticated scan on the users and roles in a cloud environment and identify anything that needs to be made more secure.
Design and Evaluation
Figure 1. IAMFinder architecture.
Figure 1 illustrates IAMFinder's architecture. IAMFinder needs at least one AWS account with sufficient permissions to perform the test. The required permissions are detailed on the instruction page. IAMFinder takes a list of names and an AWS account number as input and outputs a list of existing names it finds. IAMFinder creates resources (e.g., S3 buckets, SQS queues or KMS keys) in one or multiple AWS accounts and attempts to update their resource-based policies with various principal names. IAMFinder accesses multiple resources concurrently with multithreading and alternates between accounts and services in a round-robin manner.
Because AWS throttles each API's request, the enumeration rate is limited by the API's max allowed request rate. Our evaluation shows that IAMFinder can check 2.8 names per second by sequentially updating an S3 bucket's policy. This enumeration rate is too low when brute-forcing a list of thousands of names. To overcome this limit, IAMFinder implements multiple ways to increase the number of APIs that can be called concurrently. The following settings can be configured to improve the enumeration rate:
AWS services to use. IAMFinder currently supports four AWS services (S3, KMS, SQS and IAM). Users can choose to use one or multiple AWS services to perform the test. Our evaluation shows that IAMFinder's enumeration rate increases with the number of services used. In Figure 2, it takes 710 seconds to enumerate 2,000 names using a single S3 bucket. When using all four services, this time drops to 101 seconds.
Number of resources created for each AWS service. To fully utilize each API's request rate, IAMFinder can create multiple resources for each AWS service and call the same API concurrently. For example, IAMFinder can create three S3 buckets and concurrently call the update_bucket() APIs to modify their policies. Our evaluation shows that two to three resources can usually saturate the request rate of an API, but using too many resources may trigger a time penalty and cause negative effects. In Figure 2, the enumeration time of using only one S3 bucket is 710 seconds. When using three S3 buckets, the time drops to 240 seconds.
Number of AWS accounts. Another way to increase the enumeration rate is using multiple AWS accounts to perform the test. IAMFinder can use services in multiple AWS accounts concurrently to enumerate a targeted account. Our evaluation shows that the enumeration rate improves linearly with the number of accounts used. In Figure 3, enumerating 2,000 names with three AWS accounts takes approximately one-third of the time than enumerating with only one account.
Figure 2. The times to enumerate 2,000 names in IAMFinder depending on different settings being used.Figure 3. Using different numbers of AWS accounts to enumerate 2,000 names with IAMFinder.
Conclusion
IAMFinder is an open-source tool developed based on the findings of Unit 42’s recent research on information leakage in AWS resource-based policy APIs. IAMFinder currently implements four out of the sixteen AWS services as described in the blog (S3, KMS, SQS and IAM). If more services are implemented, IAMFinder should achieve even better performance.
Organizations can use IAMFinder to identify the information leaked from IAM reconnaissance. With this tool, organizations can adjust and reinforce their IAM configuration to mitigate the potential impact.
We hope the cybersecurity community can help continue the efforts and improve the tool. IAMFinder is posted on GitHub to allow the community to make it more extensible and apply it to more proactive DevOps use cases.
Unit 42 researchers discovered a class of Amazon Web Services (AWS) APIs that can be abused to leak the AWS Identity and Access Management (IAM) users and roles in arbitrary accounts. Researchers confirmed that 22 APIs across 16 different AWS services could be abused the same way and the exploit works across all three AWS partitions (aws, aws-us-gov or aws-cn). AWS services that can be potentially abused by attackers include Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS) and Amazon Simple Queue Service (SQS). A malicious actor may obtain the roster of an account, learn the organization's internal structure and launch targeted attacks against individuals. In a recent Red Team exercise, Unit 42 researchers compromised a customer’s cloud account with thousands of workloads using a misconfigured IAM role identified by this technique.
The root cause of the issue is that the AWS backend proactively validates all the resource-based policies attached to resources such as Amazon Simple Storage Service (S3) buckets and customer-managed keys. Resource-based policies usually include a Principal field that specifies the identities (users or roles) allowed to access the resource. If the policy contains a nonexistent identity, the API call that creates or updates the policy will fail with an error message. This convenient feature, however, can be abused to check whether an identity exists in an AWS account. Adversaries can repeatedly invoke these APIs with different principals to enumerate the users and roles in a targeted account. Furthermore, the targeted account can't observe the enumeration because the API logs and error messages only appear in the attacker's account where the resource policies are manipulated. The "stealthy" property of the technique makes detection and prevention difficult. Attackers can have unrestricted time to perform reconnaissance on random or targeted AWS accounts without worrying about being noticed.
AWS Resource-Based Policy
AWS IAM manages permissions between users, resources and applications using various types of policies. Resource-based policy is a type of policy attached to resources within an AWS service. Each AWS service can have multiple resources and each resource can be attached with a different policy. For example, an S3 service can create multiple bucket resources and the SQS service can create multiple message queue resources. At the time of this writing, there are 26 AWS services that support resource-based policies, as shown in Table 1. The policy determines the actions that principals can perform on the attached resource. A principal can be an AWS user, role or service. The actions that can be performed depend on the type of service.
Figure 1. Resource-based policy illustration.
Figure 2 is an example resource-based policy attached to an S3 bucket. Two principals are allowed to access the bucket, user “Bob” in account 123456789012 and IAM role “qa-role” in account 98765431098. The principals can perform three actions, GetObject, GetBucketLocation and ListBucket on S3 bucket “awsexamplebucket”. Note that the principals do not need to be in the same account as the bucket, meaning that a policy can also grant cross-account access to resources.
Figure 2 is the simplest form of a policy. A more complicated policy may consist of multiple statements and conditions. To avoid human errors, AWS validates every field in the policy before the policy can be applied to a resource. The validator ensures the specified principals actually exist and the specified actions are supported by the service. In Figure 2, an error message is raised because “GetFiles” is not a supported action.
Figure 2. Example S3 bucket policy (left) and error message when an action is mis-specified (right).
Abusing Resource-Based Policy APIs
Policy validation is a feature from AWS that facilitates the user experience. While most users benefit from the feature, adversaries may also find the feature useful for performing reconnaissance in another account. Because the policy validator checks whether the specified principal exists, it gives adversaries a way to build up knowledge of a targeted account's roster gradually. As we will show, adversaries may abuse policy validators in multiple AWS services that support resource-based policies.
When defining a principal in a resource-based policy, users ask AWS to authenticate and authorize the principal to access the resources in an AWS account. If we provide an invalid username or role name, the authentication will fail. One of the authentication best practices for implementing a secure authentication process is to avoid giving out account-specific information in error messages.
The AWS policy validator inadvertently leaks account-specific information in the error messages. When creating or updating a resource policy, the AWS policy validator explicitly reveals if the specified principal exists or not. An adversary could use the error messages to check whether a user or an IAM role exists in a targeted account. By repeating this process with a wordlist, an adversary can enumerate and discover the existing identities in a targeted account. Figures 3 and 4 show the error messages when we specify a nonexistent IAM role in different AWS services' resource policies. These policies are rejected and can't be saved. The process can also be performed programmatically using AWS APIs, making the enumeration scalable.
One concerning property of this technique is that it is completely unobservable by the target or victim. When making changes to a resource policy, the AWS CloudTrail logs and error messages only appear in the resource owner or the attacker's account. The "stealthy" property makes detection and prevention almost impossible.
A similar technique was first published in a blog by Rhino Security Labs, in which they used the IAM role trust policy to check whether a cross-account IAM role exists. Unit 42 researchers identified and confirmed that at least 22 APIs across 16 AWS services can be exploited, as shown in Table 1. The commonality between these APIs is that they all take a resource policy as input and the policy needs to have a valid "Principal" field.
Figure 3. Resource policies with nonexistent principals. AWS SQS (left) and AWS SNS (right).Figure 4. Resource policies with nonexistent principals. AWS KMS (left) and AWS Glue (right).
Conclusion
Detecting and preventing identity reconnaissance using this technique is difficult as there are no observable logs in the targeted accounts. However, good IAM security hygiene can still effectively mitigate the threats from this type of attack. Although it’s not possible to prevent an attacker from enumerating identities in AWS accounts, the enumeration can be made more difficult and you can monitor for suspicious activities taken after the reconnaissance. To mitigate this issue, we recommend the following IAM security best practices for organizations:
Remove inactive users and roles to reduce the attack surface.
Add random strings to usernames and role names to make them more difficult to guess.
The formjacking attack has been one of the fastest-growing cyberattacks in recent years. As explained in our previous blog, “Anatomy of Formjacking Attacks,” the formjacking attack is easy to deploy but hard to detect. It has gained popularity among threat actors, especially against e-commerce websites. Between May and September 2020, we detected an average of 65,000 malicious HTML pages and 24,000 unique URLs compromised by formjacking attacks.
In this blog, we will take a closer look at the web skimmer attack, which is one of the most widely used formjacking attacks. We will present several web skimmer samples and provide an in-depth analysis of the attack vectors deployed during the attack. We hope this blog will help security researchers understand how web skimmer attacks happen in a real-life environment and develop effective detection and defense mechanisms.
Palo Alto Networks Next-Generation Firewall customers are protected from formjacking attacks via the WildFire and URL Filtering security subscriptions.
Victim Analysis
With WildFire, we detected 351,972 HTML pages that were compromised by skimmer malware from October 2019-October 2020. These samples belong to 6,684 unique domain names.
We derived the geographical locations for the domain names to generate a heat map as shown in Figure 1. This heat map indicates that the majority of the domain names are located in the United States. Also, the domain names have a wide geographic distribution across almost every continent, including Africa and Australia.
Figure 1. Geographical location of domains including HTML pages that were compromised by web skimmer malware from October 2019-October 2020.
Figure 2 shows the top eight countries the domain names belong to. While the United States has a majority share, it is notable that all of the top countries have a populace with a relatively high socioeconomic status. This seems sensible since most of the skimmer attacks target e-commerce websites, which attract users with spending power.
Figure 2. Top eight countries, based on geographical location of domains compromised by web skimmer malware from October 2019-October 2020.
Web Skimmer Family Analysis
In order to understand web skimmer attacks, we analyzed skimmer samples and determined that, although the skimmer HTML pages have different layouts and styles, they share similar JavaScript code. We were able to extract 10,764 unique malicious JavaScript snippets from the 351,972 HTML pages collected from October 2019-October 2020.
With the help of VirusTotal and automation tools, we were able to identify 63 different malware families based on their functionalities and features. Figure 3 shows the number of HTML samples associated with each skimmer family. Among all malware families, 19 are relatively popular, with more than 1,000 observed samples each, while the remaining 44 families were seen in only 3,612 pages combined.
Figure 3. Number of HTML samples among web skimmer families from October 2019-October 2020.
From Figure 3, we can see that 27% of malicious web skimmer pages belong to the most popular skimmer family (family1 in Figure 3). Also, the top three families (family1, family2 and family3) can cover 65% of all web skimmer pages, considering that one page can belong to multiple skimmer families.
We found some pages with more than one malicious JavaScript embedded. For those pages, no evidence indicated different types of skimmers are intentionally used together. Rather, it is more likely that the pages were randomly compromised by different campaigns independent of each other.
Web Skimmer Case Study
From October 2019-October 2020, we observed the evolution of skimmer obfuscation techniques and command and control (C2) communication. Specifically, we determined that family7, shown in Figure 3 with a total number of 34,004 samples, is typical and representative of skimming attacks. In this section, we will do a deep dive into family7 to better understand how a skimmer operates. Multiple variants of web skimmer samples from family7 will be presented. We hope this can help security researchers understand the complexity and polymorphism of web skimmer attacks, especially in terms of the code structure and usage of obfuscation techniques.
Let’s start with the JavaScript code extracted from one of the most commonly seen skimmer samples in family7, as shown below in Example 1.
Example 1. JavaScript code from sample 1 of family7.
From the code, we can see that the payment information is stolen by the attackers, and then the data is sent to the C2 server (https://informaer[.]net/js/info_jquery.js) via a POST request. The related function is shown below.
The characteristics of JavaScript grammar allow the code to be presented in different ways. Even samples of code that are nearly identical to one another could be refined or rewritten into a completely different structure. In another variant shown below, sample 2, we see code from family7 presented:
Example 2. JavaScript code from sample 2 of family7.
Sample 1 has labeled function declarations to define JavaScript functions. In sample 2, the traditional way to define JavaScript functions is used. In order to detect and capture both of them using intrusion prevention system (IPS) signatures, patterns need to be written in a way that considers both ways of definition. Also, in this sample, the C2 server points to “https://cloudservice[.]tw/lib/jquery.php” to steal the sensitive information.
Obfuscation and polymorphism are also widely used in delivering malicious code. Many open-source tools, such as javascript-obfuscator and jfogs, can be utilized to make it easier to evade detection, rather than rewriting the malicious code. Below is another piece of code coming from the family7:
Example 3. JavaScript code from sample 3 of family7.
In this case, its C2 server URL is encoded in hexadecimal form.
By converting the hex strings into the decoded characters, we can find its C2 server pointing to "https://onlinestatus[.]site/js/status.js".
Other than the samples we’ve presented above, highly obfuscated malicious codes were also observed in family7. Though these samples have different code, the logic and main code flow are similar or even identical. Intruders seem to deploy different code in different compromised websites, which makes it less likely to be detected by IPS signatures with one single pattern.
Another fact worth mentioning here is that the URL of the C2 server is written as a variable in JavaScript, which is fairly easy for the attackers to modify. In our dataset, we determined that many other skimmer samples use the same code after decoding/de-obfuscation, yet point to different C2 servers.
Figure 4 shows all the extracted C2 servers and the usage statistics from family7.
Figure 4. C2 server usage found in web skimmer samples from family7.From Figure 4, we can see that eight domains are used in 93% of web skimmer samples from family7, which shows that the skimmer malware campaign operates many C2 servers. When the C2 server is blocked or detected, the attackers can easily replace the C2 server with a new domain name.
Identifying all C2 servers is an impractical strategy because most malicious JavaScript samples are heavily obfuscated using complicated methods to which automation cannot be applied. Evolving codes and constantly changing IPs also make it difficult to collect all live C2 servers.
We also determined that some C2 servers are used in more than one family, providing us with strong evidence that these families could be maintained or operated by the same campaign. For example, "https://cloudservice[.]tw/lib/jquery.php" seen in the second sample above, also appears in another family (labelled as “other” in Figure 3):
Example 4. JavaScript code from other samples using the same C2 servers.
Palo Alto Networks has developed an advanced detection module in WildFire that targets formjacking attacks. Figure 5 shows the monthly detection of malicious HTML pages and unique URLs in the past five months (May - Sept. 2020). On average, WildFire detected 65,000 malicious HTML pages (listed as “all hit”) and 24,000 unique URLs (listed as “unique url hit”) compromised by formjacking attacks. All detections automatically undergo additional analysis for verification. WildFire correctly identifies and detects formjacking attacks, while URL Filtering identifies those URLs as malicious and categorizes them accordingly.
Figure 5. Number of detected malicious URLs from WildFire (May - September 2020). “All hit” measures malicious HTML images, while “unique URL hit” measures unique URLs.
Conclusion
A web skimmer is a popular formjacking attack to steal sensitive information by injecting malicious JavaScript code into compromised websites. In this blog, we analyzed 351,972 HTML pages infected by skimmer campaigns October 2019-October 2020 and found that skimmer malware is highly elusive and continuously evolving. Traces of web skimmer attacks are found across every corner of the world.
For security teams, comprehensive detection against skimmer malware is not an easy task. They have to keep alert and be aware of the latest techniques used by skimmer malware in order to develop dynamic detection strategies.
For website administrators, it is advisable to patch all systems, components and web plugins in their organization to minimize the likelihood of compromised systems. Also, conducting web content integrity checks on a regular basis is highly recommended. This can help detect and prevent web skimmer attacks.
For internet users, it is advisable to track online activities for abnormal use and unauthorized payments from online banking services. If you believe your credit card information was stolen as a result of a recent online purchase, you should contact your bank to freeze or replace your card immediately.
Palo Alto Networks Next-Generation Firewall customers are protected from formjacking attacks via the WildFire and URL Filtering security subscriptions.
The xHunt campaign has been active since at least July 2018 and we have seen this group target Kuwait government and shipping and transportation organizations. Recently, we observed evidence that the threat actors compromised a Microsoft Exchange Server at an organization in Kuwait. We do not have visibility into how the actors gained access to this Exchange server. However, based on the creation timestamps of scheduled tasks associated with the breach, we believe the threat actors had gained access to the Exchange server on or before Aug. 22, 2019. The activity we observed involved two backdoors – one of which we call TriFive and a variant of CASHY200 that we call Snugy – as well as a web shell that we call BumbleBee.
The TriFive and Snugy backdoors are PowerShell scripts that provide backdoor access to the compromised Exchange server, using different command and control (C2) channels to communicate with the actors. The TriFive backdoor uses an email-based channel that uses Exchange Web Services (EWS) to create drafts within the Deleted Items folder of a compromised email account. The Snugy backdoor uses a DNS tunneling channel to run commands on the compromised server. We will provide an overview of these two backdoors since they differ from tools previously used in the campaign.
We will be providing an analysis of the activity associated with the BumbleBee web shell in an upcoming blog. That activity provides a glimpse into the threat actor's tactics, techniques and procedures when interacting with compromised servers.
Palo Alto Networks customers are protected from the attacks outlined in this blog in a variety of ways. See the Conclusion for more details.
TriFive and Snugy Backdoors
In September 2020, we were notified that threat actors breached an organization in Kuwait. The organization's Exchange server had suspicious commands being executed via the Internet Information Services (IIS) process w3wp.exe. Actors issued these commands via a web shell we call BumbleBee that had been installed on the Exchange server, which we will discuss in detail in a future blog. We investigated how the actors installed the web shell on the system, and we did not find any evidence of exploitation of the Exchange server within the logs that we were able to collect. However, we did discover two scheduled tasks created by the threat actor well before the dates of the collected logs, both of which would run malicious PowerShell scripts. We cannot confirm that the actors used either of these PowerShell scripts to install the web shell, but we believe the threat actors already had access to the server prior to the logs.
The actors created two tasks on the Exchange server named ResolutionHosts and ResolutionsHosts, both of which were created within the c:\Windows\System32\Tasks\Microsoft\Windows\WDI folder. This folder also stores a legitimate ResolutionHost task by default on Windows systems, as seen in Figure 1. The legitimate ResolutionHost task is associated with the Windows Diagnostic Infrastructure (WDI) Resolution host that is used to provide interactive troubleshooting for problems that arise on the system. We believe that the actor chose these task names specifically to blend in and appear to be part of the legitimate WDI.
Figure 1. Legitimate ResolutionHost Task associated with the Windows Diagnostic Infrastructure Resolution host. The tasks running the backdoors appear to imitate this task.
On Aug. 28 and Oct. 22, 2019, the actors created the ResolutionHosts and ResolutionsHosts tasks to run two separate PowerShell-based backdoors. The actors used these two scheduled tasks as a persistence method, as they ran the two PowerShell scripts repeatedly, albeit at different intervals. Table 1 shows the two tasks and their associated creation times, run intervals and the command executed. The commands executed by the two tasks attempt to run splwow64.ps1 and OfficeIntegrator.ps1, which are backdoors that we call TriFive and a variant of CASHY200 that we call Snugy, respectively. The scripts were stored in two separate folders on the system, which is likely an attempt to avoid both backdoors being discovered and removed.
Table 1. Scheduled tasks used to persistently run malicious PowerShell-based backdoors.
The table also shows that the two backdoors were executed at different intervals, with TriFive backdoor running every five minutes and the Snugy backdoor running every 30 minutes. We cannot confirm the exact reason behind the difference in intervals, but it may have to do with the stealthiness of the C2 channel associated with the backdoor. For instance, Snugy may have a longer interval than TriFive as it uses DNS tunneling as a C2 channel, which is a more well-known C2 channel with a higher likelihood of detection compared to the previously unknown email-based C2 channel used by TriFive.
We were not able to confirm how the actors created the ResolutionHosts and ResolutionsHosts tasks. However, we are aware of the actors using batch scripts to create scheduled tasks named SystemDataProvider and CacheTask- when installing Snugy samples on other systems. For instance, the following batch script creates and runs a scheduled task named SystemDataProvider to run the Snugy sample named xpsrchvw.ps1:
TriFive is a previously unseen PowerShell-based backdoor that the xHunt actors installed on the compromised Exchange server, executing every five minutes via a scheduled task. TriFive provided backdoor access to the Exchange server by logging into a legitimate user's inbox and obtaining a PowerShell script from an email draft within the deleted emails folder. The TriFive sample used a legitimate account name and credentials from the targeted organization. This suggests that the threat actor had stolen the account's credentials prior to the installation of the TriFive backdoor.
The use of email drafts and a shared email account between the Trojan and actor to facilitate C2 communications is not a new technique for the actors associated with xHunt. In fact, this same general technique was used by the email-based C2 in the Hisoka tool discussed in the initial publication about the xHunt campaign in September 2019. While the Hisoka tool used email drafts to send and receive data, these drafts remained in the Drafts folder, whereas the TriFive backdoor specifically saves its email drafts to the Deleted Items folder instead.
To issue commands to the backdoor, the actor would log into the same legitimate email account and create an email draft with a subject of 555, including the command in encrypted and base64 encoded format. Figure 2 shows an example command email with a subject of 555 and a message body of woFyeWt3cw==, which decodes and decrypts to whoami. The script would execute this via PowerShell.
Figure 2. Email draft in Deleted Items folder issuing command to TriFive backdoor.
To run the commands supplied by the actor, the PowerShell script logs into a legitimate email account on the Exchange server and checks the Deleted Items folder for emails with a subject of 555. The script opens the email draft, base64 decodes the contents in the message body of the email and decrypts the decoded contents by subtracting 10 from each character. The script then runs the resulting cleartext using PowerShell's built-in Invoke-Expression (iex) cmdlet. After executing the provided PowerShell code, the script will encrypt the results by adding 10 to each character and base64 encoding the ciphertext. TriFive will then send the command results to the actor by setting the encoded ciphertext as the message body of an email draft that it will save in the Deleted Items folder with the subject of 555 s. Figure 3 shows an example email draft in the Deleted Items folder created by the TriFive script to transmit the results of the command issued, which has a subject of 555 s and a message body of bQB5AHgAfgB5AH0AeQBmAGsAbgB3AHMAeABzAH0AfgB8AGsAfgB5AHwA, which decodes and decrypts to contoso\administrator.
Figure 3. Email draft in Deleted Items folder created by TriFive backdoor to send results to C2.
The TriFive PowerShell script does not have any loops to continually run on a system. Instead, TriFive relies on the previously mentioned ResolutionsHosts scheduled task for persistence.
Snugy Backdoor
The OfficeIntegrator.ps1 file seen in the ResolutionHosts task is a PowerShell-based backdoor we call Snugy, which allows an actor to obtain the system's hostname and to run commands. Snugy is a variant of the CASHY200 backdoor used by actors in previous attacks in the xHunt campaign. In July 2019, Trend Micro created a detection signature for this backdoor called Backdoor.PS1.NETERO.A, which suggests that this particular variant of CASHY200 has been around for over a year. We are calling this variant of the backdoor Snugy, as Netero is already a name of a variant of the Hisoka tool used by the xHunt actors.
We observed the following code overlaps between this Snugy tool and CASHY200:
Function used to convert strings to hexadecimal representation.
Function used to generate a string of random upper and lowercase characters.
Regular expression to extract resolved IP address from either the ping or nslookup command, depending on the sample.
Command handler uses the first octet of IP address to determine the command to run.
Command handler has the same two commands available: get hostname and run command.
Much like CASHY200, Snugy uses DNS tunneling to communicate with its C2 server, specifically by issuing DNS A record lookups to resolve custom crafted subdomains of actor-controlled C2 domains. However, the structure of the custom crafted domains differs dramatically from previous CASHY200 samples due to the following:
Variable values for important fields in the subdomain.
Randomly chosen order of the fields in the data section.
Randomly chosen C2 domains for each outbound query.
Can only transmit one byte of data per query instead of 11.
The differences in the subdomains and amount of data that each query can transmit is the main reason we gave this particular sample its own variant name. The Snugy sample was configured to choose one of the following domains at random as its C2 domain:
hotsoft[.]icu
uplearn[.]top
lidarcc[.]icu
deman1[.]icu
Like early variants of CASHY200, the Snugy variant uses the following command to ping a custom crafted domain, which ultimately attempts to resolve the domain before sending the ICMP requests to the resolving IP address:
Snugy will extract the IP address that the ping application resolved using the following regular expression to gather the IP address from the ping results:
This regular expression is publicly available on many sites as a way to extract or validate IP addresses. However, we saw this same regular expression in the CASHY200 tool used in previous xHunt attacks. Snugy also has the same command set available as CASHY200 and uses the first octet to determine the command the actor wishes to run. Table 2 shows the two numbers that will either send the hostname of the system to the C2 or run a command. The first octets of 86 and 102 differ from CASHY200's 48 and 92, but both backdoors use the second octet to determine how many DNS queries the backdoor needs to issue to download the command from the C2.
IP address
Description
86.x.x.x
Runs hostname command and sends results to C2
102.<# of queries>.x.x
Run command via cmd /c and send results to C2
Table 2. Snugy backdoor command handler.
The subdomains created by Snugy include a communication type field, a field specifying the order of elements in the data section, and lastly the data section, as seen in the following C2 domain structure:
<character for communication type><character for order of fields in data section><data section>.<C2 domain>
As previously mentioned, the structure of the subdomain differs dramatically from previous variants. Not only does it introduce multiple possible values for each communication type, but it also includes a random order of fields in the data section of the subdomain as well. The first character in the subdomain generated by Snugy is the communication type, which tells the C2 server the purpose of the inbound DNS query. Table 3 shows the possible characters for each communication type that Snugy will choose at random when constructing the subdomain, as well as the purpose of each type.
Comm Type
Description
'q','b','e','d' or 'm'
Initial Beacon
'z','j','r','p' or 'x'
Sending the hostname as data to the C2 server
's','n','u','g' or 'y'
Requesting a chunk of data from C2 server
'c','f','v','h' or 'k'
Sending the results of command execution as data to the C2 server
'i','t','o','l' or 'w'
Notification of the end of the data transmission
Table 3. Communication types and their purpose in Snugy's DNS tunneling protocol.
The second character in the subdomain generated by Snugy tells the C2 server the order of the fields in the subsequent data section of the subdomain. The data section of the subdomain contains the following three fields and their corresponding 0, 1 or 2 index used by Snugy to specify the order of the fields:
0. 4 hexadecimal characters representing a 2-byte campaign code
1. 2 random characters
2. 2 hexadecimal characters representing one byte of data, followed by a sequence number between 1 and 9
Snugy uses the 0, 1 and 2 index to order the fields in the data section and includes the order character so the C2 understands how to parse inbound queries. Table 4 shows the order of data fields and the corresponding character used to represent the order. It should be noted that the data section is blank in the initial beacon communication type.
Index Order
Character
Structure of data field
012
t
<campaign code><random characters><data and sequence number>
021
m
<campaign code><data and sequence number><random characters>
102
d
<random characters><campaign code><data and sequence number>
120
h
<random characters><data and sequence number><campaign code>
201
p
<data and sequence number><campaign code><random characters>
210
z
<data and sequence number><random characters><campaign code>
Table 4. Order of data fields and the corresponding character used in Snugy's DNS tunneling protocol.
The Snugy DNS tunneling protocol can only send one byte of data per query, making it quite inefficient at exfiltrating data, but the use of DNS A record queries suggests that the DNS tunneling protocol can receive four bytes of data per DNS query. For instance, if the C2 server resolves the beacon query to an IP address that has “86” as its first octet, Snugy will issue the 12 queries to transmit the host name “WIN-DESKTOP” to the C2 server. Table 5 shows these 12 queries with each subdomain parsed as the C2 would upon receipt of the query. This table highlights the inefficiency of this DNS tunneling protocol for data exfiltration.
j (hostname) m (021) 7266 ('rf') 50 ('P' data) 2 (seq) HA (rand)
ot7266Ng502.hotsoft.icu
o (done) t (012) 7266 ('rf') Ng (rand) 50 ('P' data) 2 (seq)
Table 5. Example queries of Snugy sending the hostname over DNS tunneling protocol.
We did observe the threat actors using the Snugy tool to run commands and exfiltrate the results, as we were able to obtain the domains queried via ping requests sent from the compromised server. Based on the exfiltrated data from within the subdomains, we were able to determine the actors ran ipconfig /all and dir. Unfortunately, we only had a subset of the requests so the data exfiltrated was truncated, which also suggests that the actors likely ran other commands that we did not observe.
We found a second Snugy sample on another server at the same Kuwaiti organization with a name of SyncRes.ps1 and a SHA256 hash of a4a0ec94dd681c030d66e879ff475ca76668acc46545bbaff49b20e17683f99c. The actor installed this Snugy sample by saving this PowerShell script to C:\Windows\System32\bg-BG and by creating a scheduled task named ResolutionHosts within the c:\Windows\System32\Tasks\Microsoft\Windows\RAC folder to run the PowerShell script every 20 minutes. This particular Snugy sample only uses one root domain for C2, specifically sharepoint-web[.]com, and uses a different structure for its custom crafted subdomains for its DNS tunnel:
<character for communication type><two random digits>46<3-bytes hexlified data section>.<C2 domain>
This Snugy sample uses a single character from a hardcoded character set at the beginning of the subdomain to signify the communication type. The character sets used for the communication type are the same as the previously discussed OfficeIntegrator.ps1 variant, but with the exception of snugy, the character sets signify different communication types, as seen in Table 6. Table 6 also shows that this sample only has three communication types. The sample does not include the hostname command. Rather, it can only run commands if the C2 answers the beacon query with an IP address with 199 as the first octet.
Comm Type
Description
'i','t','o','l' or 'w'
Initial Beacon
's','n','u','g' or 'y'
Requesting a chunk of data from C2 server
'q','b','e','d' or 'm'
Sending the results of command execution as data to the C2 server
Table 6. Communication types and their purpose in the DNS tunneling protocol found in the second Snugy sample.
Infrastructure Links to xHunt
The infrastructure associated with the activity outlined in this blog involves the five domains that Snugy communicated with as its C2 using DNS tunneling, specifically hotsoft[.]icu, uplearn[.]top, lidarcc[.]icu,deman1[.]icu and sharepoint-web[.]com. While there was not a lot of overlap with other infrastructure, the domain ns1.alforatsystem[.]com resolved to the same IP address as several of the ns1 and ns2 subdomains on the Snugy C2 domains in May 2019, as seen in Table 7.
Domain
Passive DNS
First seen
ns1.hotsoft[.]icu
198.98.48[.]181
05/06/2019 10:48:37 AM
ns2.hotsoft[.]icu
198.98.48[.]181
05/06/2019 10:48:37 AM
ns1.uplearn[.]top
198.98.48[.]181
05/11/2019 11:42:40 AM
ns2.uplearn[.]top
198.98.48[.]181
05/11/2019 11:42:40 AM
ns1.lidarcc[.]icu
198.98.48[.]181
05/08/2019 12:53:29 PM
ns2.lidarcc[.]icu
198.98.48[.]181
05/08/2019 12:53:29 PM
ns1.deman1[.]icu
198.98.48[.]181
05/08/2019 10:30:24 AM
ns2.deman1[.]icu
198.98.48[.]181
05/08/2019 10:30:24 AM
ns1.alforatsystem[.]com
198.98.48[.]181
05/05/2019 8:41:38 AM
ns2.alforatsystem[.]com
198.98.48[.]181
05/05/2019 8:41:38 AM
Table 7. Infrastructure overlap between Snugy C2 domains and a domain previously used in xHunt.
Actors used the alforatsystem[.]com domain to host ZIP archives that they used to deliver LNK shortcut files to install backdoors in previous attacks during the xHunt campaign. The alforatsystem[.]com domain also has significant infrastructure overlap with other domains associated with xHunt as discussed in our previous publications, such as firewallsupports[.]com and pasta58[.]com, among others.
Conclusion
The xHunt campaign continues as threat actors attack organizations in Kuwait. The group shows an ability to adjust their tools with slightly new features and communication channels to avoid detection. Both of the backdoors installed on the compromised Exchange server of a Kuwait government organization used covert channels for C2 communications, specifically DNS tunneling and an email-based channel using drafts in the Deleted Items folder of a compromised email account. Only one variant of the Hisoka tool used in the xHunt campaign has used email drafts and a compromised email account for C2 communications, so it appears that this group is beginning to use an email-based communication channel when they already have access to a compromised Exchange server at an organization.
Palo Alto Networks customers are protected from the attacks outlined in this blog in the following ways:
All known TriFive and Snugy backdoors have malicious verdicts in WildFire.
AutoFocus customers can track the TriFive and Snugy backdoors with the tags TriFive and Snugy.
Cortex XDR blocks both TriFive and Snugy payloads.
As security practitioners, we spend a lot of time focusing on the threat actors and malware families that leverage the most impactful exploits or affect the highest number of victims. But what happens when a threat actor goes “low and slow” to fly under the radar? One could argue that, in that situation, the threat actor may end up having more impact than some of the more prolific threat groups.
We first noticed that there may be a relationship between the Vatet loader, PyXie Remote Access Tool (RAT) and Defray777 ransomware when there were remnants and/or detections of all three in various Incident Response and Managed Threat Hunting engagements. After digging deep into each malware family, it became apparent that Vatet, PyXie and Defray777 are all associated with the same financially motivated threat group that has been operating since as early as 2018.
That threat group, sometimes referred to as PyXie by BlackBerry Cylance and GOLD DUPONT by SecureWorks, has been actively conducting successful ransomware operations that have impacted organizations in a number of sectors including healthcare, education, government and technology while remaining under the radar. This blog aims to shed light on this threat group and to disrupt their operations through awareness of their malware families and operating methodologies. In essence, we want to get them on the radar.
During our research, we discovered that this threat group has developed and maintained the Vatet loader. This loader has evolved as this threat group has taken advantage of multiple open source tools by altering the original application to execute payloads such as PyXie and/or Cobalt Strike. Next, the threat group uses a tailored version of PyXie, which we call PyXie Lite, to conduct reconnaissance and to find and exfiltrate files that are likely sensitive to the victim organization. In a number of incidents we investigated, the actors established an initial foothold into the victim's network through common banking trojans such as IcedID or Trickbot. From there, they deployed Vatet, PyXie and Cobalt Strike before executing Defray777 ransomware entirely in memory. This results in encrypted files on local drives and file shares before exiting. Additionally, the ransomware leaves no evidence of execution except for the encrypted files and ransom notes. In regard to Defray777, the group behind this malware has also ported their ransomware from Windows to Linux, something that, before Defray777, has yet to be seen in the targeted ransomware space. Before this discovery, ransomware that had the ability to impact both Windows and Linux systems was limited to cross-functional ransomware written in Java or scripting languages such as Python. With the port to Linux, Defray777 ransomware has become the first ransomware variant to have standalone executables for Windows and Linux.
With three different malware families to cover, we realize there is a lot of content to digest. We have a lot of great details on each of these, but we also realize that you may be interested in one malware family over the others, or you may just prefer to choose your own adventure. If desired, use the links below to skip to the malware family that interests you most, or to get right to the IOCs that will get you hunting for, and detecting, this threat group in action.
Vatet is a custom loader that executes XOR encoded shellcode from the local disk or a network share. The loaders are typically open source applications found on GitHub, or other repositories, that the actors modify to load their shellcode. In most cases, the payload winds up being Cobalt Strike beacons and/or stagers, but some of the more recent payloads have been an updated version of the PyXie RAT. Vatet is often a precursor to enterprise-wide ransomware attacks.
Microsoft wrote about the Vatet loader in April 2020 and said the loader had been in use as early as November 2018 for the purpose of loading Cobalt Strike into memory for execution. This loader continues to be seen in the wild using multiple versions of open source applications to load shellcode including:
In our research, we have seen Vatet samples with compile times as early as 2019, although this variant has implemented several variations since then.
In the earliest versions of Vatet that we analyzed, the malicious payload was loaded via a network share using a path with the following format: \\{IP}\{EPOCHTIME}\{PAYLOAD}.dat. However, in the latest samples analyzed, the malicious payload was loaded locally from disk. Additionally, we have seen variations in the XOR keys used to decode the payload during execution time. Our research also determined that the Vatet loader has expanded its payload capabilities to load PyXie in addition to the previously seen Cobalt Strike beacons and stagers. Finally, the Vatet loaders we analyzed have evolved and begun taking steps to improve their anti-forensics capabilities by deleting malicious payloads after they have been loaded into memory for execution.
Figure 1. Vatet execution flow.
Let’s take a deeper look at Vatet using a malicious version of Rainmeter.
Inner Workings of the Vatet Loader: A Rainmeter Review
Rainmeter is a desktop customization tool that allows users to customize their desktops through the use of “skins.” During a legitimate installation, Rainmeter creates an executable, rainmeter.exe, and a corresponding DLL, rainmeter.dll. Under normal conditions, rainmeter.dll is responsible for reading configuration files and facilitating a customized desktop. Under the observed circumstances, a signed, legitimate version of rainmeter.exe and a malicious version of rainmeter.dll could be simply copied onto the victim system, then used to load and execute a Cobalt Strike beacon in memory under the context of a signed, legitimate executable.
Taking a Look at the Static Properties
We first reviewed the suspicious rainmeter.exe and rainmeter.dll files and compared them to versions that would be installed on a system through the official September 2019 release of the Rainmeter installer, which can be found on its public GitHub page.
Reviewing rainmeter.exe did not produce many interesting findings. Examining both executables in PEStudio confirmed that the sample recovered during a ransomware scenario was the same executable generated by the standard Rainmeter installer, based on the SHA256 hash. We also verified that both executables had the same valid digital signature.
Figure 2. Initial comparison of static properties of “rainmeter.exe”.
Comparing the rainmeter.dll samples provided more interesting findings. Initially, it was obvious that the two samples were not the same, since the hashes did not line up. The sizes of the files were significantly different from one another and the compile dates were also quite different. Additionally, there was some variability in the imports, exports, strings and other properties. Further, the suspected malicious DLL was not digitally signed and had additional sections not present in the legitimate Rainmeter DLL.
Figure 3. Comparing the two versions of “rainmeter.dll”.Figure 4. Comparing sections between “rainmeter.dll” samples.
It is important to note that the code base for Rainmeter is publicly available on GitHub under the GNU General Public License v2.0. This would have allowed the threat actor to openly review/modify the existing rainmeter.dll file contents and compile it into the suspected malicious DLL we saw during our investigation.
After completing these comparisons to confirm that the Rainmeter DLL was likely malicious, it was time for a deeper and more focused look at the samples using a debugger for dynamic analysis.
Dynamic Analysis of the Malicious Rainmeter Sample
Now that we had identified samples for deeper inspection, we stopped the comparisons to the legitimate Rainmeter application and focused on the analysis of the suspicious samples recovered. We placed the samples of rainmeter.exe and rainmeter.dll recovered from the investigation into our analysis environment and began debugging Rainmeter. Shortly after starting analysis, rainmeter.exe loaded rainmeter.dll as expected, and subsequently called its ordinal 1 exported function. Continuing the execution, there were calls to CreateFileA, where the sample was looking for the hardcoded path C:\Windows\help\options.dat.
Figure 5. Call to “CreateFileA” for a hardcoded path.
After the call to CreateFileA, there is a comparison of the result of the call to CreateFileA to FFFFFFFF to determine if it has a valid handle to the file or not. If there is no valid handle, the program exits.
Originally it was not obvious that options.dat was necessary for the analysis of the malicious Rainmeter sample as .dat files are not part of the normal Rainmeter application. However, a version of options.dat was recovered in order to continue analysis. Once the “dat” file was placed in the expected location, the program then allocated space on the heap and read the contents of options.dat into memory. After the contents of options.dat were read into memory, the sample performed a first-level decoding of the contents by XOR-ing the contents with the value FE.
Figure 6. Initial XOR decoding loop.
Once the first decoding routine is completed, the malicious Rainmeter application closes the handle to options.dat. When the program closes the handle to options.dat, it is removed from the file system. This is a built-in anti-analysis technique employed to hinder recovery of the .dat file for analysis. At this point, the data read into the program was still a blob of unrecognizable code. However, at the end of the XOR decoding routine, there is a CALL EBX instruction that transfers execution to the recently decoded data. Following EBX in the disassembled view shows that this is valid code. At this stage of analysis, Rainmeter has decoded its options.dat payload, loaded it into memory and executed it. Future analysis confirmed that this was the end of the Vatet loader routine, and execution was passed to the Cobalt Strike shellcode loader.
Figure 7. Transfer of execution to valid code after XOR decoding.
By this point, we realized that the Vatet loading mechanism was completed, but we wanted to validate the identity of the final payload, so we pressed on. Further along in the execution, there is a second decoding routine where an additional dynamic XOR loop is used to decode and rewrite the contents of the executable code. If this routine looks familiar, it’s probably because you are noticing the Cobalt Strike decoding mechanism. This routine begins by obtaining a pointer to the first four bytes of the imported executable code and setting it as the starting XOR key. The code then executes a loop acting on four bytes at a time, XORing the imported code with the starting XOR key. Next, the loop writes the XOR’d value back into the data segment, followed by setting a new XOR key. The new XOR key is determined by XOR’ing the current XOR key with the value decoded by the current key. Once this loop is finished, the sample then uses JMP ECX to transfer execution to the recently decoded executable contents.
Figure 8. Entering into the second decoding loop. Note the memory space in Dump 1.Figure 9. After the completion of the second decoding routine, note the executable contents now decoded in Dump 2.
At this stage of analysis, we confirmed the content included in options.dat was shellcode that was later decoded via a dynamic XOR routine to create executable code in Rainmeter’s process memory.
Now that we had the executable contents of the XOR’d executable code from options.dat available in memory, we dumped the contents from the memory map section in x64bdg for additional analysis to determine this code’s potential functionality.
Moving to our dumped sample of the executable code, we conducted an analysis of the strings to determine if there was anything obvious to correlate dynamic analysis findings. In doing this, we identified a reference to beacon.dll, which is most often associated with the DLL version of Cobalt Strike’s beacon. Additionally, loading the isolated PE into PeStudio showed the following references to an exported function _ReflectiveLoader@4, which is a known exported function of Cobalt Strike.
Figure 10. Extracted PE analysis in PeStudio.
To confirm whether the extracted payload was a Cobalt Strike beacon or not, we utilized a Cobalt Strike beacon parser, which dumped the beacon’s decoded configuration.
Figure 11. Cobalt Strike beacon configuration.
The confirmed Cobalt Strike beacon shows a typical implementation of Cobalt Strike’s HTTPS beacon using malleable C2 profiles. Specifically, the Amazon browsing traffic profile created by harmjoy was used in this beacon.
On Sept. 24, 2020, the source code for Windows XP and Windows Server 2003 was leaked and posted on several file-sharing sites such as Mega and 4Chan. Microsoft ended support for Windows XP when it reached its end-of-support date in 2014 and for Windows Server 2003 in 2015. Therefore, any vulnerabilities discovered since then remain unaddressed (with the exception of a patch in 2017 for the WannaCry attack). Although the leaked Windows XP source code might have circulated privately even earlier, the recent leak makes it broadly available for the first time. As a result, more hackers can easily identify potential vulnerabilities for which there are no software fixes.
This blog is a follow-up to the 2020 Unit 42 IoT Threat Report with a focus on the issue of devices running on an end-of-life (EOL) version of Windows and their impact on an organization. We review the data challenges this brings up for organizations and provide information about the best solutions to address the problem. We also provide a list of detailed recommendations to mitigate the impact of this specific incident around the source code leak for Windows XP and Windows Server 2003.
Palo Alto Networks Next-Generation Firewall customers with the Threat Prevention security subscription can protect legacy devices running Windows XP, Windows Server 2003 and other versions of Windows.
The Facts and Challenges
Windows End of Life – Does It Mean End of Use?
IoT devices running EOL Windows operating systems are commonplace in hospitals. This is a particularly big issue for imaging equipment. According to our IoT report, 83% of medical imaging devices run on operating systems that are no longer supported. This is based on an analysis of 1.2 million IoT devices in thousands of physical locations across enterprise IT and healthcare organizations in the United States in 2018 and 2019. Figure 1 shows the prevalence of unsupported operating systems in a typical hospital environment. Windows XP, which Microsoft stopped supporting in 2014, is still being used in 11% of imaging devices.
Figure 1. Operating system usage on imaging devices. (Chart from the 2020 Unit 42 IoT Threat Report.)
A typical mid-size hospital has, on average, 75 different types of medical imaging devices (such as X-Ray machines, MRI machines, CT scanners or ultrasounds) and approximately 100 imaging-related servers or workstations (such as PACS servers or DICOM image viewers). Among these devices, we observed a notable and discouraging trend of continued reliance on devices using Windows XP and Windows Server 2003.
Medical Imaging Device Type
% of devices running
Windows XP or Windows Server 2003
X-Ray Machine
21%
Ultrasound Machine
20%
DICOM Imager
15.3%
Medical Printer
14%
Table 1. Top medical imaging devices running on Windows XP and Windows Server 2003.
Continued use of unsupported software, though prevalent in hospitals, is not restricted to IoT devices in the healthcare industry. We see this issue impacting other industries, such as manufacturing.
Let’s Update! – Or Is It That Easy?
At a glance, this may seem like an easy problem to solve – update the operating system and run up-to-date, supported software on all systems. However, there are administrative and operational challenges that complicate the migration process.
Most organizations manage information technology (IT) and operational technology (OT) as separate teams with separate processes using separate tools. While IT focuses on the organization’s IT assets – such as computers, network equipment and printers – OT focuses on non-IT assets, such as medical devices, factory floor equipment and security cameras. For example, in the healthcare industry, biomedical engineers understand and maintain the medical devices. However, they don’t typically maintain the underlying operating systems that power the devices, nor do they manage the global security policies that govern these systems. The gaps between OT and IT security practices and operations result in ongoing use of devices that continue to run EOL operating systems. As a consequence, these devices are often prone to attacks that IT has been protected from for over a decade.
Updating the software in IoT devices is not as straightforward as updating a normal laptop or desktop, as certain functionalities of the IoT device only work with a specific Windows version. In healthcare specifically, biomedical engineers need to ensure that existing software running on the new versions of Windows complies with FDA regulations and does not introduce any new vulnerabilities for the medical devices.
Additionally, updating an unsupported operating system in healthcare IoT devices requires a certain amount of downtime that might not be feasible, given the nature of the operating environment. It might not be a realistic possibility for all medical facilities to devote the time to do such upgrades and testing, as the hospital may be unable to function at full capacity while devices are down for software maintenance. Lastly, there are cost and resource-allocation challenges to upgrading the entire medical device inventory to a certain operating system.
We observed similar trends when analyzing data from our healthcare customers. At the time of writing, 72% of IoT devices running unsupported versions of Windows were detected more than three months ago, while 30% of all legacy Windows devices were detected more than six months ago. The Palo Alto Networks IoT Security subscription raises an alert to Next-Generation Firewall customers when a device running an EOL Windows operating system is detected. Based on these statistics, we can assume that awareness of the presence of devices running unsupported versions of Windows is not reason enough to persuade customers to update to the latest Windows version. There must be other factors, similar to the ones listed above, that might delay a software update.
Attacks: How Vulnerable Are These Devices?
The Windows XP and Windows Server 2003 operating systems, in addition to no longer being supported by Microsoft, come with a host of vulnerabilities and security threats. Table 2 includes the number of National Institute of Standards and Technology (NIST) vulnerabilities reported for these operating systems. Most common vulnerabilities can allow an attacker to run remote code, cause memory overflow issues or restrict usage of devices by performing a Denial of Service (DoS) attack.
Vulnerability Breakdown
Windows XP
Windows Server 2003
Total CVEs
741
436
Critical CVEs
(CVSS Score > 9.0)
239
127
Denial of Service
144
89
Code Execution
325
190
Overflow
206
133
Memory Corruption
68
44
Cross-Site Scripting
6
7
Gaining Privileges
228
132
Gaining Information
17
14
Directory Traversal
1
1
Bypass
22
9
Table 2. A breakdown of CVEs on Windows XP and Windows Server 2003.
The simplest IoT risk remediation practice is network segmentation. However, due to a large number of medical IoT devices running EOL operating systems, even subnetworks with proper network segmentation are at risk. Based on data collected from about 100 hospital customers, we determined that 12% of all segments with medical devices include at least one device running an outdated Windows version. In such segments, if an attacker can gain access to a Windows XP device, all the other devices in that segment, including critical medical devices, are at risk. Having a vulnerable Windows XP or Windows Server 2003 device increases the attack surface. Moreover, an attacker can move laterally across a network to infect other devices.
In one example, we encountered a healthcare customer with a specific VLAN segment that has only medical and imaging devices. This segment includes devices such as CT scanners, MRI machines, medical dispensing equipment, PACS servers, medical printers, ultrasound machines and X-Ray machines. From the point of view of a security analyst, this VLAN is ideally segmented with no mixing of medical and non-medical devices. However, we determined that a particular CT scanner was running Windows XP. Thus an attacker, by exploiting knowledge from the leaked source code, can attack the device and expose all the other devices in the segment.
The Solution
Palo Alto Networks data shows that Windows XP and other EOL Windows versions are still popular in older IoT and OT devices. Many of these devices are mission-critical and yet difficult to manage. It is often a daunting task to upgrade them without the risk of introducing a network-wide interruption to business operations. As a result, most businesses choose not to do so. This is especially true in the healthcare industry. In a typical hospital, Windows XP can still be found running on various types of devices such as CT scanners, X-Ray machines, nuclear medicine imagers, patient monitors, DICOM viewers, medical workstations and even some older printers. What makes things difficult is that the majority of IoT and OT devices frequently use customized software, configurations and limited hardware resources, such as memory or CPU power. As a result, an endpoint security solution is unlikely to sufficiently protect against vulnerabilities.
As a consequence of these obstacles, IoT and OT devices can essentially be rendered un-upgradable, and with viable endpoint solutions often out of the question, how can organizations stay protected from the threats that rely on exploits collected over hundreds of existing vulnerabilities? The answer lies in network behavior monitoring and network traffic analytics powered by artificial intelligence and machine learning.
Figure 2 illustrates the network behavior of a healthcare customer’s nuclear medicine imager that is operating within normal parameters and another with suspicious traffic patterns that is running on Windows 2000 (as an aside, this particular device is still being used in a hospital at the time of writing). In this case, network behavior refers to how various applications running on the device connect to remote destinations to provide or acquire network-based services. When the device is infected by malware, its network behavior becomes anomalous compared to its normal operating state. In Figure 2, in its normal state, the nuclear medicine imager only has a regular connection to a PAC server using the DICOM application. But when the imager is infected by malware, the malware takes control on the device and starts making dozens of network connections in order to find more nearby devices that are also vulnerable, allowing it to move laterally on the network.
Figure 2. A comparison of normal and victimized network behavior. The chart on the lower left reflects normal application usage, such as SMB and DICOM, to a couple regular network destinations. In contrast, the chart on the right shows very aggressive network behavior from a device infected by malware, involving many simultaneous connections to almost all surrounding devices. This is a clear sign of the malware attempting to move laterally.
Traditionally, threat detection relies on deploying thousands of rules that look for predetermined byte patterns in the network payload. But it is not capable of detecting zero-day attacks or network behavior changes as a result of the attacks. To discover changes in network behavior and detect attacks like this, A machine learning based solution has been proved to be more effective. Machine learning algorithms can be used to inspect the network traffic, discover and learn the repeatable behavior patterns carried in the traffic and then build that into mathematical models that serve as the network behavior baseline for an IoT device. Corresponding detection algorithms can then be put in place using these models to predict attacks when a deviation from the device’s network behavior baseline is observed.
Often, a single detection of a behavior pattern change might not provide enough information to draw a conclusion. Naturally, a sequence of anomalous events that match an attack scenario could become more definitive proof. Machine learning techniques are good at picking up time sequences automatically and correlating seemingly unrelated events based on what is learned and captured from massive amounts of data. When we put together all the data collected from thousands of hospitals of various sizes and in various environments, we can obtain an accurate picture of how a type of medical device behaves on the network under normal operating conditions, compared to when it is under attack. This type of approach would work well to address the challenges brought by EOL operating systems still running on these devices.
However, to truly secure IoT and OT devices, a solution can’t stop at monitoring and detecting behavioral anomalies or attempting to associate them with certain attack scenarios. The network behavior needs to be controlled with a good set of security policies, which can be effective at stopping the behavior before the attack is set in motion. This can be best achieved by integrating IoT monitoring with a next-generation firewall. When the user is allowed to create a policy based on the device identity and the operating system used, bad behaviors can be easily blocked and filtered out. Artificial intelligence and machine learning technologies excel at summarizing trends from trained models to make policy recommendations, which can then be converted into usable, real-world security policies. This feature is available for Palo Alto Networks Next-Generation Firewall customers through the IoT Security subscription.
With AI and ML-based network behavior baselining, combined with security policy recommendations, any risks and consequences from the Windows XP code leak can be contained and mitigated. When reviewing all the recommended actions, an IT security organization should prioritize having an effective IoT security solution whenever unsupported operating systems are present within the network.
Conclusion
One of the biggest challenges for securing IoT and OT devices comes from software upgrades. Many IoT and OT devices have long life cycles, but are nearly impossible to keep up to date with the latest software release. It is often a norm to find these devices running on outdated or EOL operating systems. EOL operating systems such as Windows XP and Windows Server 2003 have hundreds of known vulnerabilities. Malicious actors rely on these vulnerabilities to penetrate organizations’ OT networks. Many organizations will undoubtedly try hard to upgrade their traditional cyber defense in order to detect exploits on known vulnerabilities, in an attempt to maintain a balance in security when upgrading the device OS is not seen as an option. Unfortunately, this is often a losing battle.
The recent Windows XP and Windows Server 2003 code leak has finally pushed the delicate balance to a tipping point. The source code offers malicious actors infinite possibilities to discover new vulnerabilities and improve their techniques. IoT and OT devices running EOL operating systems could become the stepping stone to attackers breaching and defeating an organization’s cyber defense.
In the meantime, AI and ML-based security solutions that focus on network behavior analysis have been effective in dealing with advanced threats and zero-day attacks. They offer new hope for organizations to regain balance and control in their cyber defense.
The following are our recommendations:
Restrict systems running Windows XP or Windows Server 2003 from browsing the internet and microsegment them from other network segments.
Implement Zero Trust policies to allow only necessary applications, sources and destinations.
Enforce strong password policies on systems running Windows XP and Windows Server 2003.
Closely monitor incoming and outgoing traffic for unusual activity on ports for commonly used services that include but are not limited to the following:
SMB on UDP 137 and 138, and TCP 139 and 445
RDP on TCP 3389
SQL Server on TCP 1433
Note: Default port numbers are shown, but use the ports specific to your deployment if they’ve been changed.
Enable threat prevention technologies such as the Palo Alto Networks Threat Prevention security subscription for Next-Generation Firewalls for legacy devices running Windows XP, Windows Server 2003 and other versions of Windows.
Palo Alto Networks Threat Prevention can detect over 280 Windows XP CVEs and over 150 of the Windows Server 2003 CVEs. If a CVE exploit is detected in your system, drop or reset the connection to disable such attacks.
Implement or enforce an incident response policy that quickly disconnects a suspicious or compromised machine from the network.
Implement or enforce cloud or offline backups for machines running Windows XP or Windows Server 2003. Saving data to the cloud or an offline server is a safety precaution in case your organization ever gets hit with ransomware.
On Oct. 28, 2020, the Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI) and the Department of Health and Human Services (HHS) released a joint cybersecurity alert regarding an increased and imminent cybersecurity threat to the U.S. healthcare system.
Threat operators have displayed a heightened interest in targeting the healthcare and the public health sector, potentially disrupting healthcare services and operations. Activities observed include the use of Trickbot malware, a well-known information stealer that can lead to the installation of other malicious files, including Ryuk ransomware.
This alert comes shortly after Universal Health Services (UHS) reported a Ryuk ransomware attack that disrupted all U.S. UHS sites for weeks. Other U.S.-based hospitals have reported similar ransomware attacks, including a hospital in Oregon and one in New York. Similarly, a health tech organization in Philadelphia was also the target of a ransomware attack.
Palo Alto Networks security subscriptions for the Next-Generation Firewall with WildFire detects activity associated with Trickbot and Ryuk. The DNS Security subscription is able to detect the Anchor_DNS DNS tunneling described in this blog. Cortex XDR also contains an Anti-Ransomware Protection module and an Anti-Malware Protection module, which target encryption-based activities associated with ransomware and other malicious file behaviors. Additionally, AutoFocus customers can review activity related to this threat activity with the following tags: Ryuk, Trickbot and BazaLoader.
Malware Overview
Trickbot is modular malware that provides backdoor access, enabling operators to distribute additional malware onto victim systems, and includes other capabilities such as worm functionality and system enumeration. One of the newest modules, Anchor_DNS, is used for DNS tunneling during command and control (C2) actions.
The Anchor_DNS module uses PowerShell to run scripts and makes multiple DNS requests including connectivity checks to benign legitimate domains. Malware often does this to confirm an active network connection that will allow the threat operator to communicate with that system during C2 activities. The following legitimate domains may be used during this check:
ipecho[.]net
api[.]ipify[.]org
checkip[.]amazonaws[.]com
ip[.]anysrc[.]net
wtfismyip[.]com
ipinfo[.]io
icanhazip[.]com
myexternalip[.]com
Table 1. Legitimate domains used by Trickbot Anchor_DNS module to conduct internet connectivity checks.
Ryuk ransomware is typically denoted by a file named “RyukReadMe” placed onto the system. This ransomware is often seen at the end of multi-stage attacks involving malware such as Trickbot and, more recently, BazaLoader (also known as "BazarLoader"). In many cases, Ryuk is not loaded onto the system until weeks or months after the initial infection. Ryuk operators learn the victim network by enumerating the impacted environment with tools that may be familiar to that environment, such as PowerShell and Windows Management Instrumentation.
Prior to encryption, the following commands may be run on a compromised system:
You can review the joint cybersecurity advisory for additional details on Ryuk and Trickbot activities associated with the targeting of Healthcare and the Public Health Sector.
The initial intrusion vector for both Trickbot and BazaLoader infections is most often observed through malicious emails.
You can find recently confirmed Trickbot samples on MalwareBazaar and additional information on Trickbot modules on the Unit 42 blog.
Recent samples of Ryuk and BazaLoader can also be found on MalwareBaazar.
This section documents the relevant tactics and techniques associated with Ryuk and Trickbot activities and maps them directly to Palo Alto Networks product(s) and service(s). Palo Alto Networks customers can utilize this table to verify current configurations within their environments.
†These capabilities are part of the NGFW security subscriptions service.
Conclusion
Ryuk ransomware infections often result from multi-stage threat activities originating from malware such as Trickbot and BazaLoader. Once the backdoor malware is established, attackers use tools such as PowerShell and CobaltStrike to attain remote connection and drop Ryuk onto the compromised system, sometimes weeks to months after initial infection.
The U.S. Government has deemed this threat activity as an imminent threat to Healthcare and the Public Health Sector industry.
Indicators associated with this Threat Assessment and the joint cybersecurity alert are available on GitHub, have been published to the Unit 42 TAXII feed and are viewable via the ATOM Viewer:
Palo Alto Networks security subscriptions for the Next-Generation Firewall with WildFire detect activity associated with Trickbot and Ryuk. The DNS Security subscription is able to detect the Anchor_DNS DNS tunneling described in this blog. Cortex XDR also contains an Anti-Ransomware Protection module as well as an Anti-Malware Protection module, which targets encryption-based activities associated with ransomware and other malicious file behaviors. Additionally, AutoFocus customers can review activity related to this threat activity with the following tags: Ryuk, Trickbot and BazaLoader.
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.
Domain parking services offer a simple solution for domain owners to monetize their sites’ traffic through third-party advertisements. While domain parking might appear harmless at first glance, parked domains pose significant threats, as they can redirect visitors to malicious or unwanted landing pages or turn entirely malicious at any point in time.
We have been detecting parked domains for more than nine years. From March to September 2020, we identified 5 million newly parked domains. In the same time frame, we observed that 6 million parked domains have transitioned to other categories. Out of the transitioned parked domains, 1.0% changed to malicious categories (such as phishing or malware); 2.6% changed to not safe for work categories (such as adult or gambling); and 30.6% changed to suspicious categories (such as questionable or high Risk). Compared to a benign domain (such as computer and internet info or shopping), a parked domain has an eight times higher probability of changing its category to one of the above non-benign categories.
In this blog, we further investigate the domain parking ecosystem and outline different types of abuse, including:
Domain registration abuse: We observed the malicious life cycle of the domain valleymedicalandsurgicalclinic[.]com, which is no longer active, as part of a global Emotet campaign. Emotet is one of the most popular malware families distributed via phishing emails. During this campaign, Palo Alto Networks observed attacks against organizations in various industries (such as education, government, energy, manufacturing, construction and telecommunications) all over the world, including the United States, the United Kingdom, France, Japan, Korea and Italy. The attack targeting French organizations also exploited the COVID-19 global pandemic: It used Covid19 as the phishing email’s subject line. None of these attacks were successful.
Advertisement abuse (case 1): We observed attackers abusing the domain peoplesvote[.]uk related to the current U.S. presidential election. While visiting peoplesvote[.]uk, users are presented with an ad listing page most of the time. However, occasionally, users are first redirected to 0redira[.]com/jr.php, which hosts an exploit kit script, and subsequently users are redirected to a survey website asking about users’ voting preference of Joe Biden or Donald Trump. The exploit kit script hosted on 0redira[.]com/jr.php fingerprints the browser silently to track users’ web activity and hides the landing URLs to prevent security companies and researchers from analyzing and blocking them. Of note, these pages are still active as of this writing.
Advertisement abuse (case 2): Furthermore, we observed a domain, xifinity[.]com, mimicking xfinity[.]com. When a user attempts to visit the Xfinity website but accidentally types an additional "i," they will go to xifinity[.]com and will be redirected to an abusive landing page, antivirus-protection[.]com-123[.]xyz. Both domains are active as of this writing. The landing page tries to fool users into believing that their machine is infected and that their McAfee subscription has expired. Clicking on the “Proceed” button will redirect users to a legitimate McAfee download page offering an antivirus subscription. We believe that attackers are abusing McAfee’s affiliate program to steal ad revenue.
Security best practice for enterprises is to keep close track of parked domains, while consumers should make sure that they type domain names correctly and double-check that the domain owners are trusted before entering any site.
Palo Alto Networks Next-Generation Firewall customers can block the parked category with the URL Filtering and DNS Security subscriptions.
Domain Parking: Why and How
Individuals and enterprises need to pay registrars (ICANN accredited domain resellers) an annual fee to buy domain names and become domain owners. If domain owners don't have content or service ready to point their domains to, they can leverage parking services to monetize user traffic. Setting up a parking service is simple and only requires domain owners to point their name server (NS) records to the parking service. In return, parking services will either present visitors with a list of advertisements or automatically redirect users to advertisers' webpages. In the first case, domain owners and parking services get paid when a user clicks on an ad, while in the second case, they get paid per user visit. Some domain owners buy large amounts of domain names as an investment to resell them later for a profit or to monetize user traffic. As shown by previous research studies and this blog, parked domains can pose significant threats to end-users. Because of this, along with their questionable utility, it may be best to block parked domains.
Palo Alto Networks has deployed a comprehensive pipeline to track newly parked domains and to publish the detection results to URL Filtering. Recently, we have launched the parked category in DNS Security as well. In particular, our pipeline:
Monitors known parked service providers and their infrastructure.
Tracks domain registrations and passive DNS queries and performs reverse DNS lookups.
Crawls website content.
Employs machine learning to combine multiple features to classify whether a domain is parked.
High-Level Statistics
To analyze the current parked domain landscape, we collected the parked domains that were detected from March to September 2020, as well as the ones whose category changed from parked to other categories in the same time span. On average, we found that 27,000 newly parked domains were identified and 35,000 existing parked domains were re-classified daily. In summary, our pipeline has identified 5 million newly parked domains and re-classified 6 million parked domains to other categories in the past six months.
Figure 1 summarizes how we observed parked domains changing during this time period. For simplicity, we group the URL Filtering categories into four classes: malicious, not safe for work, suspicious and benign. The malicious class consists of malware, command and control (C2), phishing and grayware. Adult, gambling and nudity are represented in the not safe for work class. For suspicious, we include questionable, insufficient content and high risk domains. Sites are deemed questionable based on suspicious web content, while the insufficient content category is normally applied to a blank website and high risk means the domain displays behavior similar to malicious domains. The benign class encompasses all other categories, such as business and economy, computer and internet info and shopping. Figure 1 shows that for parked domains, the malicious change rate is 1.0%, the not safe for work change rate is 2.6% and the suspicious change rate is 30.6%. As a comparison, the non-benign change rate of the parked category is eight times higher than the non-benign change rate of benign categories.
Figure 1. A list of categories that parked domains we observed changed to in the last six months.
Figure 2 presents the distribution of the number of days that domains that we ultimately categorize as malicious and benign are parked before changing their category. We aggregate the number of category changes from parked for every 10 parked days and normalize by the total number of domains per class. Figure 2 shows that over 25.9% of parked domains that changed to malicious categories are parked for less than 10 days, which is significantly different from benign, where the majority of them are parked for around 60-69 days. We conjecture that many cybercriminals do not age their domains (a practice used to evade domain lifetime-based detection features) and use them to conduct attacks as soon as possible.
Figure 2. The number of days a domain is parked before a category change occurs, based on observations made during the last six months.
The Ecosystem and Attack Vectors
In this section, we further investigate the benefits of detecting and blocking parked domains. We begin by dissecting the domain parking ecosystem into different stakeholder groups. We then show that the largest attack vector is domain registration, since attackers can register parked domains and turn them malicious at any time. Second, we show that attackers can abuse the lack of advertisement control by some smaller advertisement networks used by parking services, thereby redirecting visitors to malicious or unwanted landing pages. Last, we show that even a parking service itself can pose privacy threats to users.
Stakeholders
We show the major stakeholder groups in the domain parking ecosystem and their relationships in Figure 3, namely domain owners, parking service providers, advertisement networks and advertisers. Note that the term stakeholders as used here represents roles and can refer to the same entity or multiple entities. Domain owners own parked domains and have the incentive to monetize through parking service providers. Parking service providers incorporate and organize feeds from advertisement networks to monetize user traffic. Advertisement networks characterize user traffic from parked domains and present ads to users from interested advertisers.
Figure 3. Stakeholders in the domain parking ecosystem and their relationships.
As mentioned previously, domain owners need to point their NS records to the parking service’s name server to “park” their domains. We measured the popularity of service providers by checking the DNS NS records of parked domains detected from March to September 2020. Figure 4 presents the top 15 most popular NS domains. The majority of parked domains are resolved by the NS of large registrars, including GoDaddy (domaincontrol[.]com) and NameBright (namebrightdns[.]com). Besides the large registrars and hosting providers, we identified several dedicated parking service providers. The most popular dedicated provider is Sedo (sedoparking[.]com), which is used by 19.5% of parked domains.
Figure 4. A list of parking service providers including registrars, hosting providers and dedicated parking providers.
Domain Registration Abuse
Parked domains could present threats to users when they turn malicious. Figure 1 shows that 1.0% of parked domains eventually changed to malicious categories such as C2 and malware. Some attackers appear to host parked pages on their domains before deploying malicious content, potentially to amortize their costs.
For example, we observed the malicious life cycle of the domain valleymedicalandsurgicalclinic[.]com. This domain was registered on July 8, 2020. Our newly registered domain detector found this domain, and our parking detector pipeline classified it as parked based on the website content. Two months later, our malware analysis engine, WildFire, captured multiple malware instances, such as SHA256: a9fe73484674696be756808e93f839be7157cd65995d8de9e67e40bf77c9b229 and 54ac560845b09ce00a48b604ac7c440331cbde4362839a3dbf14c378230bee21 hosted on the URL valleymedicalandsurgicalclinic[.]com/ujftb/statement/wr7hoba7i9hz since Sept. 14, 2020. Furthermore, we discovered that it's part of a global Emotet campaign (refer to our recent Emotet blog for more information). Emotet is one of the most popular malware families distributed via phishing emails. The documents attached to the phishing emails contain macro scripts that call back to the C2 servers from victims’ machines. Emotet further downloads Trojan payloads that steal victims' credential information or even compromises their machines. We can see many suspicious behaviors from these files, including incorrect file extensions and communication with multiple C2 servers, such as 50.91.114[.]38 and 51.38.124[.]206. We sketch the phases of the Emotet campaign in Figure 5.
The observed campaign was launched using multiple domains around the world. During this campaign, Palo Alto Networks observed attacks against organizations in various industries (such as education, government, energy, manufacturing, construction and telecommunications) all over the world, including the United States, the United Kingdom, France, Japan, Korea and Italy. The attack targeting French organizations also exploited the COVID-19 global pandemic: It used Covid19 as the phishing email’s subject line (refer to our COVID-19 scams blog for similar cases). None of the attacks were successful.
Figure 5. Illustration of the phases of the Emotet campaign.
Advertisement Abuse
The domain parking ecosystem depends on advertisers to profit from user traffic. As discussed earlier, parking services either show users a list of ads (and get paid based on the number of user clicks on these ads) or redirect users automatically to the advertisers’ webpages (and get paid based on the number of user visits). Often the parking services and the advertisement networks do not have the means or willingness to filter abusive advertisers (i.e. attackers). Therefore, users are exposed to various threats, such as malware distribution, potentially unwanted program (PUP) distribution and phishing scams. In our experience, we most frequently observe the distribution of grayware.
We observed attackers abusing the domain peoplesvote[.]uk related to the current U.S. presidential election, which was allowed by the lack of control by above[.]com, the seventh-most popular domain parking service, as shown in Figure 4. While visiting peoplesvote[.]uk, users are presented with an ad listing page most of the time, as shown in Figure 6. However, occasionally, users are first redirected to 0redira[.]com/jr.php, which hosts an exploit kit script, and subsequently redirected to a survey website asking about users’ voting preference, as shown in Figure 7. The exploit kit script hosted on 0redira[.]com/jr.php fingerprints the browser silently to track users’ web activity and hides the landing URLs. Of note, these pages are still active as of this writing.
Figure 6. The ad listing page often seen while visiting peoplesvote[.]uk.Figure 7. The voting preference landing page that is sometimes seen after visiting peoplesvote[.]uk and being redirected to a survey website.Furthermore, we observed attackers abusing the largest dedicated parking service provider, Sedo. We found a parked domain, xifinity[.]com, that is a typosquatting domain mimicking xfinity[.]com (refer to our cybersquatting blog or this academic paper for more information). When a user attempts to visit the Xfinity website but accidentally types an additional "i," they will go to xifinity[.]com and will be redirected to an advertiser page. We identified that the traffic to this domain is sold to multiple advertisers. One of the advertisers, softonic[.]com, presents users with a software download page.
Besides legitimate advertisers, we also captured multiple redirections to PUPs from attackers. Figure 8 shows one of the abusive landing pages, the level-squatting domain antivirus-protection[.]com-123[.]xyz. The landing page tries to trick users into believing that their machine is infected and that their McAfee subscription has expired. Clicking on the “Proceed” button will redirect users to a legitimate McAfee download page offering an antivirus subscription. We believe that attackers are abusing McAfee’s affiliate program to steal ad revenue.
As a squatting domain, xifinity[.]com receives a high visit volume compared to other parked domains. We observed over 1,000 DNS requests for xifinity[.]com in our passive DNS dataset from June to September 2020, and the domain is still active as of this writing – as is antivirus-protection[.]com-123[.]xyz. From a domain owner’s perspective, using a parking service is a convenient way to monetize user traffic. However, as abusive advertisers (i.e. attackers) are not filtered, users are exposed to various threats.
Figure 8. The landing page impersonating McAfee while visiting xifinity[.]com.
Parking Service Abuse
We observed several parked pages using ztomy[.]com, the 14th-most popular parking service provider (shown in Figure 4), harvesting visitors' personal information. We observed that these pages generate fingerprints of users' browsers and send them back to the parked domain. The parked pages are using the browser fingerprinting script from pxlgnpgecom-a.akamaihd[.]net/javascripts/browserfp.min.js, which collects various private information and tracks user behavior. These browser fingerprints could be leveraged to track visitors’ online activities, allowing advertisement networks to target visitors with ads tailored to them. Additionally, domain owners complained online that their domains' NS records were configured to ztomy NS servers without their awareness, which could be considered a form of domain hijacking.
Figure 9. An example of a parked domain, bridgeplatform[.]biz, using ztomy[.]com as the parking service provider.
Conclusion
In summary, parked domains can expose users to threats as they can redirect visitors to malicious or unwanted landing pages or turn entirely malicious in the future. Due to their questionable utility and the fact that our system can quickly re-classify parked domains when they merit new categories, we suggest that Palo Alto Networks Next-Generation Firewall customers block the parked category with URL Filtering or DNS Security. While this may be deemed a bit overly cautious by some due to potential false positives, we suggest alerts be set up for additional visibility at the bare minimum.
Palo Alto Networks Next-Generation Firewall customers are protected against malicious indicators (domain, IP, URL, SHA256) mentioned in this blog via URL Filtering, DNS Security and Threat Prevention subscription services.
Acknowledgements
We would like to thank Wei Wang and Ryan Nangong for their help with providing some of the data sources necessary for our analysis. We would also like to extend our gratitude to Jimmy Chen and Jun Javier Wang for their advice and help with improving the blog.
Executive Summary
![If the freed MS_T120 channel object is reclaimed with a fake MS_T120 channel object, the following function execution route can be controlled with a function call (call [eax]) in which the function pointer (register eax) is obtained from inside the fake MS_T120 channel object. Red boxes highlight key sections of code. A green box highlights code that avoids crash. A blue box highlights a bypass check.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/12/word-image-6.png)
![The debug log shown here shows how to get the fake object address at the offset 0x8c and make a function call (call [eax]) to control EIP.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/12/word-image-9.png)
![This breaks down how commonly web skimmer samples from family7 used different C2 servers. Results range from 21,122 instances of usage of "onlinestatus[.]site" to 157 instances of usage of "web-stat.me"](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/11/word-image-10.png)
![A list of domain parking service providers, sorted by popularity. Top providers are domaincontrol[.]com, sedoparking[.]com, namebrightdns[.]com, bodis[.]com and parking crew[.]net](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/10/chart-2.png)
![This shows how peoplesvote[.]uk often appears – a parked domain with ad listings.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/10/word-image-40.png)
![This shows what sometimes occurs after visiting peoplesvote[.]uk - a voting preference landing page.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/10/word-image-41.png)
![This screenshot shows how bridgeplatform[.]biz appears with ads from domain parking service provider ztomy[.]com](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/10/word-image-43.png)
Get updates from Unit 42 