Subdomain Reputation: Detecting Malicious Subdomains of Public Apex Domains

Posted on by Samantha Stallings

Executive Summary

Cybercriminals regularly leverage popular dynamic domain name system (DDNS) or web hosting services to store and distribute their content. Threat actors leverage these for command and control (C2), malware distribution and phishing. This abuse has created the need for new detection methods for malicious subdomains.

DDNS and web hosting services often allow people to serve content from subdomains of a domain registered by the service provider. These subdomains offer the possibility of detecting malicious activity at the level of the DNS, but to do so is more difficult than detecting malicious registered domains.

Malicious domain detection has typically relied on information that may not be available for these subdomains of registered domains. For example, WHOIS information can reveal whether a domain has recently been registered, and (in some cases) who registered the domain. WHOIS information is not available for the subdomains of public apex domains, though.

Given this lack of information typically used to detect malicious domains, identifying malicious subdomains requires new methods. Palo Alto Networks has developed a system to detect malicious subdomains of public apex domains.

The detections generated by this detector are available to Palo Alto Networks Next-Generation Firewall customers with Cloud-Delivered Security Services, including DNS Security and Advanced URL Filtering.

Related Unit 42 Topics DNS

The DNS and Delegation

The DNS serves as the directory of the internet: a globally distributed database containing information about all the domain names that exist within the internet. To store and retrieve information for the vast number of domains in use, the DNS depends on delegation.

Various groups – including companies, governments and educational institutions – are responsible for managing portions of the DNS namespace. These groups control what domains are registered within the portion of the namespace they manage. They also maintain records for these domains and run servers that distribute those records.

For example, Verisign manages the .com top level domain (TLD). Verisign works with registrars to allow people to register names in the .com TLD, such as paloaltonetworks[.]com. It also maintains nameservers that refer people to where they can find information about these domains.

Similarly, Palo Alto Networks manages paloaltonetworks[.]com. We create subdomains, such as www[.]paloaltonetworks[.]com, and ensure DNS records for those subdomains are available in authoritative nameservers.

Delegation of responsibility for a domain usually happens when a domain is registered. Top level domains (TLDs) such as .com or .edu are, of course, special cases. The Internet Assigned Numbers Authority (IANA) delegates authority for TLDs through processes unique to TLDs. At lower levels of the DNS namespace, where most of the delegating action occurs, responsibility for a domain belongs to the party that registers the domain.

Typically only the party that registers a domain uses that domain (known as the apex domain) and its subdomains to provide content or services. For example, only Palo Alto Networks uses paloaltonetworks[.]com and its subdomains. For some registered domains, however, many parties may control subdomains. We refer to these domains as public apex domains. Figure 1 illustrates the two scenarios.

The case in which multiple parties control subdomains of a registered domain frequently occurs when the domain registrant runs a service that allows people to claim subdomains of its registered domain. Dynamic DNS providers and web hosting platforms frequently provide this option.

Image 1 is a diagram of the use of registered domains including top level domains (TLDs). From the root, a .com TLD can be either the apps page of Palo Alto Networks or the main Palo Alto Networks site. Other registered domains include duckpins.org sites.
Figure 1. Scenarios for use of registered domains.

While the providers can – and often do – remove malicious domains and content, they are not creating the content or services represented by these subdomains. This arrangement creates challenges for detecting malicious subdomains.

Malicious Domain Detection

Malicious domain detection relies on various sources of information. First, we can observe attacks and blocklist the domains involved. This is a standard and helpful approach, but it only covers a portion of the threats evident in the DNS. Also, as a reactive measure, it may detect malicious domains too late to stop many attacks.

Other approaches look at the characteristics of observed domain names or their subdomains to determine if they are likely to have been generated by a domain generation algorithm (DGA), or used for DNS Tunneling. Still more can be learned from assessing a domain’s reputation.

Reputation comprises information about a domain such as age, usage patterns, popularity, what IP addresses it uses and what other domains use the same IP addresses. Newly registered domains or domains that have been dormant since registration (strategically aged domains) are treated with caution.

If a domain resolves to IP addresses in diverse networks over a short period, it is likely to be a fast-flux domain. These are just some of the ways in which a domain’s characteristics build its reputation and suggest whether it’s malicious. For subdomains of public apex domains, though, much of this information is not available or not helpful.

Malicious Subdomains: A New Challenge

DDNS is a technology that allows domains to map to different IP addresses over time without requiring network operators to manually change DNS records. Some providers of DDNS services allow people to manage subdomains of the provider’s registered domains.

For example, No-IP offers people the ability to create subdomains under 80 of its registered domains, including ddns[.]net and couchpotatofries[.]org. Similarly, FreeDNS enables users to claim subdomains of several thousand domains such as chickenkiller[.]com and undo[.]it. These free subdomains allow users who do not want to go to the expense or trouble of registering a domain to use the DNS for locating their servers.

Other services easing entry into the internet include various hosting platforms. Many well-known companies offer tools and resources that allow users to easily create and distribute content.

These providers may also offer people free subdomains from which to serve their content. For example, bloggers can share stories from subdomains of blogspot[.]com, researchers can showcase their projects at subdomains of github[.]io and companies building websites with Netlify can host those sites from subdomains of netlify[.]app.

Some providers of public apex domains have a large number of users and thus they have a non-trivial impact on the shape of DNS traffic. For example, in a day’s worth of Palo Alto Networks passive DNS data, the records for 93% of the top-level domains contained fewer than 87,000 unique registered domains. This is fewer than the number of subdomains seen for public apex domains such as github[.]io, netlify[.]app or ddns[.]net.

In the same passive DNS dataset, the number of subdomains for netlify[.]app was greater than the number of registered domains for the .tokyo and .work TLDs, both of which are in the top 10 TLDs for grayware use. Of course, these public apex domains only account for a tiny portion of the DNS traffic seen. Nonetheless, the fact that they have more subdomains than many TLDs demands that we consider their unique dynamics and how well we can characterize their subdomains.

This consideration becomes more pressing given attackers’ proclivity to use subdomains of public apex domains in their campaigns. Attackers regularly leverage DDNS to manage their infrastructure. Examples of this include C2 servers for Adwind malware and hosts used for COVID-19 related phishing campaigns.

Other malicious campaigns have incorporated various hosting services. For example, the Aggah campaign used Blogger to serve malicious scripts, and attackers have hosted various phishing campaigns on GitHub Pages.

Detecting which subdomains of public apex domains are malicious presents several unique challenges, as traditional approaches might not work or could require adjustments. Domain name characteristics are still somewhat helpful. For example, a random domain name like yjhtbgvfdcsdx[.]duckdns[.]org or a group of very similar domain names (e.g., nicetshirt171[.]blogspot[.]com, nicetshirt180[.]blogspot[.]com, nicetshirt186[.]blogspot[.]com) are inherently suspicious.

However, there are complications to using these characteristics for detection. Some providers might offer default algorithmically generated subdomain names that are DGA-like or very similar to each other. These characteristics would trigger many false positives if we used typical DGA detection approaches.

Establishing subdomain reputation is also more difficult than with registered domains. Information from WHOIS data does not help, as that pertains to the apex domain, not the subdomain itself.

Similarly, information about nameservers or sibling domains is not helpful, as the service provider manages the nameserver, and sibling domains are owned by thousands of different users. IP reputation might still help with DDNS domains, but for subdomains belonging to hosting providers, IP address information is practically useless. These subdomains resolve to the providers’ IP addresses which, like the nameservers, are shared by thousands of subdomains controlled by unrelated parties.

In short, traditional approaches to building domain reputation are insufficient to characterize subdomains of public apex domains. We need new approaches, and that is what Palo Alto Networks has developed.

Detecting Malicious Subdomains of Public Apex Domains

The system Palo Alto Networks has developed for detecting malicious subdomains of public apex domains uses the same basic principles as traditional malicious domain detection approaches. They check for suspicious lexical characteristics, and evaluate reputation. However, the methods for determining what is suspicious and for finding clues to reputation have changed.

Since many typical sources of information are no longer available, we have to be creative, consider a greater variety of inputs, and filter the inputs based on providers’ practices and policies. Putting these inputs together, we can start to characterize subdomains of public apex domains.

Our detectors currently focus on subdomains of a half dozen public apex domains chosen for evaluation largely based on how often their subdomains are reported by our other detectors. The detector identifies an average of over 300 new subdomains per day (shown in Figure 2).

Image 2 is a chart ranging from mid-December 2022 to mid-January 2023, showing the average over time of newly detected subdomains, which is over 300. There are peaks in late December and early January.
Figure 2. Number of newly detected subdomains per day.

Subdomains detected include those used for sites serving various scams, adult content, and other questionable or malicious content. Two of the more interesting cases we observed include a large-scale SMS phishing campaign and a free Robux scam.

Case One: SMS Phishing

For several months, our system has detected subdomains of duckdns[.]org involved in a campaign to distribute malware and steal credentials. The threat actor group Roaming Mantis runs the campaign, which targets mobile device users in several countries.

An attack typically starts with SMS phishing messages, and it is designed to have victims install the MoqHao malware (Android users) or to steal victims’ credentials (iPhone users). Attackers use geofencing to ensure only visitors from the target regions reach the landing page.

The attack regularly evolves. In mid-2022, we observed a portion of the campaign targeting au ID users. An au ID is an ID created by a Japanese telecommunications provider that allows users to easily perform actions such as accessing account information or making purchases.

Originally, the attack was different for Android and iPhone users, but after several weeks, we observed a change in the strategy. Figure 3 shows the structure of the campaign when we originally observed it (March 2022).

Image 3 is a tree diagram showing the structure of an observed Roaming Mantis campaign in March 2022. It starts with an automatic redirect. There are different outcomes depending on whether the target is using an Android or an iPhone.
Figure 3. Structure of Roaming Mantis campaign observed in March 2022.

The attack started with a web page that automatically redirected users. On the second page, the user was redirected based on the user agent (shown in Figure 4).

Image 4 is a screenshot of many lines of code that show the redirection of the user dependent on Android or iPhone.
Figure 4. Redirection based on user agent.

If the user agent was iPhone, the visitor was redirected to a login page posing as an au ID login, but it was actually located at a duckdns[.]org DGA-like subdomain (shown in Figure 5a). If the user agent was Android, victims were redirected to a page where they are encouraged to install a service that was purported to detect annoying or fraudulent SMS and calls (shown in Figure 5b). Again, this page looked similar to those belonging to au ID, but it was located at a DGA-like duckdns[.]org subdomain.

Image 5a is a screenshot of a fake login page that iPhone users were sent to.
Figure 5a. Fake login page to which iPhone users were originally sent.
Image 5b is a screenshot of a fake login page that Android users were sent to. It shows a warning popup that encourages the user to download software.
Figure 5b. Page to which Android users were redirected, encouraging users to download software.

By early June 2022, the attack had changed as shown in Figure 6, and victims using both Android and iPhone ended up at the same page.

Image 6 is a tree diagram showing the structure of an observed Roaming Mantis campaign in June 2022. Unlike the campaign of March 2022, it ends with both iPhone and Android users getting a request for payment. It starts with an automatic redirect.
Figure 6. Structure of Roaming Mantis campaign observed in June 2022.

In this version of the campaign, the page with the agent-based redirect still appeared in the chain, but both redirects led to pages with the same message. This page informed visitors they have an unpaid balance in electricity charges, and warned that their power would be stopped if they did not pay immediately (shown in Figure 7a).

Following the link to make the payment led to another page with a form in which visitors could fill in information for V-Preca (prepaid Visa) cards in order to make payments for the fake charges (shown in Figure 7b). The payments, of course, go to the attacker.

Image 7a is a screenshot of a page requesting payment for a fake charge for an electricity bill.
Figure 7a. Page warning visitors to pay bill.
Image 7b is a screenshot of a page with a form for visitors to enter payment information. The payment will go directly to the attacker.
Figure 7b. Form where visitors can enter V-Preca card information for payment.

Case Two: Free Robux Generator

Since the middle of December 2022, our detection system has identified over 3,000 subdomains of a popular blog hosting service involved in a phishing campaign targeting Roblox users. Roblox’s platform is free, but users can purchase Roblox currency – called Robux – to access certain perks in the Roblox virtual world. Until recently, most Roblox users were under the age of 13, and children make up a large portion of the platform's users. Roblox’s site expressly states that there is no such thing as free Robux, but that has not stopped scammers from trying to convince people otherwise.

The blogs involved appear to be automatically generated using a few templates, and they include text or images related to Roblox (shown in Figure 8).

Image 8 is two screenshots side by side. They are examples of blogs using a free Robux (the currency of Robox) scam. Left is a page for Runners Path Codes and right is a page for Fasthink. Both pages seem to have auto-generated content.
Figure 8. Examples of blogs used in free Robux scam.

Scripts on these pages redirect automatically to bux[.]wellter[.]de. Visitors might need to click through browser warnings, but those who do arrive at a page offering free Robux (shown in Figure 9).

Image 9 is a screenshot of a page that advertises free Robux, with the headline text “Roblox robux generator” and a button to generate.
Figure 9. Site advertising free Robux.

After running the generator, visitors are redirected again to a page at appinstallcheck[.]com listing several possible tasks users might need to perform in order to complete verification. These tasks include installing software, entering a contest to win money, or using a tool to monitor credit scores (shown in Figure 10).

Image 10 is a screenshot that shows what happens once the “generate” button is hit in image 10. A page is shown titled “Get Free Robux — Verify” where the user is asked to complete offers with five buttons of different options.
Figure 10. After requesting free Robux, users are required to complete two more tasks.

Conclusion

Systems to detect malicious subdomains of public apex domains cannot simply employ the same approaches traditionally used to detect malicious registered domains. These subdomains have unique characteristics that require defenders to adapt methods to establish subdomain reputation. Developing such methods is an important task for security researchers and network defenders.

Palo Alto Networks assigns detected subdomains of public apex domains to the grayware category through our Cloud-Delivered Security Services. These subscriptions include DNS Security and Advanced URL Filtering.

Additional Resources

 

Answers to Unit 42 Wireshark Quiz, February 2023

Posted on by Brad Duncan

Executive Summary

This blog presents the answers for our February 2023 Unit 42 Wireshark quiz. The information is ideal for security professionals who investigate suspicious network activity in an Active Directory (AD) environment, but everyone is welcome to review. To get the most benefit, readers should understand basic network traffic concepts and be familiar with Wireshark.

If you’d like to view the version without answers, please see the standalone quiz post.

Related Unit 42 Topics pcap, Qakbot, Qbot, spambot VNC, Wireshark, Wireshark Tutorial

Table of Contents

Scenario, Requirements and Quiz Material
Quiz Questions
Quiz Answers
Pcap Analysis: Victim Details
Pcap Analysis: Identifying the Malware
Pcap Analysis: Post-infection Traffic
Pcap Analysis: Follow-up Spambot Activity
Pcap Analysis: Follow-up VNC Activity
Pcap Analysis: ARP Scanning
Pcap Analysis: File Transfer Over SMB
Conclusion
Indicators of Compromise
Additional Resources

Scenario, Requirements and Quiz Material

The pcap for this month’s Wireshark quiz is from an AD environment, and it contains real-world traffic from a simulated enterprise setting. Details of the local area network (LAN) from the pcap follow.

  • LAN segment range: 10.0.0[.]0/24 (10.0.0[.]0 through 10.0.0[.]255)
  • Domain: work4us[.]org
  • Domain Controller IP address: 10.0.0[.]6
  • Domain Controller host name: WORK4US-DC
  • LAN segment gateway: 10.0.0[.]1
  • Land segment broadcast address: 10.0.0[.]255

Our investigation for this month’s quiz requires Wireshark. This blog utilizes a recent version of Wireshark, and we recommend at least version 3.x.

Participants should have some basic knowledge of network traffic fundamentals. We also recommend readers customize their Wireshark display to better analyze web traffic. A list of tutorials and videos is available. As always, we recommend using Wireshark in a non-Windows environment like BSD, Linux or macOS when analyzing malicious Windows-based traffic.

To obtain the pcap, visit our GitHub repository. Download the ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.

Quiz Questions

This month’s Wireshark quiz asks participants to write an incident report on the activity, as described in the February 2023 standalone quiz post. The incident report should consist of three sections:

  • Executive Summary: State in simple, direct terms what happened (when, who and what).
  • Victim Details: Victim’s IP address, MAC address, Windows hostname and Windows user account name.
  • Indicators of Compromise (IoCs): IP addresses, ports, domains and URLs associated with the infection. SHA256 hashes if any files from the infection can be extracted from the pcap.

Quiz Answers

The incident report should look similar to the following write-up.

Executive Summary:

On 2023-02-03 at 17:04 UTC, a Windows computer used by Damon Bauer was infected with Qakbot (Qbot) malware. The Qakbot infection may have spread to the domain controller.

Victim Details:

  • IP address: 10.0.0[.]149
  • MAC address: 00:21:5d:9e:42:fb
  • Host name: DESKTOP-E7FHJS4
  • Windows user account: damon.bauer

IoCs:

Malicious network traffic

  • Port 80 - hxxp://128.254.207[.]55/86607.dat
  • 102.156.32[.]143:443 - HTTPS/SSL/TLS traffic
  • 208.187.122[.]74:443 - HTTPS/SSL/TLS traffic
  • 5.75.205[.]43:443 - HTTPS/SSL/TLS traffic
  • 23.111.114[.]52:65400 - TCP traffic
  • 78.31.67[.]7:443 - TCP traffic for VNC activity
  • Various IP addresses over TCP ports 25 and 465 - SMTP traffic to servers on various email domains
  • ARP scanning from the infected Windows host
  • File transfer over SMB between the infected Windows host and the domain controller

Malware:

  • SHA256 hash: 713207d9d9875ec88d2f3a53377bf8c2d620147a4199eb183c13a7e957056432
  • File size: 1,761,280 bytes
  • File location: hxxp://128.254.207[.]55/86607.dat
  • File description: Malicious 32-bit DLL for Qakbot
  • Run method: rundll32.exe [filename],Wind
  • Sample available at MalwareBazaar.

Pcap Analysis: Victim Details

Our analysis assumes you have customized Wireshark according to our tutorials or workshop videos.

First, determine the victim’s details.

The common internal, non-routable IP address from this pcap is 10.0.0[.]149. To find it, use the basic web filter provided in our Wireshark tutorials, or type the following in your Wireshark filter bar:

(http.request or tls.handshake.type eq 1) and !(ssdp)

The results in the column display should show the source IP address as 10.0.0[.]149. The frame details section provides a corresponding MAC address of 00:21:5d:9e:42:fb as shown in Figure 1.

Image 1 is a screenshot of Wireshark that highlights the source IP column (Src), the source MAC address when filtering the web traffic.
Figure 1. Filtering on web traffic to find the victim’s IP and MAC address.

Network Basic Input/Output System (NetBIOS) Name Service (NBNS) traffic or Server Message Block (SMB) traffic may also provide a victim’s Windows host name. Use the following filter in Wireshark:

nbns or smb or smb2

The default host name for a Windows 10 or Windows 11 computer is a 15-character string. The name starts with DESKTOP- and is followed by an alphanumeric string of seven additional ASCII characters. We find DESKTOP-E7FHJS4 in the column display and frame details as shown in Figure 2.

Image 2 is a screenshot of Wireshark showing how to find the Windows host name in the traffic, highlighted with arrows.
Figure 2. Finding a Windows host name in NBNS or SMB traffic.

Kerberos authentication traffic is generated when a user logs in, and it may provide a Windows user account name in the pcap. Filter on kerberos.CNameString and scroll to the end of the results in your column display. Select one of the last few frames in the column display. Go to the frame details section and expand the Kerberos line. Keep expanding values until you find the CNameString that has a value of damon.bauer, as shown in Figure 3.

Image 3 is a screenshot of Wireshark highlighting the CNameString column, showing how to find the victim’s Window user account name in the Kerberos traffic.
Figure 3. Finding the victim’s Windows user account name in Kerberos traffic.

As stated in our tutorial on identifying hosts and users, you can select the CNameString value and apply it as a column in your Wireshark display. The result is a CNameString column as shown above in Figure 3.

Pcap Analysis: Identifying the Malware

After gathering the victim’s details, determine when the malicious traffic started. First, check unencrypted HTTP traffic for any unusual URLs. Modify our basic web filter by removing tls.handshake.type eq 1, so we only see the HTTP requests over TCP port 80. Your Wireshark filter will look like this:

http.request and !(ssdp)

The filter reveals only two results in our Wireshark column display. The second result is an HTTP GET request to cacerts.digicert[.]com, which is typical traffic generated by the operating system or seen during routine web browsing.

The first result is an HTTP GET request to an IP address, which is highly suspicious.

Follow the TCP stream on that suspicious HTTP GET request to 128.254.207[.]55 for 86607.dat. The TCP stream window shows minimal request headers, and the server returns a Windows executable (.exe) or DLL file as shown in Figure 4.

Image 4 is a screenshot of Wireshark showing how to navigate through the menus in order to follow the TCP stream. The TCP window shows the curl as user-agent in the request header as well as the indicators of a Windows .exe or .dll file.
Figure 4. Highly suspicious HTTP traffic over TCP port 80.

Use the File → Export Objects → HTTP menu path to export 86607.dat from the pcap as shown in Figure 5.

Image 5 is a screenshot of Wireshark shows the process of exporting an HTTP object from the File menu.
Figure 5. Exporting the file returned from 128.254.207[.]55 using Wireshark’s Export Objects function.
In a Linux or macOS environment, we can easily check the file type of this exported object using a terminal window and the file command. The file command reveals that 86607.dat is a Windows DLL file, as shown in Figure 6. Check the SHA256 hash using the shasum -a 256 command, also shown in Figure 6.

Image 6 is a screenshot of the Linux terminal window showing how to check the file type and the hash in the terminal.
Figure 6. Determining the file type and SHA256 hash in a Linux terminal window.

Searching the SHA256 hash on VirusTotal reveals that several vendors detect this file as malware. This file has also been submitted to MalwareBazaar and identified as Qakbot. The URL hosting this file is also identified as Qakbot on URLhaus.

This type of unencrypted HTTP request is usually the first malicious traffic from a Qakbot infection. The HTTP request for 86607.dat happened on Feb. 3, 2023 at 5:04 p.m. UTC, which is our start time for this infection.

Pcap Analysis: Post-infection Traffic

In February 2020, we published a Wireshark tutorial on examining Qakbot infection traffic. Qakbot has evolved since then, but many characteristics remain the same. Current identifiers for Qakbot post-infection activity include:

  • HTTPS traffic directly to IP addresses using self-signed certificates with random values in the certificate issuer fields
  • HTTPS traffic directly to an IP address using a self-signed certificate spoofing vipsauna[.]com
  • HTTPS traffic to several legitimate domains used for connectivity checks as we previously tweeted about for previous Qakbot infection traffic
  • Traffic over TCP port 65400

Please note that threat actors often contact legitimate websites to check an infected host’s internet connectivity. For example, Qakbot has used www.openssl[.]org for connectivity checks during the past several years, and the site is not malicious.

Qakbot often leads to:

  • Spambot traffic over ports for Simple Mail Transfer Protocol (SMTP)
  • Cobalt Strike activity
  • Virtual network computing (VNC) traffic

We might see any combination from those three activities. For example, we reported Cobalt Strike and VNC activity from a Qakbot-infected host in January 2023.

To find HTTPS traffic sent directly to an IP address, use the following Wireshark filter:

tls.handshake.type eq 1 and !(tls.handshake.extension.type eq 0)

This reveals HTTPS web traffic without any associated domain, as shown in Figure 7.

Image 7 is a screenshot of Wireshark showing how to filter the HTTPS traffic with a Wireshark filter, highlighted in green in the image.
Figure 7. Filtering for HTTPS web traffic directly to IP addresses.

Use the Statistics → Endpoints menu path and review filtered results for all IPv4 addresses, as shown in Figure 8.

Image 8 is a screenshot of Wireshark showing how to use the Statistics menu to access Endpoints and see the statistics for the filtered results.
Figure 8. Endpoint statistics for IPv4 addresses on the filtered results.

The results consist of four IP addresses. One is the internal IP address of our infected Windows host. The other three are Qakbot servers for command and control (C2) traffic. The three Qakbot C2 server addresses are:

  • 102.156.32[.]143
  • 208.187.122[.]74
  • 5.75.205[.]43

Confirm these are Qakbot C2 servers by reviewing their HTTPS certificate data from the pcap. Use the following filters, one for each IP address:

  • tls.handshake.type eq 11 and ip.addr eq 102.156.32[.]143
  • tls.handshake.type eq 11 and ip.addr eq 208.187.122[.]74
  • tls.handshake.type eq 11 and ip.addr eq 5.75.205[.]43

Use the above filter for 102.156.32[.]143 and select the frame result. Expand the frame details following the certificate fields until you reach the rdnSequence section for the certificate issuer (shown in Figure 9).

Image 9 is a screenshot of Wireshark highlighting, in red, the rdnSequence section of the certificate issuer data (highlighted with arrows).
Figure 9. Certificate issuer data for Qakbot C2 server at 102.156.32[.]143.
Certificate issuer data for HTTPS traffic from the server at 102.156.32[.]143 is:

  • it-ad-countryName=NL
  • it-ad-stateOrProvinceName=TA
  • it-ad-localityName=Lix Mngham
  • it-ad-organizationName=Ardx Qcej Kudefrqoi Tqkofhsie
  • it-ad-commonName=ujcbhafnfs.mobi

These appear to be random characters in most of the fields for the certificate issuer. We should find similar certificate issuer data for 208.187.122[.]74 as shown in Figure 10.

Image 10 is a screenshot of Wireshark highlighting, in red, the rdnSequence section of the certificate issuer data (highlighted with arrows).
Figure 10. Certificate issuer data for Qakbot C2 server at 208.187.122[.]74.
Certificate issuer data for HTTPS traffic from the server at 208.187.122[.]74 is:

  • it-ad-countryName=PT
  • it-ad-stateOrProvinceName=OC
  • it-ad-localityName=Ariy
  • it-ad-organizationName=Stecisp Ondpsqg Ajfqkosna
  • it-ad-commonName=ptvcdl.mobi

As shown in Figure 11, the certificate issuer data from 5.75.205[.]43 is different from the other two Qakbot C2 servers:

  • it-ad-countryName=US
  • it-ad-stateOrProvinceName=CA
  • it-ad-localityName=Los Angeles
  • it-ad-organizationName=vipsauna[.]com
  • it-ad-commonName=vipsauna[.]com

Image 11 is a screenshot of Wireshark highlighting, in red, the rdnSequence section of the certificate issuer data (highlighted with arrows).
Figure 11. Certificate issuer data for Qakbot C2 server at 5.75.205[.]43.
This certificate does not have random characters in the issuer fields, and it lists vipsauna[.]com in the organizationName and commonName fields. The traffic is not actually from vipsauna[.]com, and this appears to be a self-signed certificate.

Registered since 2012, the domain vipsauna[.]com has not resolved to any IP address for the past several years. This same certificate issuer has also been noted from at least one other Qakbot C2 IP address in 2022.

Another identifier of Qakbot activity is traffic over TCP port 65400. To review it, use the following Wireshark filter:

tcp.port eq 65400 and tcp.flags eq 0x0002

The results should look similar to Figure 12.

Image 12 is a screenshot of Wireshark showing the Qakbot traffic after selecting the TCP Stream option.
Figure 12. Finding and reviewing Qakbot traffic over TCP port 65400.

This traffic uses 23.111.114[.]52 for its IP address. The TCP stream reveals the infected host’s identification string and public IP address within the first 80 bytes of traffic. In this case, the identification string is jzbxct683972, and the public IP address is 71.167.93[.]52. Of note, this information was altered in the pcap to help sanitize network traffic for this month’s exercise. These are neither the actual identification string nor the real-world public IP address.

Pcap Analysis: Follow-up Spambot Activity

Various reports have linked Qakbot to different ransomware groups. Qakbot has most recently been associated with the Black Basta ransomware gang. On a Qakbot-infected host, ransomware groups use tools like Cobalt Strike to gain a foothold, map the internal network and perform lateral movement.

The AD environment used for this month’s pcap does not provide a high-value target for ransomware groups. However, Qakbot infections in this type of environment can still lead to follow-up actions like Cobalt Strike malware, VNC activity and spambot traffic.

For this month’s exercise, our pcap from the Qakbot infection contains probable spambot activity and VNC traffic.

To check a pcap for possible spambot activity, filter on smtp in Wireshark. This results in several lines of unencrypted SMTP traffic in the Wireshark column display (shown in Figure 13).

Image 13 is a screenshot of Wireshark showing the filtered unencrypted SMTP traffic.
Figure 13. Filtering for SMTP traffic in Wireshark.

Windows clients in an AD environment should not establish connections with several different public email servers in a short period of time. This is an indicator of spambot activity. Determine how many SMTP connections occurred with the following Wireshark filter:

smtp.req.command contains "EHLO"

Your results should look similar to Figure 14.

Image 14 is a screenshot of Wireshark showing the refined filtering for SMTP activity.
Figure 14. Refined filtering for SMTP activity.

The filter reveals our infected Windows host contacted at least five email servers in approximately 10 to 11 minutes. But this only represents SMTP traffic that is either unencrypted or encrypted after establishing the SMTP connection. The following Wireshark filter presents more accurate indicators of spambot activity:

tls.handshake.type eq 1 and (tcp.port eq 25 or tcp.port eq 465 or tcp.port eq 587

Your results should look similar to Figure 15.

Image 15 is a screenshot of Wireshark showing the refined filtering for TLS encrypted email traffic.
Figure 15. Filtering for TLS encrypted email traffic.

This Wireshark filter looks for TLS connections over the three most common TCP ports used in SMTP traffic: port 25, port 465 and port 587. As Figure 15 shows, our new filter reveals at least 25 email servers contacted in approximately 19 to 20 minutes. This is more clearly an indicator of spambot activity.

Check if any emails were sent over unencrypted SMTP traffic by using the File → Export Object → IMF menu path as shown in Figure 16. Unfortunately, in this case, no spambot emails are available to export.

Image 16 is a screenshot of Wireshark showing how, after selecting the IMF option from Export Objects from the File menu does not result in anything in the popup window.
Figure 16. No luck exporting any emails from unencrypted SMTP traffic.

Pcap Analysis: Follow-up VNC Activity

VNC is a graphical desktop sharing system that uses the remote framebuffer (RFB) protocol to control another computer. Over a network, someone running VNC transmits keyboard and mouse input to a targeted computer and receives graphical updates from the targeted computer’s screen.

VNC has legitimate use cases, but threat actors occasionally use VNC to maliciously control an infected Windows host. Such VNC traffic can be found in this month’s pcap.

For the past several months, VNC activity from Qakbot infections has used 78.31.67[.]7 over TCP port 443. Use the following filter in Wireshark to find this traffic:

ip.addr eq 78.31.67[.]7 and tcp.flags eq 0x0002

This filter reveals the start of two TCP streams for VNC traffic as shown in Figure 17.

Image 17 is three screenshots of Wireshark showing how to access the VNC traffic from the Qakbot infection, showing two streams in total.
Figure 17. VNC traffic from the Qakbot infection.

VNC traffic in the pcap consists of two TCP streams. The first stream contains a sequence of 13 bytes that continually repeat with some minor variations. The second stream is noticeably larger and contains RFB content. The ASCII characters VNC appear about 40 bytes into the second TCP stream.

These traffic patterns are typical for VNC traffic from Qakbot infections.

Pcap Analysis: ARP Scanning

Address resolution protocol (ARP) scans are occasionally used by threat actors to discover other active IP addresses in a compromised network.

ARP scanning happens at the MAC address layer, where a MAC address sends ARP queries to the broadcast MAC address at ff:ff:ff:ff:ff:ff for all IP addresses within a network segment. The goal is to determine if any other IP addresses are assigned to a MAC address.

ARP queries from a Windows client for sequential IP addresses in a network segment indicate ARP scanning.

In this month’s pcap starting from 7:22 p.m. UTC, the infected host at 00:21:4d:9e:42:fb broadcasts ARP queries for every IP address in the network segment, starting with 10.0.0[.]254 and sequentially working down to 10.0.0[.]2. The only addresses not included in the ARP scan are known IP addresses like:

  • The infected Windows host at 10.0.0[.]149
  • The domain controller at 10.0.0[.]6
  • The network segment gateway at 10.0.0[.]1
  • The segment broadcast address at 10.0.0[.]255

To find this traffic, use the following Wireshark filter:

arp and eth.dst eq ff:ff:ff:ff:ff:ff

The results should look similar to Figure 18.

Image 18 is a screenshot of Wireshark showing the result of using the Wireshark filter arp and eth.dst eq ff:ff:ff:ff:ff:ff. Highlighted is where the arp scanning starts.
Figure 18. ARP scanning from the Qakbot-infected host.

During the ARP scan, if the infected Windows host finds any other active IP addresses on the network segment, it sends a ping echo request over ICMP. If the targeted address responds, the infected Windows host then probes it by attempting to connect over various TCP or UDP ports.

For this month’s pcap, the only other IP addresses are the domain controller and the network segment gateway. No other clients or servers are active in this AD environment.

Filter on icmp to see the infected Windows host ping the domain controller and the network segment gateway. Filter on ip.addr eq 10.0.0[.]1 to view TCP and UDP ports probed by our infected Windows host.

ARP scanning and subsequent probing of any active IP addresses is not limited to Qakbot infections. We have seen similar activity from hosts infected with Bumblebee, IcedID, Emotet and other malware families.

Pcap Analysis: File Transfer Over SMB

Server Message Block (SMB) protocol enables file transfers between Windows hosts. The ultimate goal of threat actors who have gained access to a Windows client in an AD environment is to gain administrative access to the environment’s domain controller.

In an AD environment, the Windows client routinely communicates with the domain controller as part of normal system operations. However, certain types of activity like file transfers over SMB can be suspect.

To find file transfers over SMB, use the File → Export Objects → SMB... menu path as shown in Figure 19.

Image 19 is a screenshot of Wireshark showing how to select SMB from the Export Objects in the File menu.
Figure 19. Menu path to export SMB objects in Wireshark.

This reveals normal file activity, but we also see some suspicious files as highlighted in Figure 20.

Image 20 is a screenshot of Wireshark showing the exported SMB object list. Suspicious files are highlighted.
Figure 20. Wireshark’s export SMB object list, with the suspicious files highlighted.

Windows EXE or DLL files in SMB traffic can be suspicious, but this activity can also represent a legitimate use case. For example, Windows Server Update Service (WSUS) deploys Microsoft updates from servers within an AD environment. WSUS generates file transfers over SMB traffic consisting of EXE and other files.

But randomly named EXE or DLL files are highly suspicious. These types of files from the export SMB object list follow.

(Read: hostname - file size - file name)

  • \\10.0.0[.]6\Shared - 1,761 KB - \efweioirfbtk.dll
  • \\10.0.0[.]6\Shared - 105 bytes - \efweioirfbtk.dll.cfg
  • \\10.0.0[.]6\C$ - 1,761 KB - \umtqqzkklrgp.dll
  • \\10.0.0[.]6\C$ - 105 bytes - \umtqqzkklrgp.dll.cfg
  • \\10.0.0[.]6\ADMIN$ - 1,761 KB - \ltoawuimupfxvg.dll
  • \\10.0.0[.]6\ADMIN$ - 105 bytes - \ltoawuimupfxvg.dll.cfg

The above list contains file names with seemingly random letters, and they are associated with the domain controller. They have either a .dll file extension or a .dll.cfg file extension.

From the export SMB object list window, select each of these files and export them from the pcap. In a macOS or a Linux environment, check the file types and SHA256 hashes using a terminal window as shown in Figure 21.

The 105 byte .bin.cfg files are data binaries, and the 1,761 KB .dll files are all Windows DLL files with a SHA256 hash of 713207d9d9875ec88d2f3a53377bf8c2d620147a4199eb183c13a7e957056432. This is the same SHA256 hash for the initial Qakbot DLL sent over HTTP traffic at the beginning of the infection.

Image 21 is a screenshot of the Linux terminal window showing how to determine the file types and hashes exported from the SMB traffic.
Figure 21. Determining file types and SHA256 hashes of the files exported from SMB traffic.

These Qakbot DLL files are listed with the domain controller in the export SMB object list. Our infected Windows host apparently sent these files to the domain controller. This implies the domain controller may have a vulnerability that allows malicious file transfer.

To better understand the SMB traffic used for these file transfers, filter on smb2 and scroll through the results. While reviewing SMB traffic, examine the Info column in your Wireshark column display. The frame details section contains additional data to further illustrate activity from the Info column.

In a real-world scenario with similar activity, analysts would also investigate the domain controller. However, our pcap only contains traffic to and from the infected Windows client. We do not have traffic from the domain controller to the internet or to other hosts.

Further investigation is not required for this month’s Wireshark quiz. But the pcap will remain available for additional review if participants want to hone their traffic analysis skills.

Conclusion

This blog provides answers to our Unit 42 Wireshark quiz for February 2023. We reviewed traffic from the pcap and presented an incident report based on the infection.

Many organizations lack access to full packet capture in their IT environment. As a result, security professionals may lack experience in reviewing network traffic. Training material like this Wireshark quiz can help. Pcap analysis is a useful skill that helps us better understand malicious activity. Incident reports help investigators organize their findings in a more easily digestible format, and security professionals with incident report-writing experience are better able to recognize similar activity. A well-written report helps other people within your organization take appropriate steps to prevent the incident from happening again.

You can also read the original post, without answers, for this month’s Unit 42 Wireshark quiz.

Palo Alto Networks customers receive protections from this type of malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services including WildFire and Advanced Threat Prevention.

If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

Infrastructure

  • hxxp://128.254.207[.]55/86607.dat
  • 102.156.32[.]143:443
  • 208.187.122[.]74:443
  • 5.75.205[.]43:443
  • 23.111.114[.]52:65400
  • 78.31.67[.]7:443
  • SHA256 hash for Qakbot DLL file
  • 713207d9d9875ec88d2f3a53377bf8c2d620147a4199eb183c13a7e957056432

Additional Resources

Updated March 15, 2023, at 8:58 a.m. PT.

Unit 42 Wireshark Quiz, February 2023

Posted on by Brad Duncan

Executive Summary

Welcome to the February 2023 Unit 42 Wireshark quiz. This blog presents a packet capture (pcap) of malicious activity and asks participants to write an incident report. A separate Unit 42 blog post will present the answers: an example of an incident report and detailed explanations for the report content.

These quizzes are designed for security professionals who investigate suspicious network activity, but anyone can participate. To get the most benefit, readers should understand basic network traffic concepts and be somewhat familiar with Wireshark.

The material provides experience reviewing real-world traffic from a live setting. This month’s Wireshark quiz uses a pcap of infection activity from an Active Directory (AD) environment.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial

Scenario

The pcap for this month’s Wireshark quiz is from an AD environment, and it contains real-world traffic from a simulated enterprise setting. Details of the local area network (LAN) from the pcap follow.

  • LAN segment range: 10.0.0[.]0/24 (10.0.0[.]0 through 10.0.0[.]255)
  • Domain: work4us[.]org
  • Domain Controller IP address: 10.0.0[.]6
  • Domain Controller host name: WORK4US-DC
  • LAN segment gateway: 10.0.0[.]1
  • Land segment broadcast address: 10.0.0[.]255

Requirements

This quiz requires Wireshark to review pcap files. However, Wireshark’s default settings are not optimized for web-based traffic commonly generated by malware. Therefore, we encourage participants in this quiz to customize Wireshark after installing it. To help, Unit 42 has published a series of tutorials and videos that include customizing Wireshark.

We recommend using a 3.x or later version of Wireshark, since it has more features, capabilities and bug fixes over previous Wireshark versions.

Furthermore, we recommend using a non-Windows environment like BSD, Linux or macOS to analyze malicious traffic. Malware traffic could contain malicious code targeting Microsoft Windows. This presents a risk of infection if participants use a Windows computer to analyze the pcap.

Quiz Material

To obtain the pcap for this month’s quiz, visit our GitHub repository. Download the ZIP archive and extract the pcap as shown below in Figures 1 and 2. Use infected as the password to unlock the ZIP archive.

Image 1 is a screenshot of Wireshark software showing where to click to download the ZIP archive from GitHub. The inset window shows where to put the zip file name.
Figure 1. Download the ZIP archive containing the pcap from our GitHub repository.
Image 2 shows how to extract the password-protected .zip archive from the download folder, entering the password and specifying the extraction location.
Figure 2. Extract the pcap file from the password-protected ZIP archive.

Incident Report Format

In this scenario, quiz participants provide an incident report to document the infection. Depending on your workplace requirements, incident report formats vary. For this month’s Unit 42 Wireshark quiz, we recommend a generic format applicable to many situations. Our recommended incident report format contains the following three sections:

  • Executive summary
  • Victim details
  • Indicators of compromise (IoCs)

The executive summary is a paragraph describing the incident. This should give the reader a clear idea of what happened. The executive summary states the type of malicious activity and any corrective actions taken. An example follows.

On 2023-02-01 at 12:53 UTC, a Windows computer used by John Doe was infected with unknown, Windows-based malware. Security confiscated the infected host at 13:15 UTC, then help desk personnel wiped and re-imaged it. John Doe changed his login password and was instructed to change any other passwords used on the infected computer.

Most of the summary lists corrective actions. But our quizzes focus on analysis of the event, so we only require the first sentence.

On [date] at [time in UTC], a Windows computer used by [victim’s name] was infected with [name of malware, if known].

The victim details section contains the following information:

  • Victim’s IP address
  • Victim’s MAC address
  • Victim’s Windows host name
  • Victim’s Windows user account name

In the AD environments used for our Wireshark quizzes, all Windows user account names are formatted as firstname.lastname. For example, the user account for someone named John Doe would be john.doe.

Finally, the IoCs section consists of IP addresses, port numbers, domain names and URLs associated with the infection. Include file information if any malicious binaries from an infection can be exported from the pcap, like SHA256 hash and file size.

Conclusion

When network traffic is available, pcap analysis of an infection provides valuable insight on the activity. This insight helps security personnel identify the victim and determine the time of infection. Data from a pcap might also provide indicators that help identify the malware.

Reviewing traffic from real-world infections can help members of the security community secure their networks and better protect our digital way of life. Incident reports help investigators organize their findings in a more easily digestible format. Security professionals who write incident reports are better able to recognize similar activity. A well-written report helps other people within the organization take appropriate steps to prevent the incident from happening again.

The answers to this month’s Unit 42 Wireshark quiz will be published in a separate blog post on Monday, Feb. 27.

Palo Alto Networks customers receive protections from Qakbot and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services, including WildFire and Advanced Threat Prevention.

If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Additional Resources

Mirai Variant V3G4 Targets IoT Devices

Posted on by Zhibin Zhang

Content Warning

We are providing a content warning because the following contains usage of a racial slur by a threat actor, which is not condoned in any instance by Unit 42. Unit 42 has partially redacted the racial slur to provide researchers with the ability to identify it and check IoCs as needed.

Executive Summary

From July to December 2022, Unit 42 researchers observed a Mirai variant called V3G4, which was leveraging several vulnerabilities to spread itself. The vulnerabilities exploited include the following:

Once the vulnerable devices are compromised, they will be fully controlled by attackers and become a part of the botnet. The threat actor has the capability to utilize those devices to conduct further attacks, such as distributed denial-of-service (DDoS) attacks. The exploit attempts captured by Unit 42 researchers leverage the aforementioned vulnerabilities to spread V3G4, which targets exposed servers and networking devices running Linux.

Palo Alto Networks Next-Generation Firewall customers receive protections through cloud-delivered security services such as IoT Security, Advanced Threat Prevention, WildFire, and Advanced URL Filtering, which can help detect and block the exploit traffic and malware.

Related Unit 42 Topics Mirai, IoT

Campaign Overview

Since July 2022, Unit 42 researchers have observed three campaigns utilizing the Mirai V3G4 variant. Based on our analysis, we believe the campaigns were operated by the same threat actor for the following reasons:

  • The hardcoded command and control (C2) domains among these three campaigns contain the same string (8xl9)
  • The malware shell script downloaders are almost identical between the three campaigns
  • The botnet client samples use the same XOR decryption key
  • The botnet client samples use the same “stop list” (a list of target processes that the botnet client searches for and terminates)
  • The botnet client samples use almost identical functions

The threat actor exploited 13 vulnerabilities that could lead to remote code execution. Upon successful exploitation, the wget and curl utilities are automatically executed to download Mirai client samples from malware infrastructure and then execute the downloaded bot clients.

The utilized vulnerabilities are listed in Figure 1 below, and the detailed vulnerability information is listed in the Appendix section.

Image 1 is a timeline overview of the V3G4 campaign. For each of the three campaigns it lists the callback IP, the botnet C2, the month and year, and the exploited vulnerabilities. The campaigns were in July, September, and December of 2022.
Figure 1. V3G4 Campaign Overview.

V3G4 Malware Analysis

Based on behavior and patterns Unit 42 researchers observed during analysis of the downloaded botnet client samples, we believe that the botnet sample is a variant of the Mirai botnet.

Upon execution, the botnet client prints xXxSlicexXxxVEGA. to the console. The malware also contains a function that makes sure only one instance of this malware is executing on the infected device. If a botnet process already exists, the botnet client will simply print a string from the console and exit, as depicted in Figure 2.

Image 2 is a screenshot of the botnet printing a string from the console.
Figure 2. V3G4 ensures single instance execution.

The botnet client also contains a list of process names, and it tries to terminate those processes by checking the running process names on the infected host. The process names in that list belong to other botnet malware families and other Mirai variants. The full stop list is shown in Figure 3.

Image 3 is a screenshot of the full stop list of V3G4.
Figure 3. V3G4’s stop list.

The V3G4 variant tries to connect to its hardcoded C2. This activity is shown in Figure 4.

Image 4 is a screenshot of many lines of code where the V3G4 variant is trying to connect to the hardcoded C2.
Figure 4. V3G4 malware C2 domain.

Most Mirai variants use the same key for string encryption. However, this V3G4 variant uses different XOR encryption keys for different scenarios.

Botnet Client Execution-Related String Decryption

For strings related to botnet client execution, this V3G4 variant will first initialize an encrypted string table. It will then retrieve the encrypted string through an index (shown in Figures 5 and 6).

Image 5 is a screenshot of the V3G4’s initialization of an encrypted string table.
Figure 5. Encrypted string table.
Image 6 is a screenshot of V3G4’s retrieved strings from the encrypted string table. Highlighted is the line where V3G4 retrieves strings from the index.
Figure 6. V3G4 retrieves strings.

All the botnet client execution-related strings are decrypted with four rounds of XOR decryption (shown in Figure 7). The decryption keys used are the following:

  • First round: 0xbc
  • Second round: 0x69
  • Third round: 0x3a
  • Fourth round: 0xe6
Image 7 is a screenshot of four rounds of XOR decryption by V3G4 using the keys 0xbc, 0x69, 0x3a and 0xe6.
Figure 7. V3G4 four rounds of XOR decryption.

Brute Force Credential String Decryption

V3G4 inherits its most significant feature from the original Mirai variant – a data section with embedded default login credentials for the scanner and brute force purposes. Like the original Mirai, it also encrypts all credentials with XOR key 0x37.

Image 8 is a screenshot of V3G4’s encrypting credentials with XOR key 0x37.
Figure 8. V3G4 credentials XOR Decryption.

The V3G4 variant initializes the table of telnet/SSH login credentials in the scanner function. It then spreads itself through brute forcing network devices’ weak username/password combinations.

Before the botnet client establishes a connection with the C2 server, the malware will first initialize all DDoS attack functions (shown in Figure 9). Once the client establishes a connection with the C2 server, the threat actor can issue commands to the client to launch DDoS attacks.

Image 9 is a screenshot of the malware’s DDoS attack functions. Four of them are highlighted in red, all starting with “attack.”
Figure 9. V3G4 DDoS functions.

We also noticed that the malware samples from the three campaigns we observed are slightly different. The original Mirai botnet sample spread itself by brute-forcing weak telnet/SSH credentials, whereas some Mirai variants utilize both brute-force and embedded exploits to spread themselves. However, samples from the September and December 2022 campaigns don’t contain the functions of vulnerability exploitation and brute force of credentials (this is shown in Figure 10).

Image 10 is a sample comparison of the July and December campaigns. Highlighted in the July campaign in red with an arrow is “scanner_init()”.
Figure 10. Campaign samples comparison.

Conclusion

The vulnerabilities mentioned above have less attack complexity than previously observed variants, but they maintain a critical security impact that can lead to remote code execution. Once the attacker gains control of a vulnerable device in this manner, they could take advantage by including the newly compromised devices in their botnet to conduct further attacks such as DDoS. Therefore, it is highly recommended that patches and updates are applied when possible.

Palo Alto Networks customers receive protection from the vulnerabilities and malware discussed above through the following products and services:

  • Next-Generation Firewalls with a Threat Prevention security subscription can help block the attacks with Best Practices via Threat Prevention signatures 56254, 56954, 92632, 55935, 55933, 58668, 35131, 55798, 57897, 56256, 55934, 93332 and 93392.
  • Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect vulnerability exploits in real-time.
  • WildFire can help stop the malware with static signature detections.
  • Advanced URL Filtering and DNS Security are able to block the C2 domain and malware-hosting URLs.
  • The Palo Alto Networks IoT Security platform can leverage network traffic information to identify the vendor, model and firmware version of a device and identify specific devices that are vulnerable to particular CVEs.
  • In addition, IoT Security has inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits nontypical behavior such as a sudden appearance of traffic from a new source, an unusually high number of connections or an inexplicable surge of certain attributes typically appearing in IoT application payloads.

Indicators of Compromise

Infrastructure

Malware C2

IoCs with slur removed

comeanalyze.8x19[.]com

Malware Host

176.123.9[.]238
198.98.49[.]79
104.244.72[.]64

Artifacts

Shell Script Downloader

0837de91aa6bd52ef79d744daba4238a5a48a79eb91cb1a727da3e97d5b36329
c32f8df3cb019e83e0ac49ab0462c59ec70733c3d516ade011727408751c9d42
f295904d966889afb0f6b3625e504a1420a978434e2b6a9e9b85b688a44593fa

V3G4 Sample

July Campaign

7bc99c87a1e0582b5f15f40141226862fbe726b496e1e77c7f95993e8e945733
88f7b9a8c4f9bb28582c485549b328d6123e8aea33009ce7657f7fc0ef829e03
64545e94daafba191669333e1dd0c6e1190df47e0742bd515911cce0cdbd4fd1
69bb44736817dabe88e3014c6207ba702f644fb43f6feaec23091af0b5224bc6
eaa387fcc12f2d8a7d42f12d27e7dccb4f3e11492a7d3a3a1ce830a11b539d28
a987d1e113b858d21596bb2dfffe79721d5149bfa782e693aafc0cf47aa8c6dc
afca95eb143e0180f1594517a44b2d226a2e44de5cbd2cd49b8c6cdb2a0b61ee
b651f9320f07d7eade9af523297b4bcfd0e0af187272e368e889c988a55ed78e
6229041985c466c131e48b9ba0d1bb80bdb7556c941ee84aa461fe2efbf1e853
1dc4777dac6dc4e8c650241e211311c4a418a35ebded72fcdd6bcb965ccf918b
3e69e8ed741ab39b0914f7e95bf13b2f0ae9f3c1227dcffdea3369e03e8bb792
b2e4ee94783062658ddf2c41e9acafb401d0f93e3848c027383a5ca19289b786
dd91943b0d453ace3b19779c88da19c9a386dd3e9d2322c85a4cdcf84a22c663
a93d999dc0515066c5c2a261f1be47233b358889d0594c14409309818d86347d

September Campaign

31926da5ca004a11c1f46947edb220afe3a53f81cf245b3afae7ea1abaec7c38
eed4690f6e4d92b511fcde9a712b1a8405c5333e0ad78a4c676a64b22412e149
210f3f1ffd2ec66a5076a7fea5d83caa8bbcdb0f3bc3bd030c77eded6f4b5d90
73cc00acc478bf09658a679a4689f34598fe6e92086efe82900242f3cc5b7aec
1218da43a62da76927484bca73a3eee53425c54625147f8d01149bcef2f09d1e
2944db28e4505fc439599dae15b10bf57b7cf6c2597f618f41b99bfc65443c61
4bffc171c0748cc9e3398b1ce8135b125f54f46752768c981c45d3390e8359a1
b3a17934f6f72941b9a60097ab09228d873a2f8737ee0ea93b08e5f1cc3916d1
916e00391279b014e53d73c2216a84bd528e18f1f633ba0101288aa963f77c5b
7dea8dac3f455f3a57fecfa5a047439126556858c239e73cd8feec2dc13bae2c
a10ce475f64f3821ab32c88f6b013effd40843dd575ceaab46a57f134c2478b6
d9b5199f36fc416d8a87d798926e0d9dcbb2fe97610cf08d6887dae1355e9439
feda096ed8ddf4206365d326b3b7cb2d57ca1e89999b0b1da80fb9658dff6e44

December Campaign:

63ACD589A53BDEC49C624F3CB2FC8319218DF721F486E2F15F3C07ABED97AAE6
1cf3879d9e93d1ff30ce5ec0f64ff15b1db7d8237160c83efed688d800e5ef12
c5be50880e2b5a8a8d43a5f1fd6f5d36fc665ab9b4031a9b6a4d52222004c2c1
9b7f36cabbb90dfe9cd75f12c01fb64766dd1ec0f4247dbf8f4477dd64407fbf
7d9cdf3afb1d52f49d82b1ffe28a3da08c6aeeaa8c5047ba37c73802d2cd9ec2
9a0d39265b53e1959df49dbc8727ad344abc12a8bc0bd8d8b76f8b150525dca6
d00fbfc439cb9c5c850690134b0d51f262021c0d04d9934df464980c346c1dc5
b4f23a88de9b566ce980a8188674319039d2fbe13b049859f8fe4821c92f9200
3f3fb70e16d65f5f4b21777b87c9aae6072022c3dfbefd177f37c8aef4a6aeee
67379740ed15e8da8604cc1f0ea715c8641674de66e553c461b3ae782a5d0cbe
ab3d61a76197003822252124e89987d061d6a4a33b9891cea778d3708cd50447
6f654198e8efd5aff1c7a903353967d0e96aeff0402cb0a79fabbc10d18c63d2
c288c200cf7bbebe7a81fd42ca1bd4c6cb6080f28f2cec297a0d3e6aff7876fe

Additional Resources

Appendix

Campaign-related vulnerability information is listed below:

CVE-2012-4869: FreePBX Elastix Remote Command Execution Vulnerability

This malicious traffic was first detected as part of the V3G4 campaign on July 4, 2022. The exploit targets a command injection vulnerability in the FreePBX Elastix callme_startcall function, which does not successfully sanitize the user input in the callmenum parameter, leading to arbitrary command execution.

A few lines of code showing the CVE-2012-4869 exploit in the wild.
Figure 11. CVE-2012-4869 exploit in the wild.

Gitorious Remote Command Execution Vulnerability

We captured this exploit traffic on July 4, 2022. The exploit works due to Gitorious’ insufficient input validation, which allows the attacker to exploit the vulnerability to launch a command injection.

A few lines of code showing the Gitorious vulnerability exploit in the wild.
Figure 12. Gitorious vulnerability exploit in the wild.

CVE-2014-9727: FRITZ!Box Webcam Remote Command Execution Vulnerability

We observed this malicious traffic on July 4, 2022. This remote command execution vulnerability is due to a failure to sanitize the value of the var:lang parameter in the cgi-bin/webcm interface of the FRITZ!Box Webcam.

A few lines of code showing the CVE-2014-9727 exploit in the wild.
Figure 13. CVE-2014-9727 exploit in the wild.

Mitel AWC Remote Command Execution Vulnerability

This exploit traffic was detected on July 4, 2022. The exploit targets a remote command execution vulnerability in the Mitel audio, web and video conferencing (AWC) product. The server fails to adequately sanitize the user-supplied input data, which leads to remote command execution.

A few lines of code showing the Mitel AWC exploit in the wild.
Figure 14. Mitel AWC exploit in the wild.

CVE-2017-5173: Geutebruck IP Cameras Remote Command Execution Vulnerability

We detected this exploit traffic on July 4, 2022. The user input to Geutebruck IP Cameras’ testaction.cgi component is not correctly sanitized, allowing the attacker to run shell commands with root privilege.

A few lines of code showing the CVE-2017-5173 exploit in the wild.
Figure 15. CVE-2017-5173 exploit in the wild.

CVE-2019-15107: Webmin Command Injection Vulnerability

This malicious traffic was detected on July 4, 2022. The exploit targets a command injection vulnerability in the password_change.cgi component within the Webmin product. The component does not successfully sanitize the parameters, which in turn can lead to arbitrary command execution.

A few lines of code showing the CVE-2019-15107 exploit in the wild.
Figure 16. CVE-2019-15107 exploit in the wild.

Spree Commerce Arbitrary Command Execution Vulnerability

We observed this exploit traffic on July 4, 2022. The exploit targets the Spree Commerce product’s insufficient input validation, the attacker can exploit the vulnerability to launch a remote command execution attack.

A few lines of code showing the Spree Commerce exploit in the wild.
Figure 17. Spree Commerce exploit in the wild.

FLIR Thermal Camera Remote Command Execution Vulnerability

This exploit traffic was captured on July 4, 2022. The exploit works due to the FLIR Thermal Camera failing to sanitize user input, which in turn could lead to remote command execution.

A few lines of code showing the FLIR Thermal Camera exploit in the wild.
Figure 18. FLIR Thermal Camera exploit in the wild.

CVE-2020-8515: DrayTek Vigor Remote Command Execution Vulnerability

We captured this exploit traffic on Sep. 13, 2022. The exploit targets the cgi-bin/mainfunction.cgi component of DrayTek Vigor. The component does not successfully sanitize the value of the HTTP parameter keyPath, which leads to remote command execution.

A few lines of code showing the CVE-2020-8515 exploit in the wild.
Figure 19. CVE-2020-8515 exploit in the wild.

CVE-2020-15415: DrayTek Vigor Remote Command Injection Vulnerability

This malicious traffic was captured on Sep. 13, 2022. The exploit works due to the /cgi-bin/mainfunction.cgi/cvmcfgupload endpoint of DrayTek Vigor failing to sanitize the value of the HTTP parameter filename.

A few lines of code showing the CVE-2020-15415 exploit in the wild.
Figure 20. CVE-2020-15415 exploit in the wild.

CVE-2022-36267: Airspan AirSpot Remote Command Execution Vulnerability

We detected this exploit traffic on Sep. 14, 2022. The exploit targets a remote command execution vulnerability in the Airspan AirSpot cgi-bin/diagnostics.cgi component. The component does not successfully sanitize the value of the HTTP parameter targetIP in the pingDiagnostic command.

A few lines of code showing the CVE-2022-36267 exploit in the wild.
Figure 21. CVE-2022-36267 exploit in the wild.

CVE-2022-26134: Atlassian Confluence Remote Code Execution Vulnerability

This exploit traffic was captured on Sep. 12, 2022. An Object-Graph Navigation Language (OGNL) injection vulnerability exists in the Confluence Server and Data Center that would allow an unauthenticated attacker to execute arbitrary code on a Confluence Server or Data Center instance.

A few lines of code showing the CVE-2022-26134 exploit in the wild.
Figure 22. CVE-2022-26134 exploit in the wild.

CVE-2022-4257: C-Data Web Management System Command Injection Vulnerability

We observed this malicious traffic on Dec. 25, 2022. The exploit targets a remote code execution vulnerability in the diagnosis_config_save.php component of the C-Data Web management system. The component does not properly sanitize the values of the HTTP parameters iface and hostname, which in turn can lead to arbitrary command execution.

A few lines of code showing the C-Data RCE vulnerability exploit in the wild.
Figure 23. C-Data RCE vulnerability exploits traffic.

Machine Learning Versus Memory Resident Evil

Posted on by Esmid Idrizovic

Executive Summary

Unit 42 researchers discuss a machine learning pipeline we’ve built around memory-based artifacts from our hypervisor-based sandbox, which is part of Advanced WildFire. This alternative approach is one we’ve come up with to boost detection accuracy against malware using a variety of different evasion techniques.

As we discussed in our first two posts in this series, malware authors are routinely refining their shenanigans to make strategies like static analysis and sandboxing ineffective. The continual development and permutation of techniques like packing methodologies and sandbox evasions create a continual cat and mouse game that is difficult to stay on top of for any detection team.

To make matters worse, popular detection techniques such as structural analysis, static signatures and many types of dynamic analysis do not fare well against the ever-increasing complexity we encounter in the more prevalent malware families.

Related Unit 42 Topics Sandbox, evasive malware, machine learning, AI, memory detection

Statically Armored and Full of Evasions

Malware authors increasingly employ evasion techniques such as obfuscation, packing and execution of dynamically injected shellcode in process memory. Using cues from the file structure for malware detection might not always succeed. Packing techniques modify the file structure sufficiently to eliminate these clues. Thus, machine learning models trained on this class of features alone would not effectively detect such samples.

Another popular alternative to this detection method is to use a machine learning model that predicts maliciousness based on the malware’s execution traces inside a sandbox. However, as detailed in our previous post in this series, sandbox evasions are extremely prevalent and payloads will often choose not to execute based on any number of clues that would point to a sample being emulated.

Malware can also inadvertently or intentionally corrupt the sandbox environment, overwrite log files or prevent successful analysis for any number of reasons due to the low-level tricks it is playing. This means that training our machine learning models on the execution logs is also not going to be enough to catch these evasive types of malware.

GuLoader Encrypted With NSIS Crypter

In this post, we will analyze one GuLoader downloader that has been encrypted with an Nullsoft Scriptable Install System (NSIS) crypter. NSIS is an open source system to create Windows installers.

Hash cc6860e4ee37795693ac0ffe0516a63b9e29afe9af0bd859796f8ebaac5b6a8c

Why Static Analysis Isn’t Going To Help

The GuLoader malware is encrypted, and it is also delivered through a NSIS installer file that is not ideal for static analysis because the file contents must be unpacked first. Once it’s unpacked, we are still left with encrypted data and one NSIS script. The script itself also dynamically decrypts some parts of the code, which is another factor that makes it harder to detect.

However, there are not many structural clues that would identify this as possible malware. Thus, a machine learning model trained on the Portable Executable (PE) file structure would not be effective in differentiating the file from other benign files.

NSIS Script and Extracting GuLoader Shellcode

To extract the NSIS script, we have to use an older version of 7-Zip, version 15.05. This version of 7-Zip is able to unpack the script, where newer versions have removed the functionality to unpack NSIS scripts. Once we have extracted the file contents and the NSIS script (shown in Figure 1), we can start analyzing the script and see how the GuLoader sample is being executed.

Image 1 is a screenshot of many lines of code the NSIS script, prepared to analyze.
Figure 1. The NSIS script.

If we scroll down the script, we quickly notice that the files are being copied into a newly created folder named %APPDATA%\Farvelade\Skaermfeltet. Though it’s not clear why, the file paths used seem to be in Danish. After the copying activity, we have regular installation logic in the script, but there is one interesting function named func_30.

Before this function is called, the string $INSTDIR\Filterposerne\Malkekvg.Nat is copied into a string variable named $4, as shown in Figures 2 and 3. The function func_30 reads data from the Programmeludviklinger210.Kon file and builds up code, which it will call immediately after the character Z has been seen.

NSIS gives developers the ability to call any exported function from a Windows DLL, and it also allows developers to save the results directly in NSIS registers/stack. This functionality allows malware authors to dynamically call Windows API functions on runtime and makes static analysis harder because it must be evaluated before being analyzed.

Image 2 is a screenshot of a few lines of code of the NSIS script as it calls function func_30.
Figure 2. Calling function func_30.
Image 3 is a screenshot of many lines of code showing the NSIS code as it is decoded.
Figure 3. Decoding NSIS code.

To decode the dynamic code, we can write a short Python script that reproduces the behavior and extracts the Windows API calls:

Figure 4 shows the decoded data that results from the script above.

Image 4 is a screenshot of a few lines of code showing the decoded Windows API calls.
Figure 4. Decoded Windows API calls.

The decoded functions together read a shellcode from another file from the NSIS archive, and they execute it using the EnumWindows function. If we had to write this process in pseudo code, it would look something like this:

To make the remaining analysis easier, we are going to generate one PE with the shellcode. To generate the executable, we can either use a tool like Cerbero Profiler or LIEF Python library.

In this case, we have used the LIEF library to build a new executable. All we have to do is to add a new section with the contents of file Malkekvg.Nat and set the entry point to be at the correct offset. Once we get that, we should be able to open our shellcode in IDA Pro (shown in Figure 5) and see that it contains valid x86 instructions.

Image 5 is a screenshot of many lines of code showing the generated PE file at entry point in IDA Pro. Highlighted is “loc_4027E9.”
Figure 5. Generated PE file at entry point in IDA Pro.

Analysis of the Shellcode

Now that we have the first stage of the shellcode inside a PE file we can run it in dynamic analysis and see what happens. The first thing that we will see is that it detects virtual machines and stops its execution after showing a message box. This text is decrypted on runtime using a 4-byte XOR key.

Image 6 is a screenshot of a Windows popup notification with the message “This program cannot be run under virtual environment or debugging software !”
Figure 6. The sample can’t be executed in a virtual environment.

If we open the file in IDA Pro and follow the code a little, we should be able to see the large function for decrypting the first stage. While the function graph overview looks large, it’s still easy to identify junk code.

The code that is doing the decryption can be seen below in Figure 7. In Figure 8 we can see the final call that jumps to the second stage. At this point, we can dump the second stage into another executable for decryption.

We can dump the executable directly from memory, but we must make sure to patch the entry point to point to the correct address (which is 0x404328 in this example).

Image 7 is is a screenshot of many lines of code showing the first stage of shellcode. Highlighted is “decryption_start.”
Figure 7. Shellcode decryption of first stage.
Image 8 is a screenshot of a few lines of code showing the second stage of anti-analysis techniques.
Figure 8. Call to the next stage.

The second stage uses many anti-analysis techniques, which would be too long to describe here and are described elsewhere, so we won’t go too much detail. Here are a few of the anti-analysis techniques mentioned:

  • Memory scan for known sandbox strings
  • Hypervisor checks
  • Time measuring
  • Instruction hammering

To get the final payload that is being downloaded by GuLoader, we would have to either manually bypass all these checks, run it inside a sandbox that is immune to all of these techniques, or run it on a bare-metal sandbox.

Extracting Payload Information

To get the payload information (including all the strings) without analyzing the second stage, we can use a little trick that has been described by Spamhaus. GuLoader uses simple XOR encryption for encrypting its strings, which includes the payload URL.

All we need is the encryption key to decrypt everything. The good news is that the key resides somewhere inside the second stage.

To decrypt the strings, we can use brute-force on a pattern that we already know exists inside the second stage. The result of that XOR operation would be our key. The only limitation to this is that the pattern must be large enough so that we are able to fully decrypt the payload URL. For example, a good pattern might be the user-agent string, which is set by default to Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko.

To quickly find the decryption key automatically, we have to encrypt a short pattern first (e.g., first 8 bytes of the user-agent string) and search if that result is somewhere in the file. If it is somewhere in the file, then we can continue and encrypt the remaining pattern to get the full encryption key.

At the end of this blog, we have attached the Python script that is able to find the encryption key from the payload by the method described above. Once we run the script on any dumped second stage GuLoader payload, we should be able to see a few strings and the payload URL.

GuLoader sometimes includes 7 to 8 random characters in front of the payload URL, which it replaces on runtime with either http:// or https://. The distinction of whether http or https is used is made by the fourth character from that random pattern.

In this sample, the payload URL was http://ozd[.]com[.]ar/wp-includes/nHMoYlbGLWls101.qxd and the payload was still online at the time of this analysis.

The final downloaded payload is from the FormBook malware family, and it had the SHA256 value of fa0b6404535c2b3953e2b571608729d15fb78435949037f13f05d1f5c1758173.

How Can Machine Learning Detect This?

In a previous blog post, we detailed several types of observable artifacts that we can extract from memory during a live sandbox run. We’ve found that the data from memory analysis is extremely powerful when combined with machine learning for the detection of malware with multiple evasion techniques.

The following section describes our strategy for taking all these observations about what was modified in memory at runtime and combining them with machine learning at scale for malware detection. The algorithm can find patterns automatically, and it can identify commonalities that indicate when malware is attempting to hide its footprints in memory, dynamically allocating and executing shell code, or using unpacking.

In this GuLoader sample, right off the bat, a human analyst would identify that there are a few unique function pointers. We would also notice that the malware has changed the page permissions of multiple pages in its own process memory to writable and executable. Our machine learning model is able to automatically perform these activities, taking the features extracted from the various memory artifacts to detect the GuLoader sample.

As we discussed earlier in this blog series, the automated analysis platform we’ve created for Advanced WildFire will automatically extract all of these memory-based artifacts in a performant way. This means that all of the information related to dynamically resolved function pointers, permissions changes and unpacked executables can be utilized either in our manually curated detection logic or additionally for our machine learning pipelines.

Detection Using Machine Learning

Figure 9 shows a high level view of how we created a machine learning model pipeline trained on custom features extracted from the aforementioned memory-based artifacts. The features we chose were fashioned to retain the most useful information from the verbose artifacts.

We also included malware execution traces as an extra source of information and built an ensemble model to detect the malicious samples. As shown in Figure 9 below, various custom features are automatically extracted from the four memory artifacts and malware execution traces, and they are passed to a classification model for detecting malicious samples. Furthermore, we have built an ensemble model that is trained on memory artifacts and execution trace based features to boost its performance.

Image 9 is an image of a diagram showing machine learning model architecture. It shows the group of memory artifacts and execution traces then lead to custom feature extraction, feature vector creation, and from the ensemble of the memory model and execution trace model, predict sample maliciousness.
Figure 9. Machine learning model architecture.

Feature Engineering

We’ve experimented with the efficacy of raw values from the different feature sources versus custom features for the purposes of model accuracy. Using custom features built using domain knowledge enables us to reduce noise and minimize the number of features overall, thus helping avoid the curse of dimensionality.

At the same time, using raw values as features allows us to quickly adapt to newer malware trends that might use changing attack tactics and techniques. We have utilized deep learning to extract features from the logs involving extracted memory-based artifacts and combine that with custom features. Our experiments show that the models work best with a combination of the two approaches.

Model Selection

When it comes to model selection, there are a few factors that we have to consider:

  • Small model size allows for scaling up the machine learning service to accommodate the ever growing number of samples to process.
  • Account for the absence of certain feature sources, (e.g., execution traces) in case of errors encountered.
  • Model predictions should be interpretable so we can identify the causal features in the case of disruptive false positives.
  • The model should attempt to retain as much information as possible from the samples it has trained on.

A gradient-boosted trees model trained on domain-specific features and custom features extracted from raw data satisfies many of the aforementioned criteria.

Training the Machine Learning Model

Image 10 is a diagram of the machine learning training pipeline. It starts with the file sample and ends with the machine learning service.
Figure 10. Machine learning training pipeline.

The file samples are processed by a streaming pipeline to save memory artifacts and other malware attributes to a feature store. The feature extraction stage uses a combination of streaming and batch processing PySpark jobs to generate the final feature vector used for training the model.

The ground truth labels come from a separate pipeline that assigns labels to the samples based on malware characteristics and researcher inputs. The pipeline generates non-overlapping training and evaluation datasets by using the sample first seen time and hashes.

Once the machine learning model is trained and satisfies the predefined evaluation checks, including expected improvement over the currently active model, it’s pushed to the production machine learning service.

Interpreting Model Predictions

It’s crucial to understand the machine learning model’s predictions in order to identify the limitations and the capabilities of the model. Machine learning is prone to false positives, as it’s heavily dependent on the quality and variety of the training data, as well as the ability to generalize on a changing landscape of files to predict on. Thus, having the ability to identify the causal features for a prediction can be very helpful.

We use two methodologies to assist with this process.

Interpreting Shapley Values

Shapley Additive Explanations (SHAP) is a game-theoretical approach used to explain the output of any machine learning model. The SHAP values explain the influence of each feature on the actual prediction for an input feature vector as opposed to the baseline prediction. In Figure 11, the features in red, from right to left, are the topmost features that push the model towards a malicious prediction. The features in blue, from left to right, indicate the topmost features that reduce the probability of the prediction being malware.

Image 11 is a red and blue force plot displaying SHAP values for the GuLoader sample. The red features are what pushes a model towards malicious prediction. The blue features indicate what reduces the probability of the prediction being malware.
Figure 11. Force plot of SHAP values for GuLoader sample.

In the figure above, we have plotted the force plot for the top seven features with significant SHAP values and their corresponding raw feature values. Our machine learning model was able to detect GuLoader due to the presence of these top features. These features correspond to several specific dynamically resolved API pointers and their relative locations in memory, as well as the relative types of memory page permission changes that were made by the sample.

Finding Similar Samples Through Clustering

Another approach to understanding the model’s predictions is to identify similar samples in the training dataset. We use density based scan (DBScan) as a clustering technique, shown in Figure 12, as it allows for outliers and different shaped clusters.

Image 12 is a data cluster identifying three colors: red, blue, and green. Outliers are grey and there are only a few. This figure was made with DBSCAN.
Figure 12. DBSCAN based clustering.

This approach also expands its use beyond model interpretation to find similar samples that belong to the same malware family or APT group. Using DBScan we can find out the cluster where the GuLoader sample resides and extract samples. Furthermore, we can also extract samples which are similar to it in feature space.

Conclusion

The GuLoader family is an excellent example of malware to detect with our machine learning model, because its use of sandbox evasions and static armoring makes it hard for traditional defenses to detect using structural cues and execution logs alone.

With Advanced WildFire, we introduce a hypervisor-based sandbox that can stealthily observe the memory of GuLoader during execution to parse meaningful memory resident artifacts and information useful for our machine learning detection pipeline. This allows us to accurately detect the malicious behavior using features extracted from the observed memory-based artifacts.

Palo Alto Networks customers receive protections from threats such as those discussed in this post with Advanced WildFire.

Indicators of Compromise

cc6860e4ee37795693ac0ffe0516a63b9e29afe9af0bd859796f8ebaac5b6a8c
fa0b6404535c2b3953e2b571608729d15fb78435949037f13f05d1f5c1758173 (Final payload)

Additional Resources

Threat Assessment: GandCrab and REvil Ransomware
SHAP Documentation
GuLoader Strings Decryptor

Mitigating RBAC-Based Privilege Escalation in Popular Kubernetes Platforms

Posted on by Samantha Stallings

Executive Summary

Prisma Cloud and Unit 42 recently released a report examining the use of powerful credentials in popular Kubernetes platforms, which found most platforms install privileged infrastructure components that could be abused for privilege escalation. We're happy to share that, as of today, all platforms mentioned in our report have addressed built-in node-to-admin privilege escalation. However, it’s possible third party add-ons might reintroduce the issue.

In the research we presented at KubeCon EU and BlackHat USA, we found that in half the platforms, any container escape had previously allowed for a full cluster compromise because all nodes hosted admin-equivalent credentials. Most of the platforms mentioned in our report made their infrastructure unprivileged by default, while one did so through an optional add-on.

Stripping permissions is often complex, and we recognize fixing this is no small matter. We'd like to thank Azure Kubernetes Service (AKS), AWS Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), RedHat OpenShift Container Platform, Antrea and Calico for working to harden their access control.

We provide a short recap of our research and look into the different mitigations the platforms implemented to address privilege escalation and powerful permissions in Kubernetes. If you're interested in evaluating your own cluster's Role Based Access Control (RBAC) posture, try rbac-police, our open-source RBAC analyzer for Kubernetes.

Prisma Cloud users can catch Kubernetes misconfigurations like excessive RBAC permissions before they're deployed to the cluster via the Cloud Code Security (CCS) module. In the runtime phase, users can rely on the built-in admission controller for Kubernetes to enforce policies that alert on suspicious activity in their clusters, including Kubernetes privilege escalation.

Related Unit 42 Topics Privilege Escalation, Cloud Security, Kubernetes, Containers, Container Escape

Recap: Powerful Permissions Everywhere

Kubernetes managed services, distributions and add-ons install a set of system pods into our cluster to manage its infrastructure and enable core functions such as networking, DNS and logging. Commonly, these pods are deployed via DaemonSets that distribute them onto every node in the cluster.

If those DaemonSets' permissions are loosely granted, they could inadvertently spread powerful credentials throughout the cluster. This could be abused for privilege escalation, as shown in Figure 1.

Image 1 is a diagram showing how a threat actor exploits DaemonSet credentials to spread in a cluster. It shows the escaped container, api server, and the pods.
Figure 1. An attacker who escaped a container exploits the credentials of a powerful DaemonSet to spread in the cluster.

To understand the prevalence of powerful DaemonSets, we analyzed popular Kubernetes platforms—managed services, distributions and container network interfaces (CNIs)—to identify privileged infrastructure components. We found that most platforms ran powerful DaemonSets, installing privileged credentials onto every node in the cluster.

As shown in Figure 2, in half the platforms, those credentials were admin-equivalent, allowing a single container escape to compromise the entire cluster.

Image 2 is a pie chart showing the percentage of platforms where a container escape led to a complete cluster takeover. 50% of credentials used were admin equivalent, with the some prerequisites and no prerequisites splitting the remainder.
Figure 2. Percentage of platforms where a container escape allowed a complete cluster takeover.

We believe powerful DaemonSets became common for three main reasons:

  1. Historically, Kubernetes clusters weren't secured by default.
    In environments where crucial components like Kubelets allowed unauthenticated access, maintaining a least-privileged RBAC posture wasn't a priority. The infrastructure built then set a precedent for powerful DaemonSets.
  2. Some Kubernetes permissions are simply too broad.
    This means they authorize a large set of operations. Often, granting a service account the ability to perform a necessary but sensitive operation implicitly authorizes it to perform other, potentially harmful operations. RBAC is not a great model for many of these use cases, and an attribute-based access control model that matches some attribute of the principal to some attribute of the resource would often make more sense.
  3. Certain permissions appear benign, but are in fact quite powerful.
    If someone believes a permission is harmless, they won't have second thoughts about granting it. For example, the ability to update the status of pods implicitly allows deleting pods that are part of ReplicaSets.

Mitigation

After identifying a powerful DaemonSet, we reached out to the relevant platform and started a discussion on mitigation. The response was extremely positive – the teams understood the issue and wanted to resolve it. Mitigations were developed, tested and deployed in recent months. And as of today, all of the privilege escalation attacks we identified are resolved.

Thanks to the work done by the different platforms, the Kubernetes landscape is a safer one, where nodes aren't admins by default. In the following sections, we'll highlight the different approaches platforms took to address powerful DaemonSets in their offerings.

Strip Permissions

The simplest way to address a risky permission is to remove it. A number of platforms identified certain risky permissions that weren't explicitly necessary, and they removed them. Some permissions were made safe by scoping them down to certain resourceNames or subresources.

For example, Cilium found that the “delete pods” permission wasn't explicitly necessary for their DaemonSet to operate correctly, and they removed it. Openshift was able to strip the "update nodes" permission from their software-defined network (sdn) DaemonSet, because the function that relied on it could be replaced with an unprivileged implementation.

Restrict via Admission Control

A common use case for DaemonSets is local node management, where each DaemonSet pod manages its local node. Unfortunately, Kubernetes doesn't support scoping down a DaemonSet pod's permissions to its local node. Thus every pod in the DaemonSet must be authorized to manage all nodes, not just its local one. This allows attackers who take over a node to abuse the credentials of the local DaemonSet pod to compromise other nodes and spread in the cluster.

Both AKS and EKS ran a DaemonSet that had pods that needed to update their local node. Unfortunately, the only way built in to Kubernetes to grant this permission was to permit every pod in the DaemonSet to update every node in the cluster.

An attacker who compromised a node could abuse the DaemonSet's token to taint other nodes, allowing it to steal pods. This attack is carried out in three steps, illustrated in Figure 3.

  1. Add a NoSchedule taint to every node in the cluster beside the compromised one, making the compromised node the only available node in the cluster.
  2. Add a NoExecute taint to the node hosting the target pod to force Kubernetes to evict it and delete its pods.
  3. Kubernetes recreates the target pod, and can now only schedule it on the one available node in the cluster, which is the compromised node.
Image 3 is a diagram showing how a threat actor compromises a node to taint other nodes in three steps. Step 1, the left column, is where the actor uses NoSchedule to taint pods in a node. Step 2, the middle column, is where the NoExecute Tain is added to the node hosting the target pod. Kubernetes then evicts the target pod and deletes its pods. In step 3, the right column, Kubernetes recreates the target pot, which is in a compromised node.
Figure 3. Abusing a DaemonSet's “update nodes” permission to manipulate taints in order to steal pods.

The DaemonSets on EKS and AKS needed the “update nodes” permission, so simply removing it wasn't a valid solution. Instead, both platforms were able to mitigate the attack using custom validating admission webhooks.

EKS - Restrict by Operation

In EKS, the aws-node DaemonSet needed to update certain node attributes, but not taints. So if an aws-node pod unexpectedly attempts to taint a node, it's likely an attack. The EKS team implemented a validating admission webhook that intercepts node update requests, and blocks attempts to manipulate taints that are issued by the aws-node service account. You can see this in action in Figure 4, below.

Image 4 is a screenshot of many lines of code where EKS is preventing the aws-node pod from tainting nodes.
Figure 4. EKS prevents the aws-node pod from tainting nodes.

AKS - Restrict by Target

AKS had a slightly more difficult situation to contend with. Their cloud-node-manager DaemonSet does taint nodes, so blocking taints altogether wasn't a valid option.

To be exact, each cloud-node-manager only needed to taint its hosting node. AKS used that to mitigate the attack. They wrote a validating admission webhook that intercepts node update requests, and identifies which cloud-node-manager pod issued the request.

If a cloud-node-manager pod attempts to update a node that isn't its hosting one, the request is denied. As shown in Figure 5, if an attacker attempts to abuse a cloud-node-manager pod's credentials, they are denied.

Image 5 is a screenshot of many lines of code demonstrating am attacker denied attempts to abuse a cloud-node-manager pod's credentials.
Figure 5. AKS prevents the cloud-node-manager pod from tainting other nodes.

To function correctly, this admission webhook must know which pod issued the request, not only which service account. This is possible thanks to a recent Kubernetes enhancement, bound service account tokens.

In the past, a token only referenced the service account it represents. Now, a pod's service account token also includes a claim that specifies the pod the token was issued for. Admission controllers can use that claim to identify which pod a request originated from.

This webhook nicely demonstrates how bound tokens enable node-local authorization for DaemonSet pods. It's possible that in the future, Kubernetes would have built-in support for that functionality, without the need for a custom admission webhook.

Move Privileged Functionality Elsewhere

To carry out privileged tasks, someone in the cluster needs to possess powerful credentials. Because DaemonSets' credentials are widely distributed, they're not the best fit for carrying out privileged tasks. Several platforms addressed powerful DaemonSets by having control plane controllers or non-DaemonSet pods carry out privileged tasks instead. DaemonSets' powerful permission could then be removed.

For example, in GKE clusters running Dataplane v2 the anted DaemonSet was authorized to update pods and nodes for certain tasks. These permissions are risky, and could also be abused for a number of privilege escalation attacks. By having the control plane take care of pod and node updates, GKE was able to remove these powerful permissions from the anted DaemonSet.

Recommendations

Even when the underlying Kubernetes infrastructure is configured to maintain appropriate privilege boundaries, add-ons and applications that are misconfigured with excessive permissions can still re-introduce the same attack paths to a cluster. Below are best practices for hardening your cluster's RBAC posture and preventing intracluster privilege escalation.

  • Follow the principle of least-privilege. Only grant explicitly required permissions. When possible, scope down permissions to specific namespaces, resources names, or subresources.
  • Add guardrails to your Kubernetes Infrastructure-as-Code (IaC) continuous integration/continuous delivery (CI/CD) pipelines. This will prevent developers from unintentionally granting powerful permissions to service accounts. Checkov, an open-source IaC scanner, supports a number of Kubernetes checks that alert on excessive RBAC permissions, as shown below in Figure 6.
  • Routinely review your RBAC posture. This allows you to identify potential threats and overly powerful identities. Ensure powerful permissions aren't granted to less trusted or publicly exposed pods. Consider using automated tools like rbac-police.
  • Refrain from assigning tasks requiring privileged credentials to DaemonSets. Control plane controllers or deployments are preferable in this instance.
  • Separate resources and workloads requiring different trust levels into different namespaces.
  • Use admission control to implement fine grained authorization for permissions that cannot be expressed in RBAC. When possible, implement a safe operation allowlist to block unexpected and malicious requests from powerful service accounts.
  • Isolate powerful pods on separate nodes from untrusted or publicly-exposed ones using scheduling constraints like Taints and Tolerations, NodeAffinity rules, or PodAntiAfinity rules.
Image 6 is a screenshot of many lines of code where Chekhov, a cloud CL infrastructure scanner, alerts on a ClusterRole configured with powerful permissions. It has warned of on over-powered role.
Figure 6: Checkov alerts on a ClusterRole configured with powerful permissions.

Your cluster’s threat model should be taken into account when implementing industry best practices. Kubernetes is a platform for building platforms, meaning a cluster's threat model varies heavily depending on its architecture. The above guidelines tackle intracluster privilege escalation.

If you're building clusters with different trust levels, intracluster privilege is a major threat. Below are a few examples for clusters hosting different trust levels:

  • Multitenant clusters hosting possibly malicious tenants/workloads
  • Running different teams on a single cluster
  • Deploying multiple applications across a large cluster

On the other hand, if you're running small clusters that are each dedicated to a single application, then it makes more sense to invest in segregating those clusters from one another and from external services. When the cluster doesn't host different trust levels, preventing privilege escalation inside it shouldn't be a top priority. That being said, detecting privilege escalation attacks can still help identify breaches.

Conclusion

Maintaining a secure RBAC posture in Kubernetes is complex, both for platforms and users. When leading platforms enforce hardened defaults, it's easier for Kubenetes users to adopt secure architectures.

We'd like to thank each of the platforms mentioned in this blog for taking the difficult problem of unprivileged infrastructure head on, and coming up with creative implementations to solve it.

We recommend Kubernetes users and platforms automate the detection of RBAC misconfigurations in their CI/CD pipelines through tools like Checkov and rbac-police. For managed services, even when an infrastructure component requires risky permissions, a validating admission webhook might be able to prevent misuse.

See our report, Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms, for more information. Prisma Cloud users are encouraged to read the report's "Prisma Cloud" section to learn how Prisma's Kubernetes IaC scanning capabilities and the built-in admission controller for Kubernetes can tackle the challenges of securing Kubernetes identities.

Additional Resources

Chinese PlugX Malware Hidden in Your USB Devices?

Posted on by Mike Harbison

Executive Summary

Recently, our Unit 42 incident response team was engaged in a Black Basta breach response that uncovered several tools and malware samples on the victim's machines, including GootLoader malware, Brute Ratel C4 red-teaming tool and an older PlugX malware sample. The PlugX malware stood out to us as this variant infects any attached removable USB media devices such as floppy, thumb or flash drives and any additional systems the USB is later plugged into.

This PlugX malware also hides actor files in a USB device using a novel technique that works even on the most recent Windows operating systems (OS) at the time of writing this post. This means the malicious files can only be viewed on a Unix-like (*nix) OS or by mounting the USB device in a forensic tool.

We also discovered a similar variant of PlugX in VirusTotal that infects USB devices and copies all Adobe PDF and Microsoft Word files from the host. It places these copies in a hidden folder on the USB device that is created by the malware.

PlugX is a second-stage implant used not only by multiple groups with a Chinese nexus but also by several cybercrime groups. It has been around for over a decade and has been observed in some high-profile cyberattacks, including the U.S. Government Office of Personnel Management (OPM) breach in 2015. It is a modular malware framework, supporting an evolving set of capabilities throughout the years.

Palo Alto Networks customers receive protections against the types of threats discussed in this blog by products including Cortex XDR and WildFire.

Related Unit 42 Topics PlugX, Brute Ratel C4

Introduction

It's not uncommon for multiple malware samples to be discovered during an investigation, as occurred in this situation with GootLoader, Brute Ratel C4 and PlugX. Numerous threat actors compromise targets and can coexist simultaneously on the affected machine.

Because we can’t conclusively say whether these malware samples were left by one group or several, we can't attribute these tools to the Black Basta ransomware group. However, the version of Brute Ratel C4 used in this case is the same one reported by Trend Micro, which also involved the Black Basta ransomware group.

PlugX Malware Infection

Historically, a PlugX infection begins by hijacking a known and trusted, digitally signed software application to load an actor-created encrypted payload. This technique has been used since 2010 and is listed in the MITRE ATT&CK techniques as Hijack execution flow DLL-Side loading ID: T1574.002 Sub-technique T1574.

In this case, the threat actors decided to hijack a popular and free open source debugging tool for Windows called x64dbg, which is used by the malware analysis/reverse engineering community. X64dbg applications are digitally signed by "Open Source Developer Duncan Ogilvie."

The developers of this tool offer two types of debugger applications: x64 for 64-bit applications and x32 for 32-bit applications. In this case, the actors used x32dbg.exe, which is the 32-bit debugger of x64dbg.

Upon execution of x32dbg.exe, Microsoft Windows will attempt to resolve any dependency files necessary to run the application. That search starts locally (i.e., in the current working directory). If found, the necessary files are loaded and executed.

X32bridge.dll is a Windows Dynamic Link Library (DLL) dependency file of x32dbg.exe. A legitimate x32bridge.dll also carries the same digital signature. In this case, the file is not signed.

Once loaded, the malware searches locally for an actor-created encrypted payload file: x32bridge.dat (SHA256: e72e49dc1d95efabc2c12c46df373173f2e20dab715caf58b1be9ca41ec0e172).

X32bridge.dat was first submitted to VirusTotal on Jan. 22, 2021. As of Dec. 15, 2022, it has a detection score of eight out of 61 engines. None of the engines identify the file as PlugX malware.

Once loaded and decrypted in memory, the malware infects the host and any removable USB devices attached with the PlugX malware. Figure 1 below illustrates PlugX DLL side loading using x64dbg DLL hijacking.

Image 1 is a diagram of the process whereby the PlugX DLL sideloading.
Figure 1. PlugX DLL sideloading using x64dbg.

Both the hijacking of x64dbg and the association of this behavior with the PlugX malware were reported by Sophos back in November 2020. Their blog refers to this malware as KilllSomeOne, based on a Program Database (PDB) string found in one of the binaries.

Sophos performed an excellent analysis of the samples and touched on the USB infection. We confirmed that our sample matched the behaviors described in their report. From there, we wanted to expand our research by focusing on the USB infection, other USB variants in the wild and links to the PlugX malware.

PlugX Malware USB Overview

The technique used by the PlugX malware to hide files in a USB device involves using a certain Unicode character. This hinders Windows Explorer and the command shell (cmd.exe) from displaying the USB directory structure and any files, concealing them from the victim.

The Unicode character used by this PlugX malware for the directories is 00A0 (a whitespace character called a no-break space). The whitespace character prevents the Windows Operating System from rendering the directory name, concealing it rather than leaving a nameless folder in Explorer.

To achieve code execution of the malware from the hidden directory, a Windows shortcut (.lnk) file is created on the root folder of the USB device. The shortcut path to the malware contains the Unicode whitespace character, which is a space that does not cause a line break, but this is not visible when viewed via Windows Explorer, as shown below in Figure 2.

Image 2 is a screenshot of Windows Explorer, showing the Shortcut tab in the USB drive properties (named TESTDRIVE). It lists the target type, location and Target, where the target shows the hidden directory with extended ASCII characters.
Figure 2. Windows shortcut properties for accessing the hidden directory.

When the shortcut file is viewed in a hex editor, the hex representation of these characters is shown as highlighted below in Figure 3.

Image 3 is a screenshot of a hex editor where the extended ASCII characters are highlighted. There are two, and both are “A0”.
Figure 3. Windows shortcut properties shown in a hex editor display.

The PlugX malware uses the Component Object Model (COM) interface to create the .lnk files and includes the Unicode character 00A0. It does this by creating an instance of a shell desktop to create the associated Windows shortcut files. The ShellLink SetArguments method is used to set the command line arguments, which include the white space no break Unicode character, as shown in Figure 4 below.

Image 4 is a screenshot of the COM ShellLink command line arguments.
Figure 4. COM ShellLink::SetArguments.

Finally, the ShellLink::Save method saves the shortcut file with all the changes.

PlugX Malware USB Infection

The PlugX malware x32bridge.dll loads x32bridge.dat, which is responsible for implanting the host with malware and infecting any attached removable media USB devices such as floppy, thumb or flash drives. If a removable media device is found, the following steps are performed:

  1. It creates the following directory structure:
    <usb volume>:\u00A0\u00A0\RECYCLER.BIN\files. Example: F:\ \ \RECYCLER.BIN\files.
  2. It creates a hidden file named desktop.ini in each folder, which specifies the icon for the folder. This file contains the following data:

[.ShellClassInfo]
IconResource=%systemroot%\system32\SHELL32.dll,7

The Windows OS uses a single file to retrieve icon images that are displayed on the desktop as shortcuts or from Windows Explorer files and folders. The Shell32.dll file contains a list of icons and a unique number. In this case, the drive icon and the number 7 are used, as shown below in Figure 5.

Image 5 is a screenshot of the drive icon, showing a drive with a green light against a blue background. The number 7 is at the bottom.
Figure 5. Drive icon number 7.

The use of this drive icon makes the directories appear as drives within Windows Explorer when viewed with hidden files enabled. If deleted, the directories appear as folders.

  1. In the second directory, it creates a subfolder named RECYLER.BIN. This directory acts as a recycle bin. In that directory is a subdirectory named files and a hidden desktop.ini file. This desktop.ini file contains the following data:

[.ShellClassInfo]

CLSID = {645FF040-5081-101B-9F08-00AA002F954E}

This CLSID instructs Windows Explorer to display the created RECYCLER.BIN folder as a recycle bin directory by giving it the recycle bin icon. This is shown in Figure 11 as an example.

  1. The files subfolder contains copies of the PlugX malware x32dbg.exe, any encrypted actor .dat files and the actor’s malicious DLL. An example of this is shown in Figure 6 below.
Image 6 is a screenshot of the program WinHex displaying the name, extensions, size, created date, bodied date, accessed date, attribution, and sector number in the files subfolder.
Figure 6. Infected UBS removable device displayed via WinHex.

It should be noted that pre-infection of the USB device, existing files or directories on the root of the removable device are moved to the second hidden folder on the USB device, as shown below in Figure 7.

Image 7 is a side-by-side root directory comparison of a non-infected (left) versus an infected (right) USB device.
Figure 7. Side-by-side comparison of the root directories of a non-infected versus infected USB device.
  1. Whenever the shortcut file from the infected USB device is clicked, the PlugX malware launches Windows Explorer and passes the directory path as a parameter. This then displays the files on the USB device from within the hidden directories and also infects the host with the PlugX malware. The victim sees their files and assumes all is working as expected.

Figure 8 below illustrates how an infected USB thumb drive would appear to a victim in Windows Explorer using default settings (i.e., not displaying hidden files).

Image 8 is a screenshot of Windows Explorer showing the infected USB drive. Show hidden files is not enabled in this instance.
Figure 8. Windows Explorer showing infected USB Removable Device. (Show hidden files not enabled.)

An infected PlugX USB device has no files or directories in the root folder and contains only a .lnk file.

Figure 9 shows that the shortcut file is TESTDRIVE, which matches the USB device name. The shortcut file is responsible for infecting the host and navigating to the hidden directory on the USB device each time it is clicked. For example, the shortcut file referenced in Figure 9 contains the following data:

%comspec% /q /c " \ \RECYCLER.BIN\files\x32dbg.exe"

Once the target clicks the shortcut, x32dbg.exe is launched via cmd.exe from the hidden files directory on the USB device. The host the USB is attached to is now infected with the PlugX malware.

When viewing the contents of the infected USB device with Windows Explorer and hidden items enabled, a victim would see the following images:

Image 9 is a screenshot of Windows Explorer showing the root folder of the USB drive.
Figure 9. Windows Explorer showing infected USB Removable Device (root folder).

They would then see the following, as shown in Figure 10, within the first hidden directory:

Image 10 is a screenshot of Windows Explorer showing the root folder of the infected USB drive, displaying the first hidden directory.
Figure 10. Windows Explorer showing an infected USB removable device (hidden directory number one).

As shown in Figure 11, Windows Explorer displays another hidden directory along with a shortcut file. The shortcut file has the same properties to launch x32dbg.exe and will infect the host with the USB device attached.

When viewing the contents of the next hidden folder, Windows Explorer shows the following directory structure:

Image 11 is a screenshot of Windows Explorer showing the root folder of the infected USB drive, displaying the second hidden directory with a folder disguised as a recycling bin.
Figure 11. Windows Explorer showing infected USB Removable Device (hidden directory number two).

This directory contains a RECYLER.BIN folder that masquerades as a Windows recycle bin, along with any files or directories that existed in the root folder of the USB device at the time of infection. When viewing the contents of the RECYLER.BIN with Windows Explorer, a victim will see what’s shown in Figure 12:

Image 12 is a screenshot of Windows Explorer showing the contents of the RECYCLER.BIN folder. There are hidden malware files that cannot be detected outside of the use of specialized tools.
Figure 12. Windows Explorer showing infected USB Removable Device (RECYLER.BIN folder).

Since the default setting for Windows Explorer is not to show hidden items, the only item visible to the victim is the shortcut file, as shown in Figure 8. Even with hidden files enabled, Windows Explorer or cmd.exe cannot show the malware files that reside in the files subdirectory.

The malware files can only be viewed on a *nix OS or by mounting the USB device in a forensic tool. Figure 13 shows how the USB device looks once it’s mounted in Ubuntu, browsing to it via File Explorer.

Image 13 is a screenshot of how the USB drive looks while browsing its contents in Ubuntu’s File Explorer.
Figure 13. Ubuntu File Explorer viewing an infected USB device.

PlugX Malware Post USB Infection

When a host is infected with this variant of the PlugX malware, the malware continuously monitors for USB removable devices. Once a USB device is discovered and infected, any new files written to the USB device root folder post-infection are moved to the hidden folder within the USB device. Since the Windows shortcut file resembles that of a USB device and the malware displays the victim's files, they unwittingly continue to spread the PlugX malware.

PlugX Malware USB Variant Two

Armed with this knowledge, we wondered if other similar PlugX USB infection malware existed in the wild. File SHA256: 5b496972a86cea66aeecaac6e3f67a92e22f35cd5d2a98d54a2f1218fcd5dfc5 in VirusTotal matches the behaviors of x32bridge.dat, specifically the creation of the Windows Scheduled Task and PDB string referenced in the Sophos blog.

This file is a Windows x86 PE file (DLL), the in-memory equivalent of x32bridge.dat. Our analysis shows the runtime behavior is identical to the x32bridge.dat USB infection detailed earlier, but it has an added capability. It copies documents from the host machine to a new hidden USB subfolder named da520e5.

The malware specifically copies all Adobe PDF and Microsoft Word documents from the host to this directory. Figure 14 below shows an example of the directory and files copied from our host.

Image 14 is a screenshot of Drive F displaying the PlugX malware variant with two exfil files. It shows their names, extensions, size, creation and modification dates, access dates, attribution, and sector.
Figure 14. PlugX malware variant with two exfil files.

This PlugX USB malware variant was designed to exfiltrate specific files from its target that could be retrieved later, as this directory and files are not used by the malware or displayed to the victim.

Association With PlugX Malware

In addition to USB infection, both x32bridge.dat and the second PlugX malware variant discovered in VirusTotal check the target for specific running processes. If found, it terminates them and deletes the directories from which they were executed.

X32bridge.dat seeks out process names starting with AAM and, if found, terminates the process and deletes specific directories associated with the process. The Sophos blog speculated that this behavior likely removed older PlugX malware variants. Previous variants attributed to PlugX started with AAM file names (i.e., AAM Updates.exe).

The second variant we discovered in VirusTotal also performs this check, including one for the specific process file name AAM Updates.exe. Additionally, if AAM Updates.exe is found, it deletes the directory AAM UpdatesikB, which is a folder that has also been associated with the PlugX malware family.

Since both x32bridge.dat and the second PlugX malware variant discovered in VirusTotal share the same USB infection method along with other runtime behaviors, we can conclusively state that it is indeed associated with PlugX.

Conclusion

PlugX malware has been used for over a decade and was historically extensively associated with Chinese nation-state APT groups. Over the years, it has been adopted and used by other threat groups, from nation-states to ransomware actors.

The typical tradecraft of PlugX uses benign files to achieve code execution, also known as DLL side loading, that many security vendors now detect and prevent. This might be part of why the actors added the capability to infect any attached removable media USB devices such as floppy, thumb or flash drives as well as any additional systems the USB is later plugged into.

Any host infected with this variant of the PlugX malware will continuously monitor for new USB removable devices to infect. This PlugX malware also hides attacker files in a USB device with a novel technique, which makes the malicious files only viewable on a *nix OS or by mounting the USB device in a forensic tool. Because of this ability to evade detection, the PlugX malware can continue to spread and potentially jump to air-gapped networks.

Additionally, we discovered a similar variant of PlugX in VirusTotal with the added capability of copying all Adobe PDF and Microsoft Word documents from the infected host to the USB device's hidden folder created by the PlugX malware. The discovery of these samples indicates PlugX development is still alive and well among at least some technically skilled attackers, and it remains an active threat.

For Palo Alto Networks customers, our products and services provide the following coverage associated with this campaign:

  • Cortex XDR customers receive protection at the endpoints from the malware techniques described in this blog.
  • WildFire cloud-based threat analysis service accurately identifies the malware described in this blog as malicious.

If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, 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. Learn more about the Cyber Threat Alliance.

Unit 42 Managed Threat Hunting Queries

Indicators of Compromise

Known PlugX Samples:

8ec37dac2beaa494dcefec62f0bf4ae30a6ce44b27a588169d8f0476bbc94115
e72e49dc1d95efabc2c12c46df373173f2e20dab715caf58b1be9ca41ec0e172
0e9071714a4af0be1f96cffc3b0e58520b827d9e58297cb0e02d97551eca3799
39280139735145ba6f0918b684ab664a3de7f93b1e3ebcdd071a5300486b8d20
41a0407371124bcad7cab56227078ccd635ba6e6b4374b973754af96b7f58119
02aa5b52137410de7cc26747f26e07b65c936d019ee2e1afae268a00e78a1f7f
2a07877cb53404888e1b6f81bb07a35bc804daa1439317bccde9c498a521644c
5d98d1193fcbb2479668a24697023829fc9dc1f7d31833c3c42b8380ef859ff1

Known File Directories

C:\ProgramData\UsersDate\Windows_NT\Windows\user\Desktop\
C:\Users\Public\Public Mediae\
<usb volume>:\u00A0\u00A0\RECYCLER.BIN\files
<usb volume>:\u00A0\u00A0\RECYCLER.BIN\files\da520e5

Known Windows Mutex Names

LKU_Test_0.1
LKU_Test_0.2
TCP_0.1

Known PlugX Encrypted Payload File Names

akm.dat
precious.dat
x32bridge.dat
Groza_1.dat

Known Windows Scheduled Task Names

LKUFORYOU_1
PRECIOUS_0.1

Known Windows Process Names (Observed Abused Benign Files)

x32dbg.exe
x32dbge.exe
Mediae.exe
Aug.exe
Precious.exe
SafeGuard.exe
Dism.exe

MITRE ATT&CK Techniques

ATOM PlugX Malware

Additional Resources

 

Realtek SDK Vulnerability Attacks Highlight IoT Supply Chain Threats

Posted on by Zhibin Zhang

Executive Summary

Unit 42 researchers review tens of millions of attack records every month, and most months, attacks targeting a single vulnerability do not exceed 10% of the total number of attacks. However, we discovered that between August and October 2022, the number of attacks attempting to exploit a Realtek Jungle SDK remote code execution vulnerability (CVE-2021-35394) accounted for more than 40% of the total number of attacks.

As of December 2022, we’ve observed 134 million exploit attempts in total leveraging this vulnerability, and about 97% of these attacks occurred after the start of August 2022. At the time of writing, the attack is still ongoing.

Many of the attacks we observed tried to deliver malware to infect vulnerable IoT devices. This tells us that threat groups are using this vulnerability to carry out large-scale attacks on smart devices around the world. While the attacks we observed were successfully blocked by our products, it’s important to assess protection of these devices in your environment. Because IoT devices and routers are often not considered as part of an organization’s security posture, many devices and organizations could still be at risk.

CVE-2021-35394 affects almost 190 models of devices from 66 different manufacturers. We believe that this vulnerability attracted so many attackers because supply chain issues can make it difficult for the average user to identify the affected products that are being exploited.

In response to this concerning phenomenon, we dug deep into all the attack records of this vulnerability from when it was disclosed to December 2022 for analysis.

Palo Alto Networks customers receive protections from the vulnerability and malware families mentioned in this post with the Next-Generation Firewall with cloud-delivered security services including WildFire. Advanced URL Filtering and DNS Security can block the command and control (C2) domain and malware hosting URLs. Our IoT Security platform can help identify anomalous network traffic, as well as determining the vendor, model and firmware version of a device to identify specific devices that are vulnerable to the aforementioned CVE.

Related Unit 42 Topics IoT, Vulnerability, Supply Chain, CVE-2021-35394

Vulnerability Overview

CVE-2021-35394 was disclosed on Aug. 16, 2021. The vulnerability affects UDPServer in Realtek Jungle SDK version 2.0 and later-Realtek Jungle SDK version 3.4.14B. Remote unauthenticated attackers could leverage this vulnerability to achieve arbitrary command execution, leading to devices being taken over.

Realtek chipsets are used by many IoT vendors in a variety of different products. This is a typical supply chain issue in that it can be difficult to identify whether your own devices are impacted, as the chipset may not be visible from the exterior of the device. According to a Shodan scan searching for this vulnerability, we found port 9034 open in over 80 different IoT devices, and these devices belong to 14 unique vendors.In particular, we noted that router models manufactured by several popular networking vendors are affected by CVE-2021-35394. Based on crowdsourced data from enterprise networks monitored by the Palo Alto Networks IoT Security product, the brands in Table 1 have the most popular vulnerable devices in mid-to-large sized deployments. The supply chain vulnerabilities in these products directly contribute to expanding the attack surface of these networks.

(Note that the vendors who produce these devices may have released updated versions or recommended mitigations. However, organizations sometimes continue to use vulnerable models, and threat actors take advantage of such situations.)

Vendor Name Number of Models Vulnerable
D-Link 31
LG 8
Belkin 6
Zyxel 6
Asus 4
Netgear 1

Table 1. Vulnerable IoT networking devices.

Based on the attacks we have seen in the wild, we found the following three types of payloads:

  • A script executes a shell command on the targeted server. This script actively connects to a malicious IP address, and automatically downloads and executes malware (shown in Figure 1). These threats were mostly from the Mirai malware family.
Image 1 is a screenshot of two lines of code. It is the first payload of CVE-2021-35394.
Figure 1. CVE-2021-35394 payload one.
  • An injected command directly writes the binary payload to a file and then executes it (shown in Figure 2).
Image 2 is a screenshot of the second payload of CVE-2021-35394. It is many lines of binary where the injected command writes this binary payload into a file for execution.
Figure 2. CVE-2021-35394 payload two.
  • An injected command directly reboots the targeted server to achieve denial of service (shown in Figure 3).
Image 3 is a screenshot of a code snippet, showing the third payload of CVE-2021-35394. It achieves a denial of service.
Figure 3. CVE-2021-35394 payload three.

Malware Analysis

Unit 42 researchers conducted analysis of malware samples that are delivered through the exploitation of CVE-2021-35394. Based on the attacks we have seen in the wild, most of the malware samples are from well-known malware families like Mirai, Gafgyt and Mozi. We also observed a new distributed denial-of-service (DDoS) botnet developed in Golang, called RedGoBot (SHA256: 26e96945ee32199536d4c85124a24c28e853b557eb31f3907d19f08b9798dff4)

RedGoBot’s first campaign was first observed in early September 2022. The threat actor tries to deliver a shell script znet.sh downloader from 185.216.71[.]157 utilizing wget.

The script downloads the following files:

  • hxxp://185.216.71[.]157/Bins_Bot_hicore_amd64
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_arm64
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_arm
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_mips
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_mips64
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_ppc64
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_ppc64le
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_s390x
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_mipsle
  • hxxp://185.216.71[.]157/Bins_Bot_hicore_mips64le

The second wave of the RedGoBot campaign was observed in November 2022, when the threat actor switched its malware host to 185.246.221[.]220.

In this campaign, the shell script utilizes wget and curl to download the following botnet clients to accommodate different processor architectures:

  • hxxp://185.246.221[.]220/Bins_Bot_hicore_s390x
  • hxxp://185.246.221[.]220/Bins_Bot_hicore_ppc64le
  • hxxp://185.246.221[.]220/Bins_Bot_hicore_ppc64
  • hxxp://185.246.221[.]220/Bins_Bot_hicore_mipsle
  • hxxp://185.246.221[.]220/Bins_Bot_hicore_mips
  • hxxp://185.246.221[.]220/Bins_Bot_hicore_arm64
  • hxxp://185.246.221[.]220/Bins_Bot_hicore_arm
  • hxxp://185.246.221[.]220/Bins_Bot_hicore_amd64

The botnet client can accept the following command and control (C2) channel commands.

Command Description
exec Remote OS command execution
attack Launch DDoS attacks
kill-bot Terminate bot client execution
update-bot No related function for updating

Table 2. RedGoBot C2 commands.

After receiving the attack command from the threat operator, the RedGoBot can perform DDoS attacks on HTTP, ICMP, TCP, UDP, VSE and OpenVPN protocols.

Protocol Method Description
HTTP POST HTTP POST Flood
GET HTTP GET Flood
ICMP N/A ICMP Flood
TCP ACK TCP ACK Flood
PSH TCP PUSH Flood
HANDSHAKE TCP Handshake Flood
HOLD TCP Hold Flood
SYN TCP SYN Flood
UDP N/A UDP Flood
VSE N/A VSE Flood
OpenVPN N/A OpenVPN Flood (UDP)

Table 3. RedGoBot supported DDoS types.

Attack Origin Analysis

From August 2021 to December 2022, we have observed 134 million exploit attempts in total, targeting CVE-2021-35394, with 97% of these attacks occurring after the start of August 2022. More than 30 international regions were involved as the attack origins, with the United States being the largest source of attacks at 48.3% of the total. Vietnam, Russia, The Netherlands, France, Luxembourg and Germany were also found to be in the top seven countries from which we observed threat actors taking part in these attacks (shown in Figure 4). However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.

Image 4 is a chart showing the percentage, by country, of the attack origin distribution, with the United States at 46.4% followed by Vietnam and Russia.
Figure 4. Attack origin distribution.

Figure 5 shows these attack counts broken down by month from August 2021 to December 2022, for top attack origins.

Image 5 is a chart that details attack trends over time by country origin, starting in October 2021 to December 2022. The attacks peak sharply in July through the end of October.
Figure 5. Attack trends over time.

Starting from August 2022, the number of attacks targeting this vulnerability began to increase, and reached a peak in September and October. In November, the attack attempts drastically decreased but were still in a pretty high state.

It's also notable that around 95% of the attacks leveraging CVE-2021-35394 that originated from Russia were targeting organizations in Australia.

Over 98% of attacks originating from Vietnam in this time period were against CVE-2021-35394, and the majority of attacks from Russia and The Netherlands also leveraged this vulnerability.

According to the latest data from November and December, attacks against CVE-2021-35394 suddenly appeared in large numbers from Luxembourg (accounting for 94.6% of the total attacks in the region). Attacks targeting this vulnerability from Vietnam, which accounted for a high proportion in previous months, decreased significantly in November and December (accounting for 3% of the total number of attacks in the region). This could mean that the attacker is changing the proxy while continuing to exploit this vulnerability.

Figure 6 shows the percentage of attacks targeting CVE-2021-35394 out of the total overall attacks, from August to December 2022. The countries the attacks are coming from are sorted from the highest total number of attacks exploiting CVE-2021-35394 to the least.

Image 6 is a stacked bar chart comparing the total overall attacks to attacks targeting CVE-2021-35394.
Figure 6. Percentage of attacks targeting CVE-2021-35394 out of overall attacks.

The following IP addresses were the top 12 originators of attacks targeting CVE-2021-35394.

IP Attack source region # of attacks (million)
199.195.251[.]190 United States 39.8
172.81.41[.]196 United States 17.2
103.149.137[.]124 Vietnam 10.6
103.149.137[.]138 Vietnam 10.5
46.249.32[.]181 The Netherlands 9.9
37.44.238[.]148 France 1.7
37.44.238[.]185 France 1.3
37.44.238[.]217 France 1.2
69.67.150[.]36 United States 1.2
37.44.238[.]144 France 1.2
103.149.137[.]192 Vietnam 1.2
185.122.204[.]30 Russia 1.1

Table 4. Top attacker IP addresses.

We also analyzed and decoded all the attack payloads, which allowed us to summarize the malicious payload that connects to other malware hosting sites that we mentioned earlier. We then counted the callback URLs that appeared more frequently, which are shown in the table below. The attack source region in each cell is listed from most total attacks to least.

From this data, we can see that when launching a campaign, attackers could host the malware on multiple sites. This allows them to send malicious attack payloads from different regions, either by using the machines in the specific region or by compromising a device in the region and commanding it to spread the threat.

Callback URLs Attack source region # of Attacks (million)
hxxp://185[.]205[.]12[.]157/trc/TRC[.]mpsl United States, The Netherlands, Canada, 31.4
hxxp://172[.]81[.]41[.]196/trc/TRC[.]mpsl The, United States, Germany 10.6
hxxp://135[.]148[.]104[.]21/mipsel Vietnam, Kenya, France, United States, Singapore, India 8.1
hxxp://199[.]195[.]251[.]190/trc/TRC[.]mpsl United States, Canada, Germany, 2.0
hxxp://37[.]44[.]238[.]178/d/xd[.]mpsl France, Kenya, United States, 1.7
hxxp://176[.]97[.]210[.]135/assailant[.]mpsl France, United States 1.2
hxxp://198[.]98[.]56[.]129/trc/TRC[.]mpsl United States, Saint Kitts and Nevis, 1.2
hxxp://141[.]98[.]6[.]249/billy[.]sh United States, Kenya, 1.1
hxxp://185[.]216[.]71[.]157/Bins_Bot_hicore_mipsle United States, Vietnam, Kenya, France 0.7
hxxp://45[.]140[.]141[.]205/bins/sora[.]mpsl United States, Germany, The Netherlands, 0.5

Table 5. Top 10 callback URLs

Conclusion

The surge of attacks leveraging CVE-2021-35394 shows that threat actors are very interested in supply chain vulnerabilities, which can be difficult for the average user to identify and remediate. These issues can make it difficult for the affected user to identify the specific downstream products that are being exploited.

Having robust security protections in place can help you block the malicious traffic we’ve described. If you confirm that a device has been affected by the malware referenced in this post, it is necessary to apply a factory reset on the device and reinstall the latest version of its software.

At home, if you have IoT or network devices from the aforementioned vendor list and have not recently looked for software updates or patches, now is a good time to do so. If you are able to determine that these devices are running slow or sending out a large amount of traffic to contact unknown domains, this could be a sign that your device has been affected by attackers.

We strongly recommend regularly applying patches and upgrades on smart devices as well as traditional desktops and mobile devices whenever possible, to ensure the best protections.

Palo Alto Networks customers receive protections from the vulnerability and malware referenced in this post through the following products and services:

  • Next-Generation Firewalls with a Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signatures 91535.
  • WildFire can stop the malware referenced in this article with static signature detections.
  • Advanced URL Filtering and DNS Security are able to block the C2 domain and malware hosting URLs.
  • The Palo Alto Networks IoT security platform can leverage network traffic information to identify the vendor, model and firmware version of a device and identify specific devices that are vulnerable to the aforementioned CVE.
  • In addition, IoT Security has an inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits non-typical behavior, such as a sudden appearance of traffic from a new source, an unusually high number of connections or an inexplicable surge of certain attributes typically appearing in IoT application payloads.

Indicators of Compromise

Infrastructure

Malicious IPs

  • 199[.]195[.]251[.]190
  • 172[.]81[.]41[.]196
  • 103[.]149[.]137[.]124
  • 103[.]149[.]137[.]138
  • 46[.]249[.]32[.]181
  • 69[.]67[.]150[.]36
  • 103[.]149[.]137[.]192
  • 45[.]125[.]236[.]14
  • 173[.]247[.]227[.]66
  • 173[.]247[.]227[.]70
  • 185[.]122[.]204[.]30
  • 45[.]95[.]55[.]188
  • 2[.]58[.]113[.]79
  • 45[.]95[.]55[.]24
  • 45[.]95[.]55[.]218
  • 45[.]95[.]55[.]189
  • 193[.]142[.]146[.]35
  • 37[.]139[.]129[.]11
  • 78[.]135[.]85[.]70
  • 45[.]137[.]21[.]166
  • 195[.]178[.]120[.]183
  • 195[.]133[.]81[.]29
  • 5[.]253[.]246[.]67
  • 45[.]61[.]184[.]133
  • 45[.]61[.]184[.]118
  • 149[.]5[.]173[.]33
  • 163[.]123[.]143[.]226
  • 45[.]61[.]188[.]148
  • 103[.]207[.]38[.]165
  • 45[.]13[.]227[.]115
  • 176[.]97[.]210[.]147
  • 163[.]123[.]143[.]200
  • 185[.]44[.]81[.]62
  • 38[.]22[.]109[.]7
  • 147[.]182[.]132[.]144
  • 205[.]185[.]126[.]88
  • 209[.]141[.]51[.]43
  • 198[.]98[.]52[.]213
  • 45[.]95[.]55[.]185
  • 20[.]249[.]89[.]181
  • 3[.]235[.]28[.]168

Callback URLs

hxxp://185.205.12[.]157/trc/TRC[.]mpsl
hxxp://172.81.41[.]196/trc/TRC[.]mpsl
hxxp://135.148.104[.]21/mipsel
hxxp://199.195.251[.]190/trc/TRC[.]mpsl
hxxp://37.44.238[.]178/d/xd[.]mpsl
hxxp://176.97.210[.]135/assailant[.]mpsl
hxxp://198.98.56[.]129/trc/TRC[.]mpsl
hxxp://141.98.6[.]249/billy[.]sh
hxxp://185.216.71[.]157/Bins_Bot_hicore_mipsle

Artifacts

RedGoBot Malware Sample

26e96945ee32199536d4c85124a24c28e853b557eb31f3907d19f08b9798dff4
1967370203138b9324f11c5cb3fd15ac8d2f0c585373486614600b676a4e2641
78953c71318fb93fa90607039bceb48f2746a8abfa3a9a8914c8fdc48ebf55df
57d39a6a88093c9e1fbc1626105d714be92680bdf666279b7663bcaaf7fa7e6e
78b55d3f1b34f1154a28ce4fc855252bc3104a07944053facf6acce9195b2e77
81e581ed06515af959c8477442243f20baa77c0e54a1054542900936c6e81ff5
ab3de77616b4d85f032a226da6c3629de4a8f1c1b4d32674c1bed30afb9419e1
a877b4e71c8f2f4ab6915cbe8c57c82ac12331e183f7cbda2de4dc3780a50379
26e96945ee32199536d4c85124a24c28e853b557eb31f3907d19f08b9798dff4
5e647d4991f9d339e6e83cee6168915e1e2c9fac0cddc53d3083cbc96a278035
6bca8cf5e48e819179f8473e4e600da2c1ef00802bf1744885dcb5ad56618943

Mirai Samples

bc03af5c06a7ff6774688e8d71f6d06e0d402f4f86d5b23969bc53d5eab3e522
67f73e1efa3c3a05e896567dfb2cef56e9b5eb33283a13e5934900030357e7e6
ebfedbcf428215d34d8f876fb9c5658048dbb4c5607f328ae155bf26a292b38d
e0fd14114737e4a599f0769683de4faf54cefae1cc106d9f475aa23bdbf5a753
5967a4889b54b97adbb6b949ffd590fa416599326eb3432f40fa142aab1df795
ff8a1abcd4fa94ffc0f1f43a92f816e6bd08272ec54d748cf004c3ef1323d5d9
080a64d595ff246d01b920d5010cffcb4ac56f224acdec32ee3eab08099c6a7b
e1d3adcb85298a08973b7ae6702cc4830d20ebde98e2eac85179c1bbba3ef7ac
edec8e8d4c2ec0c489e4c5dbb89994c223f29e8d4470825bd488bf1a44e42751
28d6dce95ffb8186ac8c611dee0681cca028bbf93365e4f0c7c67c235d3034a3
97878c28d915e2b56e7c06436d209a9198eb0c50bdfb1fd4602e9e95b5eb4321
637dc2a8baf2a46ffe872aedc823ab766b4a9fbab129b2c7dc9513ba8ee712bc
0d2c3120464184610ac939c34e5309968bd7b81255708307d545d742f3468930
f3a3e90ea713215a4d30f0f142d6ef0f1ed72b246ee297b8bba64921dbf4300c
3f8b5887ae0ef8b51845bf0f2996c4f9891cdc0724b7d0ccc3dbc1b4cdae11a2
1a70ceb57768d3e027e307abd09548f151a8d6da72532f1b88e9813eaf0bdad2
2ef3040947c9d51317e103457a6613ac9297cb610b3691ef6d440f15cb36a9ed
9b7eb2cf51d806076e1662ca4ad800c1de421234c19fbea44b56eb47cc616fd8

Answers to Unit 42 Wireshark Quiz, January 2023

Posted on by Brad Duncan

Executive Summary

This blog presents the answers for our January 2023 Unit 42 Wireshark quiz. The information is ideal for security professionals who investigate suspicious network activity, but everyone is welcome to review. To get the most benefit, readers should understand basic network traffic concepts and be familiar with Wireshark.

If you’d like to view the version without answers, please see the standalone quiz post. 

Related Unit 42 Topics AgentTesla, OriginLogger, pcap, Wireshark, Wireshark Tutorial

Background, Requirements and Quiz Material

This quiz is based on a Palo Alto Networks Unit 42 tweet about Agent Tesla-style activity from a possible OriginLogger infection that was found Thursday, Jan. 5, 2023. Figure 1 provides a chain of events from the infection.

Image 1 is a flow chart showing the Agent Tesla variant infection, starting with malspam. It shows the circuitous route the loader.exe takes depending on the victim’s actions.
Figure 1. Flow chart for the Agent Tesla variant infection.

Our investigation for this month’s quiz requires Wireshark. This blog utilizes a recent version of Wireshark, and we recommend Wireshark version 3.x. We also use the Thunderbird email client to review an email extracted from the packet capture (pcap).

Participants should have some basic knowledge of network traffic fundamentals. We also recommend readers customize their Wireshark display to better analyze web traffic. A list of tutorials and videos is available. As always, we recommend using Wireshark in a non-Windows environment like BSD, Linux or macOS when analyzing malicious Windows-based traffic.

To obtain the pcap, visit our Github repository. Download the ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.

Quiz Questions

The Unit 42 Wireshark quiz for January 2023 has the following questions:

  • When did the malicious traffic start in UTC?
  • What is the victim’s IP address?
  • What is the victim’s MAC address?
  • What is the victim’s Windows host name?
  • What is the victim’s Windows user account name?
  • How much RAM does the victim’s host have?
  • What type of CPU is used by the victim’s host?
  • What is the public IP address of the victim’s host?
  • What type of account login data was stolen by the malware?

Quiz Answers

The answers for our January 2023 Unit 42 Wireshark quiz are:

  • The malicious traffic started 2023-01-05 at 22:51 UTC
  • Victim’s IP address: 192.168.1[.]27
  • Victim’s MAC address: bc:ea:fa:22:74:fb
  • Victim’s Windows host name: DESKTOP-WIN11PC
  • Victim’s Windows user account name: windows11user
  • Amount of victim’s RAM on victim’s host: 32 GB
  • Victim’s CPU: Intel(R) Core(TM) i5-13600K
  • Victim’s public IP address: 173.66.46[.]112
  • Type of stolen account data: email and web accounts

Pcap Analysis

Our analysis assumes you have customized Wireshark according to our tutorials or workshop videos.

Analyzing the pcap requires a basic knowledge of network traffic. You should understand that a router acts as a gateway between public-facing IP addresses and hosts within an internal network.

Participants should recognize internal, non-routable IPv4 addresses. We commonly find one of three classes for non-routable internal IPv4 addresses behind an internet router:

  • Class A: 10.0.0[.]0/8 (10.0.0[.]0 through 10.255.255[.]255)
  • Class B: 172.16.0[.]0/12 (172.16.0[.]0 through 172.31.255[.]255)
  • Class C: 192.168.0[.]0/16 (192.168.0[.]0 through 192.168.255[.]255)

In most pcaps, the victim’s IP address is from the internal network. For this month’s pcap, our victim is using a Class C non-routable IP address in the 192.168.0[.]0/16 range.

How do we find the victim’s IP address? Use the basic web filter provided in our Wireshark tutorials, or type the following in your Wireshark filter bar:

http.request or tls.handshake.type eq 1

In the frame details panel for any frame listed in the column display, the source IP address should be 192.168.1[.]27. The frame details also provide a MAC address that corresponds to 192.168.1[.]27 as shown below in Figure 2.

Image 2 is a screenshot of the Wireshark program. Highlighted in boxes and with arrows are the victim’s IP address and MAC address in the program.
Figure 2. Finding the victim’s IP address and MAC address in Wireshark.

In some pcap files, NBNS or SMB traffic provides a victim’s Windows host name. Use the following filter in Wireshark:

nbns or smb or smb2

The default host name for a Windows 10 and Windows 11 computer is a 15 character string. The name starts with DESKTOP- and is followed by an alpha-numeric string of seven additional ASCII characters. In Figure 3, we find DESKTOP-WIN11PC in the frame details from one of the frames in the column display.

Image 4 is a screenshot of the Wireshark program. This shows the SMB traffic from the cpap.
Figure 3. Finding the victim’s Windows host name in Wireshark.

Please note that threat actors often abuse legitimate products and operating system features for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate software being abused.

The remaining information for this quiz is from stolen data in the unencrypted SMTP traffic. Type smtp in your Wireshark filter. The results reveal several frames as shown below in Figure 4.

Image 4 is a screenshot of the Wireshark program. This shows the SMTP traffic from the cpap.
Figure 4. Finding SMTP traffic from the pcap in Wireshark.

These frames represent a single TCP stream of traffic. Follow the TCP stream to review the associated email as shown in Figures 5 and 6.

Image 5 is a screenshot of the Wireshark program. Arrows highlight menu windows that show how to follow a single TCP stream.
Figure 5. Follow TCP stream for any of the frames in your column display.
Image 6 is a screenshot of the Wireshark program. It shows the TCP stream of the unencrypted SMTP traffic. Some information has been retracted through blurring.
Figure 6. TCP stream of the unencrypted SMTP traffic.

Figure 6 shows the infected Windows host using one email address to relay stolen data to another address. The recipient address collects similar data from other hosts infected by the same malware. The message text has HTML tags, and it is somewhat cumbersome to read.

To more easily view this stolen data, export the email from our pcap, then open the exported file in a Thunderbird email client. Use the following menu chain in Wireshark:

File → Export Objects → IMF

Actions to export the email from the pcap in Wireshark should look similar to Figures 7 and 8.

Image 7 is a screenshot of the Wireshark program. It shows with arrows how to access the File menu that allows the user to export an IMF file.
Figure 7. Exporting an email from unencrypted SMTP traffic in Wireshark.
Image 8 is a screenshot of the Wireshark program. It shows two windows, showing the process to save an exported email as an .eml file.
Figure 8. Saving the exported email as an .eml file.

Once the email has been saved, open the file in Thunderbird to see the content. Figure 9 shows the exported message viewed in Thunderbird.

Image 9 is a screenshot of the Thunderbird program, an email program. It shows the exported email.
Figure 9. Viewing the exported email in Thunderbird.

The email contains information about the infected Windows host, including account credentials saved by the victim’s email client (Thunderbird) and web browser (Microsoft Edge). Stolen data includes information such as the operating system, Windows user account name, CPU, amount of RAM and public IP address of the infected host.

Of note, none of these are legitimate login credentials. Before running the malware, we populated the host with fake login data. However, the traffic illustrates the type of data stolen by Agent Tesla variants like OriginLogger.

Conclusion

This blog provides answers to our Unit 42 Wireshark quiz for January 2023. We reviewed traffic from the pcap to answer characteristics of the infected Windows host, and we discovered what type of data this malware steals.

Many organizations lack access to full packet capture in their IT environment. As a result, many security professionals lack experience in reviewing network traffic. Training material like this Wireshark quiz can help. Pcap analysis is a useful skill that helps us better understand malicious activity.

You can also find the original post, without answers, for this month’s Unit 42 Wireshark quiz.

Palo Alto Networks customers receive protections from Agent Tesla variants like OriginLogger through Cortex XDR and our Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Additional Resources

Wireshark Tutorial: Wireshark Workshop Videos Now Available – Unit 42, Palo Alto Networks

Updated Jan. 30, 2023, at 12:26 p.m. PT to correct MB to GB in quiz answers. 

Unit 42 Wireshark Quiz, January 2023

Posted on by Brad Duncan

Executive Summary

Welcome to the January 2023 Unit 42 Wireshark quiz. This blog presents a packet capture (pcap) of malicious activity and asks questions based on information derived from the network traffic. A separate Unit 42 blog post will present the answers with detailed explanations.

These quizzes are designed for security professionals who investigate suspicious network activity, but anyone can participate. To get the most benefit, readers should understand basic network traffic concepts and be somewhat familiar with Wireshark.

The material provides experience reviewing real-world traffic from a live environment.

Related Unit 42 Topics AgentTesla, OriginLogger, pcap, Wireshark, Wireshark Tutorial

Background

Earlier this month, Palo Alto Networks Unit 42 tweeted about Agent Tesla-style activity from a possible OriginLogger infection that was found Thursday, Jan. 5, 2023. The original tweet contains our initial analysis. You can also find further information on the associated malware binary.

Image 1 is a flow chart showing the Agent Tesla variant infection, starting with malspam. It shows the circuitous route the loader.exe takes depending on the victim’s actions.
Figure 1. Flow chart for the Agent Tesla variant infection.

For this month’s exercise, we generated a pcap of network traffic from this malware sample. Post-infection activity contains unencrypted SMTP traffic with data stolen from the infected computer.

Requirements

Our analysis requires Wireshark, a well-known tool used to review pcaps. However, its default settings are not optimized for web-based malware traffic. Therefore, we encourage people to customize Wireshark after installing it. To help, Unit 42 has published a series of tutorials and videos that include customizing Wireshark.

We recommend using the latest 3.x version of Wireshark, since it has more features, capabilities and bug fixes over previous Wireshark versions.

Furthermore, we recommend using a non-Windows environment like BSD, Linux or macOS to analyze malicious traffic. The pcap for this quiz contains HTTP traffic of an obfuscated binary. If decoded, this binary becomes a malicious DLL file, as previously noted in the indicators for this infection posted on Github. The decoded malware presents a risk of infection when using a Windows computer.

Quiz Material

To obtain the pcap for this month’s quiz, visit our Github repository. Download the ZIP archive and extract the pcap as shown below in Figures 2 and 3. Use infected as the password to unlock the ZIP archive.

Figure 2. Download the ZIP archive containing the pcap from our Github repository.
Figure 2. Download the ZIP archive containing the pcap from our Github repository.
Arrows indicate where to enter the password in order to extract the pcap from the password-protected archive
Figure 3. Extract the pcap file from the password-protected ZIP archive.

Quiz Questions

When did this activity first occur? Format your answer as Universal Coordinated Time (UTC). When sharing threat intelligence, UTC ensures recipients understand the exact time regardless of time zone.

Can you identify the infected host? For a Windows computer, the basic identifiers are the following:

  • Victim’s IP address
  • Victim’s MAC address
  • Victim’s Windows host name
  • Victim’s WIndows user account name

This month, our infected host is a stand-alone Windows client. In addition to Windows system traffic, the pcap also contains unencrypted SMTP traffic generated by the malware. This traffic contains additional information, so we can determine all four of the above identifiers.

The SMTP traffic includes various login credentials from the infected host. Of note, this traffic does not contain legitimate credentials. We populated the host with fake login data before we ran the malware. Despite the fake data, this traffic provides a better understanding of data stolen by Agent Tesla variants like OriginLogger.

Review the pcap and answer the following questions for this month’s Unit 42 Wireshark quiz:

  • When did the malicious traffic start in UTC?
  • What is the victim’s IP address?
  • What is the victim’s MAC address?
  • What is the victim’s Windows host name?
  • What is the victim’s Windows user account name?
  • How much RAM does the victim’s host have?
  • What type of CPU is used by the victim’s host?
  • What is the public IP address of the victim’s host?
  • What type of account login data was stolen by the malware?

Conclusion

Palo Alto Networks encourages members of the security community to develop their skills, so we can all better protect our digital way of life. This month’s Wireshark quiz can help participants accomplish that goal.

The answers to this month’s Unit 42 Wireshark quiz are available in a separate blog post located here.

Palo Alto Networks customers receive protections from Agent Tesla variants like OriginLogger through Cortex XDR and our Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Additional Resources

Wireshark Tutorial: Wireshark Workshop Videos Now Available – Unit 42, Palo Alto Networks

Updated Jan. 20, 2023, at 11:15 a.m. PT to correct Figure 3. 

Updated Jan. 23, 2023, at 7:38 a.m. PT to add link to quiz answers post.  

Chinese Playful Taurus Activity in Iran

Posted on by Unit 42

Executive Summary

Playful Taurus, also known as APT15, BackdoorDiplomacy, Vixen Panda, KeChang and NICKEL, is a Chinese advanced persistent threat group that routinely conducts cyber espionage campaigns. The group has been active since at least 2010 and has historically targeted government and diplomatic entities across North and South America, Africa and the Middle East.

In June 2021, ESET reported that this group had upgraded their tool kit to include a new backdoor called Turian. This backdoor remains under active development and we assess that it is used exclusively by Playful Taurus actors. Following the evolution of this capability, we recently identified new variants of this backdoor as well as new command and control infrastructure. Analysis of both the samples and connections to the malicious infrastructure suggests that several Iranian government networks have likely been compromised by Playful Taurus.

Palo Alto Networks customers receive protections from the threats described in this blog through Advanced URL Filtering, DNS Security, Cortex XDR and WildFire malware analysis.

Names for Threat Actor Group Discussed Playful Taurus, APT15, BackdoorDiplomacy, Vixen Panda, NICKEL

Playful Taurus Infrastructure

In 2021, the domain vpnkerio[.]com was identified as part of a Playful Taurus campaign targeting diplomatic entities and telecommunications companies across Africa and the Middle East. Since then, this domain and its associated subdomains have shifted hosting to several new IP addresses. Notably, several of the subdomains currently resolve to 152.32.181[.]16.

Analyzing this IP, we identified an expired X.509 certificate that appeared to be associated with Senegal’s Ministry of Foreign Affairs (MFA), CN=diplosen.gouv[.]sn.

Suspected Playful Taurus X509 Certificate
SHA-1 cfd9884511f2b5171c00570da837c31094e2ec72
Issued 2020-04-23
Expires 2021-04-29
Common Name diplosen.gouv[.]sn
Organization Name DigiCert, Inc.
SSL Version 3
Locality Dakar
Country SN

Table 1. Suspected Playful Taurus certificate.

Despite expiring in April 2021, this certificate continued to be associated with recent infrastructure. For example, this certificate was first observed on 152.32.181[.]16 in April 2022, a full year after it had expired. Coincidentally, that same month, subdomains for vpnkerio[.]com began resolving to this IP.

Exploring all IP associations with this certificate, we found that this certificate was initially associated with what we assess is likely legitimate Senegal government infrastructure. This association remained consistent until the expiration of the certificate in April 2021. Following its expiration, this certificate has been associated with nine different IP addresses. Eight of those nine IPs have hosted Playful Taurus domains.

Observed Activity

Monitoring connections to the malicious infrastructure, we observed the following four Iranian organizations attempting to connect to 152.32.181[.]16 between July and late December 2022.

Iranian Connections to Playful Taurus Infrastructure
IP Address Organization
109.201.27[.]66 Iranian Government Infrastructure
185.4.17[.]10 Foreign Ministry of Iran Infrastructure
37.156.28[.]101
37.156.29[.]172		 Suspected Iranian Government Infrastructure
31.47.62[.]201 Iranian Natural Resource Organization

Table 2. Iranian connections to Playful Taurus infrastructure.

The sustained daily nature of these connections to Playful Taurus controlled infrastructure suggests a likely compromise of these networks. Moreover, these targets also fit historical targeting patterns by the group.

Inside the Wire

While researching the Iranian infrastructure in Table 2, we found that the first IP (109.201.27[.]66) hosted what appears to be a legitimate Foreign Ministry of Iran domain (pro.mfa[.]ir) between May and November 2019. This IP also resides on a netblock that hosts other Iranian government domains.

However, since September 2021, this IP has hosted the domain mfaantivirus[.]xyz. The use of the .xyz top level domain (TLD) seems odd for an IP and netblock that hosts legitimate Iranian government domains.

The registration record for mfaantivirus[.]xyz shows that it was registered by an organization that has only registered eight other domains. Three of those domains, including mfaantivirus[.]xyz, stand out for being hosted on Iranian government netblocks. The two additional domains hosted on Iranian government infrastructure are as follows.

Registration Organization Overlap
IP Domain Owner
109.201.27[.]67 pfs1010[.]xyz Foreign Ministry of Iran

Reverse PTR: cp.econsular[.]ir
109.201.19[.]184 pfs1010[.]com Foreign Ministry of Iran

Table 3. Domains sharing a registering organization with mfaantivirus[.]xyz.

The first IP in Table 3 contains a reverse DNS pointer to cp.econsular[.]ir, and the second IP’s netname is “Foreign Ministry of Iran.” This suggests that both are affiliated with the Iranian government.

That said, further analysis of these IPs revealed associations with two X.509 certificates. The earliest certificate appears to be related to pfSense and was only associated with these IPs for a single day in August 2019. This leads us to believe that the two pfs1010.* domains are made to resemble pfSense firewalls. The use of the domain name mfaantivirus[.]xyz loosely fits the security theme as well.

The second certificate associated with the IPs in Table 3 is a self-signed certificate with a common name of www.netgate[.]com. Netgate is the doing business as (DBA) name for Rubicon Communications, who developed pfSense – again sticking with the pfSense theme. Below is the information associated with that certificate.

Netgate X.509 Certificate
SHA-1 1cf1985aec3dd1f7040d8e9913d9286a52243aca
Issued 2022-04-21
Expires 2032-04-18
Common Name www.netgate[.]com
Organization Name netgate
SSL Version 1
Locality New York
State/Province New York
Country United States

Table 4. Second suspected Playful Taurus certificate.

There are five additional malicious IPs associated with this certificate, but the two we wish to highlight are the following.

X509 Certificate Two - IP Associations
IP Owner
151.248.24[.]251 NYNEX satellite OHG

Previous Cert: portal-Share.mfa[.]new
158.247.222[.]6 Constant Company VPS

Table 5. X509 certificate two – IP associations.

The first IP contains a historical certificate reference to portal-Share.mfa[.]new, which suggests an ambiguous “Ministry of Foreign Affairs (MFA)” nexus. The second is a virtual private server (VPS) owned by The Constant Company. This second IP (158.247.222[.]6) hosted the domain www[.]delldrivers[.]in from July 7, 2022 to Oct. 11, 2022. This domain is associated with a Turian backdoor sample.

Tying this all together, we identified Iranian government infrastructure establishing connections with a known Playful Taurus command and control (C2) server. Pivoting on one of the Iranian government IPs, we then identified additional infrastructure hosting certificates that overlap with a second Playful Taurus C2 server.

Turian Backdoor

Analyzing the domain *.delldrivers[.]in resulted in the identification of the following sample of malware.

File Details
Filename dellux[.]exe
Creation Time 2022-06-27 01:25:26 UTC
SHA256 67c911510e257b341be77bc2a88cedc99ace2af852f7825d9710016619875e80
Connections update.delldrivers[.]in

Table 6. File details for Turian sample.

This sample was uploaded to VirusTotal from submitters in Iran on Nov. 12 and 13, 2022. We further observed that these same submitters uploaded files and URLs that suggest a likely affiliation with Iran’s Ministry of Foreign Affairs.

Technical Analysis

We found that this sample is packed with VMProtect. However, the final payload is not virtualized and is ultimately unpacked into the .text, .data and .rdata sections of the payload. Unfortunately, VMProtect obfuscates all API calls within the sample. So whenever an API call is made, execution jumps to the .vmp0 section to resolve the import and execute it.

While the functionality of the sample becomes increasingly difficult to analyze due to the API obfuscation, the strings within the unpacked .data section provide a useful pivot point for identifying additional samples that contain the same functionality but are not packed with VMProtect.

Alongside the strings, the sample also contains a fairly unique XOR decryption function (shown in Figure 1). This is used to decrypt the embedded C2 server, update.delldrivers[.]in.

Image 1 is a screenshot of many lines of code showing the XOR unique decryption algorithm.
Figure 1. Fairly unique decryption algorithm.

A similar algorithm has been seen within the Neshta file infector, back in 2014. Data encrypted with this algorithm can be decrypted with the Python snippet shown in Figure 2.

Image 2 is a screenshot of many lines of Python code that could be used to decrypt an algorithm associated with the Neshta file infector.
Figure 2. Python data decryptor.

Pivoting on the algorithm’s byte pattern {69 D2 05 84 08 08 8A 1C 30 42 32 DA 88 1C 30} allows us to identify two additional malware samples.

File Details
Filename scm[.]exe
Type EXE
Creation Time 2022-04-28 02:56:26 UTC
SHA256 8549c5bafbfad6c7127f9954d0e954f9550d9730ec2e06d6918c050bf3cb19c3
Connections scm.oracleapps[.]org

Table 7. File details of the first sample located via pivoting on algorithm byte pattern.

File Details
Type DLL
Creation Time 2022-06-18 14:43:13 UTC
SHA256 ad22f4731ab228a8b63510a3ab6c1de5760182a7fe9ff98a8e9919b0cf100c58
Connections update.adboeonline[.]net

Table 8. File details of the second sample located via pivoting on algorithm byte pattern.

The Turian Link

Aside from the C2 infrastructure being very similar in naming convention, comparing the code bases of these samples to the unpacked VMProtect sample indicates clear overlap between the functionality.

Due to the almost identical code base, we opted to focus our analysis on the executable, rather than the DLL. Before doing so, we had a look at the DLL and noticed several cleartext strings.

Image 3 is is a screenshot of cleartext strings in the DLL.

Searching for samples with similar strings, we identified two additional samples.

File Details
Type DLL
Creation Time 2022-04-28 02:56:26 UTC
SHA256 5bb99755924ccb6882fc0bdedb07a482313daeaaa449272dc291566cd1208ed5
Connections 127.0.0.1

Table 9. File details of the first sample located via pivoting on registry strings.

File Details
Type x64 DLL
Creation Time 2022-06-18 14:43:13 UTC
SHA256 6828b5ec8111e69a0174ec14a2563df151559c3e9247ef55aeaaf8c11ef88bfa
Connections mail.indiarailways[.]net

Table 10. File details of the second sample located via pivoting on registry strings.

These samples have been tagged in VirusTotal as being APT_MAL_LNX_Turian_Jun21_1, which is a Linux version of the Turian backdoor. However, these samples are clearly not for Linux systems. This tag did point us toward previous reporting on the Turian/Quarian backdoors, which established a link between our dellux.exe sample and Turian.

An Updated Variant

Key differences between our samples and the previously documented Turian samples indicated that we were likely looking at a newer version, with some additional obfuscation and a modified network protocol.

The first key difference was the C2 decryption algorithm. In prior Turian samples, the C2s were decrypted with an XOR against a hard coded byte, such as 0xA9.

Image 4 is a screenshot of 5 lines of code showing hardcoded byte 0xA9.

Whereas in the dellux.exe sample, the algorithm has clearly been updated.

Additionally, the network protocol in use by Turian and Quarian backdoors has historically been very distinct, especially during the initial key exchange. In this variant, the network protocol has been altered to instead make use of the Security Support Provider Interface (SSPI).

On startup, Turian will retrieve a pointer to the SSPI Dispatch Table via a call to InitSecurityInterfaceA(), before calling AcquireCredentialsHandleA(). A socket is then opened to the remote C2, using standard Winsock API, with connect() being called to establish a connection.

Once a connection has been made, Turian then performs an SSL handshake with the C2. This is done through a call to InitializeSecurityContextA(), which will return a token to send to the C2 server.

Once sent, Turian waits for a 5 byte response (the SSL/TLS record header). This response contains the length of data also to be received from the C2 server, after the initial header. The remaining data is then passed into another call to InitializeSecurityContextA(), before returning. At this point, the handshake has been successful and secure communications can begin.

All packets sent to the C2 server are encrypted using the EncryptMessage() API, but are also XORed with the key 0x56 beforehand. The same functionality is performed on received packets, with the data being decrypted with DecryptMessage(), followed by XORing with 0x56.

The updated backdoor offers fairly generic functionality, from updating the C2 to communicate with, to executing commands and spawning reverse shells. The main differences with this compared to other variants of Turian are the command IDs. Whereas before, the IDs started at 0x01 and followed an order, the IDs in this variant appear to be randomized.

Commands Table
0xBC5B Clean up
0xA8CB Update C2
0x9D58 Execute Command
0x9A3C Spawn File Explorer Thread
0x7C0D (Unknown)
0x6394 Set Flag
0x74D2 (Unknown)
0x53A6 Get System Info
0x26CD Spawn Reverse Shell Thread

Table 11. Updated Turian commands.

Conclusion

Playful Taurus continues to evolve their tactics and their tooling. Recent upgrades to the Turian backdoor and new C2 infrastructure suggest that these actors continue to see success during their cyber espionage campaigns. Our analysis of the samples and connections to the malicious infrastructure suggest that Iranian government networks have likely been compromised. At the same time, we would also caution that Playful Taurus routinely deploys the same tactics and techniques against other government and diplomatic entities across North and South America, Africa and the Middle East.

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Protections and Mitigations

For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:

  • WildFire cloud-based threat analysis service accurately identifies the Turian malware described in this blog as malicious.
  • Advanced URL Filtering and DNS Security identify domains associated with Playful Taurus as malicious.
  • Cortex XDR prevents the execution of known malware samples as malicious. It also prevents the execution of Turian malware using Behavioral Threat Protection and the new in-memory shellcode protection released in Cortex 3.5.

If you think you may have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

Infrastructure

152.32.181[.]16
158.247.222[.]6
vpnkerio[.]com
update.delldrivers[.]in
scm.oracleapps[.]org
update.adboeonline[.]net
mail.indiarailways[.]net

Playful Taurus Certificate SHA-1

cfd9884511f2b5171c00570da837c31094e2ec72
1cf1985aec3dd1f7040d8e9913d9286a52243aca

Turian Sample SHA-256

67c911510e257b341be77bc2a88cedc99ace2af852f7825d9710016619875e80
8549c5bafbfad6c7127f9954d0e954f9550d9730ec2e06d6918c050bf3cb19c3
5bb99755924ccb6882fc0bdedb07a482313daeaaa449272dc291566cd1208ed5
ad22f4731ab228a8b63510a3ab6c1de5760182a7fe9ff98a8e9919b0cf100c58
6828b5ec8111e69a0174ec14a2563df151559c3e9247ef55aeaaf8c11ef88bfa

Additional Resources

Network Security Trends: August-October 2022

Posted on by Samantha Stallings

Executive Summary

Recent August-October 2022 observations of exploits used in the wild reveal that threat actors have been leveraging significant numbers of attacks against the Realtek Jungle SDK remote code execution vulnerability (CVE-2021-35394).

In our observations of network security trends, Unit 42 researchers have pinpointed several attacks based on proof-of-concept (PoC) availability and impact. We have detailed below which of these we believe should be on a defender’s radar.

Other insights that could assist defenders include the following:

  • Rankings of the most commonly used attack techniques and the types of vulnerabilities that attackers have recently favored. For example, among 5,190 newly published vulnerabilities, a large portion (almost 9.8%) involves cross-site scripting.
  • Lists of major vulnerabilities identified by evaluating more than 232 million attack sessions including remote code execution.
  • Insight into how these vulnerabilities are exploited in the wild based on real-world data collected from our Next-Generation Firewalls.
  • Summaries of key trends from August-October 2022.
  • Analysis of the most recently published vulnerabilities, including the severity and attack origin distribution.
  • Classification of these vulnerabilities to provide a clear view of the prevalence of the different types, such as cross-site scripting or SQL injection.
  • Lists of the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.

Palo Alto Networks customers receive protections from the vulnerabilities discussed here through the Next-Generation Firewall and associated Cloud-Delivered Security Services including Threat Prevention, WildFire and Advanced URL Filtering. Protections are also available from Prisma Cloud’s Web Application and API Security (WAAS) and Cortex XDR.

Types of Attacks and Vulnerabilities Covered Cross-site scripting, denial of service, information disclosure, buffer overflow, privilege escalation, memory corruption, code execution, SQL injection, out-of-bounds read, traversal, command injection, improper authentication, arbitrary file download, security feature bypass
Related Unit 42 Topics Network Security Trends, exploits in the wild, attack analysis

Analysis of Published Vulnerabilities, August-October 2022

From August-October 2022, a total of 5,190 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact these newly published vulnerabilities could have on network security, we provide our observations based on the severity, availability of working proof-of-concept (PoC) code, and vulnerability categories.

How Severe Are the Latest Vulnerabilities?

To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable PoCs available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the 5,190 CVEs that have an assigned severity score of medium or higher can be seen in the following table:

Severity Count Ratio Ratio Change From Last Quarter % PoC Availability Change in PoC Availability
Critical 980 18.9% -0.1% 2.9% -2.6%
High 2184 42.1% +2.0% 2.2% -1.6%
Medium 2026 39.0% -1.9% 2.3% -1.1%

Table 1. Severity distribution for CVEs registered August-October 2022, including only those rated medium to critical.

Image 1 is a pie chart measuring the distribution of critical, high, and medium CVEs registered through August and September of 2022. The largest percent is “high” at 42.1%.
Figure 1. Severity distribution for CVEs registered August-October 2022, including only those rated medium to critical.

Our classification of vulnerability levels is based on CVSS v3 scores. Many conditions must be met to rate a vulnerability as critical, so there are very few at this level. One of the common factors for rating a vulnerability at this level is whether it has a working PoC available. To be considered critical, vulnerabilities generally have low attack complexity, and it is often easy to create a PoC to exploit them.

In the period we discuss here, PoC ratios decreased slightly for all severity levels.

Vulnerability Category Distribution

It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 26.6% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 73.4% are remote vulnerabilities, which can be exploited over a network. This means that most newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.

In Figure 2, the most common vulnerability types are ranked by how prevalent they were among the most recent set of published vulnerabilities.

Image 2 is a stacked bar chart showing the vulnerability category distribution for CVEs registered through August and September of 2022. Medium has the largest portion in yellow for cross-site scripting.
Figure 2. Vulnerability category distribution for CVEs registered August-October 2022.

Cross-site scripting remains the most reported vulnerability during August-October 2022. We also saw that the prevalence of buffer overflow vulnerabilities increased during this time. The number of new vulnerabilities of other types, such as cross-site scripting and denial-of-service, has decreased. Most of the recently published cross-site scripting and information disclosure vulnerabilities are usually at medium or high severity (rather than critical).

Image 3 is a column chart showing the vulnerability category distribution for CVEs registered through August and September of 2022. Medium has the largest portion in yellow for cross-site scripting. It compares the previous quarter to August and September.
Figure 3. Vulnerability category distribution compared with the previous quarter.

Network Security Trends: Analysis of Exploits in the Wild, August-October 2022

Data Collection

By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from August-October 2022. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 232 million valid malicious sessions and then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.

How Severe Were the Attacks Exploited in the Wild?

To arrive at 232 million valid malicious sessions, we excluded the original set of low-severity signature triggers used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a medium and higher severity ranking (based on the CVSS v3 Score) as a verified attack.

Image 4 is a pie chart measuring attack severity distribution of critical, high, and medium CVEs registered through August and September of 2022. The largest percent is “critical” at 58.6%.
Figure 4. Attack severity distribution, August-October 2022, including only medium-critical vulnerabilities.

Figure 4 shows the ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters' severity distribution, this quarter shows an increase in critical attacks. We further analyzed the data and found that the attacks against the Realtek Jungle SDK remote code execution vulnerability (CVE-2021-35394) accounted for 71.4% of all critical attacks, accounting for 41.8% of the total number of attacks.

Image 5 is a column chart showing the vulnerability severity distribution for CVEs registered through August and September of 2022 compared to the previous quarter, showing a decrease in medium and high and a rise in critical.
Figure 5. Vulnerability severity distribution compared with the previous quarter.
Image 6 is a graphic comparing the numbers of the total number of critical-severity attacks with the proportion of those attacking CVE-2021-35394.
Figure 6. Proportion of attacking CVE-2021-35394. Numbers are rounded to the nearest million.

When Did the Network Attacks Occur?

Image 7 is a bar chart detailing the severity of exploits in the wild measured weekly from August to October of 2022. There is a spike in critical attacks towards the end of the year.
Figure 7. Severity of exploits in the wild measured weekly from August-October 2022.

During August-October 2022, there has been a spike in critical attacks over several weeks, most likely related to the increase in attacks referenced in the previous section, and a slight increase in attacks exploiting medium-severity vulnerabilities in September. There were no significant fluctuations in the number of attacks of other severities at other times.

As we’ve seen in the past, attackers frequently use recently disclosed vulnerabilities, especially those from 2021-2022. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities. Due to the extremely large number of attacks exploiting the Realtek Jungle SDK remote code execution vulnerability (CVE-2021-35394), the distribution of CVE numbers in attacks in the wild this quarter has been dramatically different from that of previous quarters.

Image 8 is a bar chart showing by month and week the observed attacks in which the exploited CVE was disclosed. Included CVEs are CVEs from 2021 to 2022, yellow, 2019 to 2020, purple, 2016 to 2018, blue, 2010 to 2015, dashed green and before 2010, orange.
Figure 8. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from August-October 2022.

Attack Category Distribution

We classified each network attack by category and organized them in terms of prevalence. In the period discussed, remote code execution ranks first, followed by traversal.

Figure 19 is a stacked bar chart showing the attack category and severity of critical, high, and medium CVEs from August to October 2022. Remote code execution far outranks any other at 155 million.
Figure 9. Attack category and severity, August-October 2022.

Compared with the previous quarter, due to the aforementioned Realtek Jungle SDK remote code execution vulnerability being greatly exploited, this quarter's remote code execution increased sharply. In addition, traversal rose almost double compared to the previous quarter, and information disclosure fell by almost a third of the previous quarter.

Where Did the Attacks Originate?

After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by Vietnam then Russia. Attacks from Vietnam increased significantly this quarter. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.

Figure 20 is a chart showing the percentage by country of attack origins from August to October. The highest is the United States at just over half, following by “Other” at 12.4% and Vietnam at 8.8%.
Figure 10. Locations ranked in terms of how frequently they were the origin of observed attacks from August-October 2022.
Figure 21 is a column chart showing the CVE attack origin distribution compared to the previous quarter, where the United States has taken a dip and Vietnam and Russia have risen.
Figure 11. Attack originate distribution compared to the previous quarter.
Figure 22 is a heat map of the attack geolocation distraction from August to October of 2022. The darkest area of the map is the United States.
Figure 12. Attack geolocation distribution from August-October 2022.

Conclusion

The vulnerabilities disclosed from August-October 2022 indicate that web applications remain popular targets for attackers, and that critical vulnerabilities are more likely to have PoCs publicly available.

In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. Attackers continue to make a concerted effort to expand their tool kit of exploits whenever possible.

While cybercriminals will never cease their malicious activities, Palo Alto Networks customers receive protections from the attacks discussed in this blog through the Next-Generation Firewall and Cloud-Delivered Security Services, including Threat Prevention, WildFire and Advanced URL Filtering, as well as through Cortex XDR.

To further mitigate any risks to your network:

  • Run a Next-Generation Firewall to identify where your configuration could be altered to improve your security posture.
  • Run a Security Lifecycle Review to get a consolidated view of your largest threats and if you have coverage to prevent them.
  • Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g., versions 8649 and above).
  • Prisma Cloud customers using WAAS receive protection from these threats through the App Firewall feature, which detects attacks such as cross-site scripting, SQL injection, directory traversals and more.

Additional Resources

 

Security Issue in JWT Secret Poisoning (Updated)

Posted on by Samantha Stallings

Updates

Jan. 30, 2023

After hearing the community's feedback about the prerequisites of the exploitation scenario of the vulnerability, we made the decision to work with Auth0 to retract CVE-2022-23529. 

The security issue described in this blog remains a concern when the JsonWebToken library is used in an insecure way. In that scenario, if all the prerequisites are met, the issue may be exploitable. We agree that the source of this risk in that case will be in the calling code, and not in the library.

Important security checks were added to the JsonWebToken code to address this issue. 

Users of jsonwebtoken 8.5.1 and earlier are encouraged to update to the latest version, 9.0.0, which presents safer code that fixes this security flaw and others, and prevents misuse of the package that was presented in this blog. 

We want to thank Auth0 for their work to address the security issue, as well as the security community for the interest and feedback. We would also like to thank GitHub for their help. The update can be read on the Auth0 GitHub.

Jan. 12, 2023

After receiving feedback from the community, we decided to make some clarifications regarding possible exploitation. We originally mentioned that an attacker needs to have control over the secret manager and decided that there was a practical need to make this even more clear in our language and associated figures.

Executive Summary

Unit 42 researchers discovered a new vulnerability in the popular JsonWebToken open source project. The vulnerability is identified as CVE-2022-23529, rated high severity (CVSS 7.6).

By exploiting this vulnerability, attackers could achieve remote code execution (RCE) on a server verifying a maliciously crafted JSON web token (JWT) request. This vulnerability requires several prerequisites in order to be exploitable, which makes it less likely for an attacker to use it in the wild.

If you are using JsonWebToken 8.5.1 or an earlier version, we suggest updating to JsonWebToken version 9.0.0, which includes a fix for this vulnerability.

JsonWebToken is an open source JavaScript package that allows you to verify/sign JWTs, which are mainly used for authorization and authentication purposes. Developed and maintained by Auth0, the package had over 9 million weekly downloads at the time of writing, and over 20,000 dependents (according to the JsonWebToken page). This package plays a big role in the authentication and authorization functionality for many applications.

Palo Alto Networks customers can identify assets that are running vulnerable versions of the JsonWebToken package with Prisma Cloud, and they can identify the relevant CVE within scan results.

Related Unit 42 Topics  CVE-2022-23529, remote code execution, open source, cloud

JWT 101

JWT (pronounced “jot”) is an open standard that defines a method of transferring information securely by encoding and signing JSON data. JWTs have a string structure that consists of 3 parts separated by a dot (.):

Header.Payload.Signature

JWTs are used to transmit different types of information, but are mainly used to deliver “claims,” which are pieces of information about some subject. In practice, this will most likely contain useful information about a user.

The most common use case of JWTs is for authorization and authentication. Let’s quickly go over the JWT structure.

JWT Header

As shown in Figure 1, the header consists mostly of two parameters that indicate the type of the token and the signing algorithm.

Image 1 is a screenshot of two lines of code enclosed in curly brackets. The first line is “alg: HS256” and the second line is “top” JWT.”
Figure 1. JWT header.

JWT Payload

The payload (shown in Figure 2) is the second part of the token, which will contain the claims. In most cases, this will provide useful information about a user.

Image 2 is a screenshot of two lines of code enclosed in curly brackets. The first line is “user_name: John Doe” and the second line is “admin: true.”
Figure 2. JWT payload.

There are three different types of claims: registered, public and private. You can find more information about them in RFC 7519.

The header and payload are each Base64Url encoded to form the first and second parts of a JWT string (Header.Payload.Signature):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 and eyJ1c2VyX25hbWUiOiJKb2huIERvZSIsImFkbWluIjp0cnVlfQ.

The third part of the JWT, the signature, is then computed (signed) by the following formula using a secret key. A signature is used to verify that the token isn’t forged or manipulated. Because it is signed with a secret key, we can validate the authenticity of the sender. Here is an example of a signature calculation: 

base64Url(HMACSHA256(base64Url(header) + ”.” + base64Url(payload), secret_key)) = epQym-1JoN9eep458VBZw4-cVhwfmsI1cfaGa6PE818

Putting it all together, we will get a JWT in its complete form, as shown in Figure 3.

Image 3 is a screenshot of a JSON web token string with the different parts, header, payload and signature red, green and cyan respectively.
Figure 3. Full JSON web token.

How Does the Authentication Process Work?

Let’s take a look at a simple authentication process using a JSON web token (also shown in Figure 4):

  1. To access a protected resource, the user will log in using credentials, usually username and password.
  2. A request containing this information will be sent to the authentication server.
  3. An authentication server will validate the information sent within a request and issue a JWT signed with a secret key, which can be stored on a server or in a different location using a secret manager.
  4. From now on, each user request will contain a JWT in the authorization header. This way, users with the right permissions can receive access to protected resources.
  5. When a user requests access to a protected resource, a request containing a JWT will be generated from the application to the JWT authentication server.
  6. Before the user receives access to a requested resource, the JWT that was sent in the authorization header will be verified using the secret key. This is done to verify it was not tampered along the way and that the user has the right permissions to view the requested information. In the node.js JsonWebToken package, this is done with the verify() function.
Image 4 is a diagram showing the process of JWT authentication, starting with the user and their credentials. The process follows from the server issuing the JWT to the authentication server.
Figure 4. Diagram of the process of authentication with JWT.

JWT and Open Source

Open source projects help a lot of organizations to save time and other resources. At times, this can serve as an elegant and quick problem solver. JWT became a very popular technology that many organizations rely on, and this is one of the reasons that some of the open source projects implementing JWT have become a great success.

One such project is a well-known JavaScript solution for signing, verifying and decoding JWTs named JsonWebToken. This tool is developed and maintained by Auth0, part of Okta.

The Vulnerability (CVE-2022-23529)

Typically, attacks on JWT will involve different forgery techniques abusing buggy JWT implementations. These kinds of attacks have severe consequences because, in most cases, a successful attack allows an attacker to bypass authentication and authorization mechanisms to access confidential information or steal and/or modify data.

One of the methods provided by the JsonWebToken package is verify. The verify method receives three parameters: token, secretOrPublicKey and options. This function verifies the validity of the JWT and returns the decoded payload part.

According to the documentation, secretOrPublicKey is a string or buffer. We can see the lines of code shown in Figure 5 in the JsonWebToken verify.js source code.

Image 5 is a screenshot of 4 lines of code taken from verify.js showing the secretOrPublicKey.
Figure 5. Code snippet from verify.js.

When no allowed algorithms are provided within the options algorithms list, the values within the privacy enhanced mail (PEM) file, which is provided by the secretOrPublicKey parameter, will be assigned instead. This presents a problem: There is no check in place that secretOrPublicKey is actually a valid PEM file’s content, and this unverified object’s toString method is blindly being used. Attackers with control over this object can supply their own toString method, which will then be executed by JsonWebToken’s verify in line 114.

Let's observe the following scenario, using node.js (a JavaScript runtime environment) version 18.9.1 and JsonWebToken package version 8.5.1, and see what will happen if we pass a malicious object to the verify function via the secretOrPublicKey parameter and override its toString() method.

Image 6 is a screenshot of many lines of code where the researchers use JsonWebToken to execute a verify function with a malicious object.
Figure 6. Arbitrary Write File PoC.

Our malicious code will execute and exit the node process before the .includes(‘BEGIN CERTIFICATE’)check in the verify function, resulting in an arbitrary write file on the hosting machine.

Image 7 is a screenshot of the title bar and contents of an arbitrary write file. The file name is “malicious.text” and the text is “PWNED! ! ! ! Arbitrary File Write on the host machine.”
Figure 7. PoC result, file created.

With the same technique, it is possible to achieve RCE, but we will have to slightly modify our payload by using the child_process module (as shown in Figure 8).

Image 8 is a screenshot of 3 lines of code where the payload has been modified using the child_process module.
Figure 8. RCE PoC.

Secrets can be stored outside of the authenticating server – for example, they can be kept within a secret manager in a different location. An attacker that only had write access to the secret manager can now execute code on the authentication server. If there was a check in place that the malicious object was a valid secret, code execution was not possible.

Exploitation Prerequisites

In the previous section, we demonstrated how a poisoned secret key could lead to an RCE. In reality, keeping and maintaining secret keys usually involves secret managers, secret key rotations, encryption and other best practices. 

In order to exploit the vulnerability described in this post and control the secretOrPublicKey value, an attacker will need to have control or exploit a flaw within the secret management process. Even then, exploitation might be complicated as the output of a secret manager is uncertain. It can be of a type not suited for an exploitation (a string, for example) or many other possible scenarios. 

Due to the complexity of exploitation of this vulnerability, we initially suggested a CVSS score of 6.6. However, we decided to accept the CVSS calculation made by the vendor, which yielded a higher severity of 7.6.

JsonWebToken Fix

JsonWebToken version 9.0.0 contains the following fix:

Image 9 is a screenshot of multiple lines of code. It is the JsonWebToken patch released with version 9.0.0 where checks for the type of secretOrPublickey are now in place.
Figure 9. Patch.

The vulnerable code was removed and replaced with checks for the type of secretOrPublickey parameter, which prevents secretOrPublicKey from containing malicious objects.

Disclosure Process

  • July 13, 2022 – Unit 42 researchers sent a disclosure to the Auth0 team under responsible disclosure procedures
  • July 27, 2022 – Auth0 team updated that the issue was under review
  • Aug. 23, 2022 – Unit 42 researchers sent an update request
  • Aug. 24, 2022 – Auth0 team updated that the engineering team was working on the resolution
  • Dec. 21, 2022 – A patch was provided by the Auth0 engineering team

Conclusion

Open source projects are commonly used as the backbone of many services and platforms today. This is also true for the implementation of sensitive security mechanisms such as JWT, which play a huge role in authentication and authorization processes.

Security awareness is crucial when using open source software. Reviewing commonly used security open source implementations is necessary for maintaining their dependability, and it's something the open source community can take part in.

As part of the commitment of Palo Alto Networks to open source software security, we regularly conduct security research efforts that include identifying security vulnerabilities in open source projects.

Palo Alto Networks Prisma Cloud customers can detect affected images and hosts under the Vulnerabilities tab. The platform detects JsonWebToken packages and alerts on entities running with a vulnerable version. In addition, our users can search for CVE-2022-23529 in the Vulnerability Explorer section to discover more details about the vulnerability and assets affected by it.

We would like to thank the Auth0 team for professionally handling the disclosure process and providing a patch for the reported vulnerability.

Updated January 12, 2023, at 3:31 p.m. PT.
Updated January 30, 2023, at 7:20 a.m. PT.

PurpleUrchin Bypasses CAPTCHA and Steals Cloud Platform Resources

Posted on by Nathaniel Quist

Executive Summary

Unit 42 researchers perform a deep dive into Automated Libra, the cloud threat actor group behind the freejacking campaign PurpleUrchin. Automated Libra is a South African-based freejacking group that primarily targets cloud platforms offering limited-time trials of cloud resources in order to perform their cryptomining operations.

Freejacking is the process of using free (or limited-time) cloud resources to perform cryptomining operations.

Key Points:

  • In order to take advantage of the limited resources offered by free trials, the actors heavily leveraged DevOps automation techniques such as continuous integration and continuous delivery (CI/CD). They accomplished this by containerizing user account creations on cloud platforms and through automating their cryptomining operations.
  • We collected more than 250 GB of container data created for the PurpleUrchin operation and discovered that the threat actors behind this campaign were creating three to five GitHub accounts every minute during the peak of their operations in November 2022.
  • We also found that some of the automated account creation cases bypassed CAPTCHA images using simple image analysis techniques. We also identified the creation of more than 130,000 user accounts created on various cloud platform services like Heroku, Togglebox and GitHub.
  • We found evidence of unpaid balances on some of these cloud service platforms from several of the created accounts. This finding suggests that the actors created fake accounts with stolen or fake credit cards.
  • With this finding, we assess that the actors behind PurpleUrchin operations stole cloud resources from several cloud service platforms through a tactic Unit 42 researchers call “Play and Run.” This tactic involves malicious actors using cloud resources and refusing to pay for those resources once the bill arrives.

Palo Alto Networks customers receive protection from the events listed within the blog through the Prisma Cloud container vulnerability scanning and runtime protection policies.

Related Unit 42 Topics Cryptomining, containers, DevOps, Prisma Cloud

A New Play and Run Tactic

The PurpleUrchin cryptomining campaign, first uncovered in October 2022, is characterized as a freejacking operation. While doing our own investigation of this threat actor, Unit 42 researchers found evidence that PurpleUrchin threat actors employed Play and Run tactics, using cloud resources and not paying the cloud platform vendor’s resource bill.

PurpleUrchin actors performed these Play and Run operations through the creation and use of fake accounts, with falsified or potentially stolen credit cards. These fake accounts held a pending unpaid balance. Although one of the largest unpaid balances we found was $190 USD, we suspect the unpaid balances in other fake accounts and cloud services used by the actors could have been much larger due to the scale and breadth of the mining operation.

Background

Unit 42 researchers analyzed more than 250 GB of data that included container data as well as system access logs by the actor (with geolocation information), and hundreds of indicators of compromise (IoCs). The IoCs collected during this research are published in the Unit 42 ATOM for Automated Libra.

The infrastructure architecture employed by the actors uses CI/CD techniques, in which each individual software component of an operation is placed within a container. This container operates within a modular architecture within the larger mining operation.

CI/CD architectures provide highly modular operational environments, allowing some components of an operation to fail, be updated, or even be terminated and replaced, without affecting the larger environment.

By analyzing the collected container data, we traced the actor’s activity back to August 2019. Their activity was spread across several cloud providers and crypto exchanges.

We also found that the actors have a preference for using cloud services via traditional virtual service providers (VSPs). Many traditional VSPs extend their service portfolio to include cloud-related services, such as Cloud Application Platform (CAP) and Application Hosting Platform (AHP). Some of the cloud service providers that offer CAP and AHP services that were targeted by the PurpleUrchin actors include Heroku and Togglebox, among others.

Unit 42 researchers identified more than 40 individual crypto wallets and seven different cryptocurrencies or tokens being used within the PurpleUrchin operation. We also identified that specific containerized components of the infrastructure the actors created were not only designed to perform mining functionality, but they also automated the process of trading the collected cryptocurrencies across several crypto trading platforms such as CRATEX ExchangeMarket, crex24 and Luno.

Mining With GitHub Workflows

The actor operations on GitHub used a combination of Play and Run and freejacking tactics. The likely reason the actors used GitHub is due to its decreased resistance in account creation. The actors were able to leverage a weakness within the CAPTCHA check on GitHub, which we discuss in more detail in the following section.

The actors automatically created GitHub accounts at an average rate of three to five accounts per minute. Once the actors had established their account base, they began their freejacking activity.

Each of the GitHub accounts was subsequently involved in a Play and Run strategy, where each account would use computational resources, but threat actors ultimately left their tabs unpaid. This appears to be a standard operational procedure for PurpleUrchin, as there is evidence that they created more than 130,000 accounts across various virtual private server (VPS) providers and cloud service providers (CSPs).

The actor also appeared to reserve a full server or cloud instances and they sometimes used CSP services such as AHPs. They did so in order to facilitate hosting web servers that were required to monitor and track their large-scale mining operations.

We have high confidence that some of the accounts created by this threat group were created using fake profiles and credit card information. This tactic allowed them to leave unpaid tabs with CSPs after their mining operations were completed.

Unit 42 researchers have found the actors behind PurpleUrchin appear to continuously evolve their operations such as refining their Play and Run and freejacking tactics.

Let’s look further into how the actors have refined the automation of account creations within GitHub.

Automating GitHub Account Creations

One of the threat actor’s latest deployments involved running Togglebox using AHP services. Togglebox is a fully managed solid-state drive (SSD) Cloud VPS and Application Hosting platform.

The actors used this platform to run a series of containers using the naming convention format repo_name/vgenerated_name:latest. Each container was capable of automatically creating GitHub accounts.

Researchers found a switch called “named” based accounts (meaning they were based on dictionary words) within the user account creation Python process, which was contained within the aforementioned container. This process uses randomly generated named accounts based on MD5 hashes.

The tools needed for the automatic account creation process were shipped as a container. In the latest version of the container, the actor combined several publicly available and legitimate tools to perform their operations, such as the following:

  • Iron Browser, a chromium-based web browser
  • xdotool, a tool used to generate keyboard and mouse inputs
  • ImageMagick tool kit, used to convert, edit and compose digital photos

Once the necessary tools were in place, threat actors could begin creating accounts. The first step to creating a GitHub account is to populate the email address, password and username fields (as shown in Figure 1).

Image 1 is a diagram showing the GitHub form completion process. There are two screenshots of code. The screenshot on the right shows the xdotool. The screenshot on the bottom is a code snippet showing the larger process.
Figure 1. GitHub form completion process.

The container ran a virtual network computing (VNC) server on display:1 where the Iron Browser was launched with the following command, as shown in Figure 2.

Image 2 is a screenshot of lines of code showing how the Iron Browser display is launched with a command on a VNC server.
Figure 2. Iron Browser display on VNC server.

Then using xdotool, the main script completed the GitHub form. After the form was completed, GitHub presented a CAPTCHA challenge as shown in Figure 3.

Image 3 is a screenshot of a CAPTCHA challenge on GitHub asking the user to select a spiral galaxy.
Figure 3. GitHub CAPTCHA challenge.

The actor implemented a very simple mechanism for solving this CAPTCHA. While we did not evaluate the effectiveness of this CAPTCHA solving process, in the following section, we will show statistics about how many GitHub accounts the actor was able to create in the span of three months. Based on this information, we think that this process (in combination with other tactics) was very effective.

Leveraging a CAPTCHA Weakness

To solve this particular CAPTCHA, which consists of identifying the spiral galaxies, the actor used two tools from the ImageMagick tools kit: convert and identify.

First, the images were converted into a red, green and blue (RGB) complemented image using the convert tool. Figure 4 shows an example of this conversion.

Image 4 is a screenshot of a CAPTCHA conversion where the threat actor converts the CAPTCHA image to an RGB complement to extract the skew of the red channel (the “R” in RGB).
Figure 4. Converting image to an RBG complement.

Once the images were converted, the identify command was executed over each image to extract the “skewness” feature of the Red channel, as shown in Figure 5.

Image 5 is a line of code showing how the skew command is extracting the red channel from the RBG image.
Figure 5. Command to extract the skewness feature of the Red channel.

The final result, shown in Figure 6, was arranged in order from largest to smallest, and the image with the smallest value was selected as the spiral image. For example, using the values for the previous images:

Image 6 shows the numerical outputs for the red channel.
Figure 6. Example of Red channel outputs for each image.

In this case, Image 2 (from Figure 4) is identified as the spiral galaxy. Once the CAPTCHA is solved, GitHub requires a “launch code,” as shown in Figure 7.

Image 7 is a screenshot of GitHub requesting a launch code with the text “You’re almost done! We sent a code to test@yah.com” with an arrow indicating where to enter the code.
Figure 7. GitHub requesting a launch code.

The actor used a Gmail account to automate the process of getting the launch code. They enabled this using Internet Message Access Protocol (IMAP) as well as a PHP script to read incoming IMAP messages.

Once the access code was entered, the automation generated a personal access token (PAT) with workflow permissions. The final result of the GitHub registering process was a username and PAT used for deploying workflows on GitHub. With the username and token, another container was invoked, as shown in Figure 8.

Image 8 is 2 lines of code that invoke a running container.
Figure 8. Invoking a running container.

This container subsequently performed the following actions:

  • Setting up SSH keys
  • Creating a GitHub repo using the GitHub API
  • Configuring the permissions for the created repo

As part of a naming convention change within more recent operations, the actor started to use random names for the repos, which were based on MD5 hashes. This followed the same convention as prior username creations. The command shown in Figure 9 demonstrates the naming convention process.

Image 9 is a screenshot of a line of code showing the random naming convention command.
Figure 9. Random naming convention command.

Once the repo was created within GitHub, a Bash script was invoked to update the repo with the desired workflow. The workflow was generated using a PHP script that worked as a template for randomizing the differently named attributes of the workflow configuration. Figure 10 provides an example of how the workflow PHP template was coded.

Image 10 is a screenshot of the PHP template for randomizing script attributes. It shows how the workflow was coded.
Figure 10. PHP template for randomizing script attributes.

In one version we observed, the workflow (generated from a template shown in Figure 10) had 64 jobs. The generated workflows were configured to run as a repository_dispatch under the event github.event.client_payload.app.

This workflow mechanism allowed the actors to execute external applications. In this case, the actor was running external Bash scripts and containers, as shown in Figure 11.

Image 11 is a screenshot of many lines of code showing the workflow mechanism used to execute external applications by the threat actor.
Figure 11. Workflow mechanism to execute external applications.

The workflow runs the Bash script that is accessed from an external domain. During the last design change we observed, the actor built and ran containers that were used to install and initiate the cryptomining functionalities, as shown in Figure 12.

Image 12 is a screenshot of many lines of code showing how the threat actor built and ran remote mining containers.
Figure 12. Remote establishment of mining containers.

The generated workflow ran 64 jobs, and each job randomly selected one out of five available, unique configurations.

We did not evaluate how effectively the complete design performed. However, as part of the research, we were able to retrieve many GitHub accounts the actor was able to create during a three month period of time.

The following chart in Figure 13 illustrates statistics about the GitHub-created accounts performed by the system. It’s important to note that we don’t know if all accounts were created with the same design mechanism for all GitHub accounts. However, the statistics show actual accounts created by the actor’s infrastructure.

This chart is an estimate of confirmed GitHub-created accounts. It is not meant to be fully comprehensive because of the limited visibility we had during the investigation.

Image 13 is a graph showing the number of GitHub accounts created by PurpleUrchin actors. There is a dramatic increase in November 2022, compared to September and October of the same year.
Figure 13. The number of GitHub accounts created by the PurpleUrchin actors.

Earlier Campaign, Pandemic Time

One of the preferred cloud services used by the actor during 2021 was Heroku. Heroku is a CAP that allows users to create and deploy applications without the need for maintaining the hosting cloud infrastructure. PurpleUrchin actors made use of this capability throughout their operations.

After analyzing the data within the collected containers, we identified a total of 100,723 unique accounts created on the Heroku platform. The chart in Figure 14 shows the Heroku account creation stats by year and month.

Image 14 is a graph measuring the amount of unique accounts created on Heroku CAP with the total number being 100,723. The graph measures from July to November of 2022.
Figure 14. Unique accounts created on the Heroku CAP.

As the above chart shows, this actor was active and using Heroku since at least November 2021.

We have a medium level of confidence that the operations started early in 2020, given that the actor created multiple certificates with the Let’s Encrypt service, which was used with the generated domains. One of the domains, linux84[.]distro[.]cloudns.cl, had an SSL certificate with a valid date starting on Nov. 17, 2020 (shown in Figure 15).

Image 15 is a screenshot of the SSL certificate for linux84.distro.cloudns.cl.
Figure 15. SSL certificate for linux84.distro.cloudns.cl.

Conclusion

Automated Libra, the cloud threat actor behind the freejacking campaign PurpleUrchin, has created more than 130,000 accounts on free or limited-use cloud platforms such as Heroku and GitHub. They have also engaged in the illegal theft of cloud resources from these platforms.

Automated Libra constantly improve their CI/CD operation and infrastructure architecture to perform the following actions:

  • Bypass or resolve the CAPTCHA presented by GitHub during account creation
  • Increase the number of accounts that can be created per minute
  • Utilize as much CPU time as possible before losing access to resources

It is important to note that Automated Libra designs their infrastructure to make the most use out of CD/CI tools. This is getting easier to achieve over time, as the traditional VSPs are diversifying their service portfolios to include cloud-related services. The availability of these cloud-related services makes it easier for threat actors, because they don’t have to maintain infrastructure to deploy their applications. In the majority of cases, all they’ll need to do is to deploy a container.

While PurpleUrchin is a freejacking crypto mining operation, Automated Libra also employs Play and Run tactics to gain access to computational resources. The threat actors use these limited-use cloud resources until the allotted time or dollar balance is reached, at which time Automated Libra ceases using those resources. This often results in an outstanding balance due, which actors do not pay.

Palo Alto Networks Prisma Cloud is capable of monitoring the usage of cloud resources, specifically those initiated within a containerized environment. Prisma Cloud’s ability to scan all containers for vulnerabilities and misuse prior to deployment, as well as monitoring the runtime status of these containers, would prevent the activities of Automated Libra from persisting within a cloud environment.

Updated January 5, 2023, at 10:05 a.m. PT.

Navigating the Vast Ocean of Sandbox Evasions

Posted on by Esmid Idrizovic

Executive Summary

When malware authors go to great lengths to avoid behaving maliciously if they detect they’re running in a sandbox, sometimes the best answer for security defenders is to write their own sandbox that can’t easily be detected. There are a lot of sandboxing approaches out there with pros and cons to each. We’ll talk about why we chose to go the bespoke route, and we’ll discuss many of the evasion types we had to cover in that effort as well as strategies that can be used to counter them.

There are many variations on how malware authors specifically detect sandboxes, but the general theme is that they will check the characteristics of the environment to see whether it looks like a targeted host rather than an automated system.

Palo Alto Networks customers receive improved detection for the evasions discussed in this blog through Advanced WildFire.

Related Unit 42 Topics Sandbox, WildFire, evasive malware 

How We Became Evasion Connoisseurs

You could say that our day to day in the world of malware analysis has made the WildFire malware team sandbox evasion connoisseurs. Our team’s Slack channel has had its share of “look at this one!” over the years, sharing the joy of finding new evasion techniques. Getting to the bottom of these has been a big part of our team mission to help improve detection.

There’s a vast number of techniques malware authors use to check if they are running on a “real” targeted host, such as counting the number of cookies in browser caches, or checking whether video memory appears too small. Given that sandbox evasions are legion and there are far too many to cover in a single article, we will first examine some of the major categories we typically encounter and then cover what we can do about them.

Checks for Instrumentation or “Hooks”

The first broad category of evasions involves the detection of any sandbox instrumentation. This is definitely one of the most popular techniques. The most common example is checking for API hooks, as this is a common method for sandboxes and antivirus vendors alike to instrument and log all of the API calls made by an executable under analysis. This can be as simple as checking the function prologues of common functions to see if they are hooked.

In Figure 1, we see what the disassembly looks like for the prologue of CreateFileA in Windows 10 as well as what it might look like if it’s been instrumented in a sandbox.

Image 1 demonstrates disassembly of CreateFileA’s prologue in Windows 10. There are three separate boxes. Box 1 on the left represents the normal CreateFileA prologue in kernel base.dll. Box 2 in the middle shows a hooked version of the same CreateFileA, and arrows going to and from this box to Box 3, which shows the Sandbox Hook Handler.
Figure 1. A typical sandbox hook on a function in the system API.

As you can see, this is pretty easy for attackers to detect, which is why it’s one of the most prevalent evasions we’ve seen out there.

A fun variation on this technique is when malware detects and unhooks existing hooks in order to stealthily execute without having its activity logged. This happens when malware authors want to slide past endpoint protections without being detected on a targeted host.

Figure 2 shows an example of how GuLoader unpatches the bytes of the ZwProtectVirtualMemory function prologue to restore the original functionality.

Image 2 is a screenshot of a before and after of GuLoader unhooking instrumentation in a system API function. It has unpatched the bytes of ZwProtectVirtualMemory function prologue.
Figure 2. GuLoader unhooking instrumentation in a system API function.

Mitigating Instrumentation Evasions

The gold standard for preventing malware authors from detecting instrumentation is simply not to have anything out of the ordinary that’s visible to the program you’re analyzing. A growing number of sandboxes are making this idea the focus of their detection strategy. It’s easier to be evasion resistant when you don’t change a single byte anywhere in the OS.

Instead of instrumenting APIs by changing code, it’s a better strategy to use virtualization to invisibly instrument programs under analysis. There are a lot of advantages to instrumenting malware from outside of the guest VM, as shown in Figure 3.

Image 3 shows two side-by-side diagrams. The left diagram shows a guest virtual machine’s program analysis components with the addition of the malware sample it executes. The diagram on the right shows the host operating system outside of the same virtual machine.
Figure 3. In-guest versus a hypervisor based hooking engine. Left: Program analysis components exist in the guest VM along with the malware sample it executes. Right: Analysis components exist entirely outside of the guest VM and are thus invisible to the program under analysis.

Detecting Virtual Environments

Another common evasion category involves detecting that a file is executing in a virtual machine (VM). This can involve fingerprinting resources like low CPU core count, system or video memory, or screen resolution. It can also involve fingerprinting artifacts of the specific VM.

When building a sandbox, vendors have a large number of VM solutions to choose from, such as KVM, VirtualBox and Xen. Each one has various artifacts and idiosyncrasies that are detectable by software running in VMs underneath them.

Some of these idiosyncrasies are particular to a specific system, like checking for the backdoor interface of VMware, or checking whether the hardware presented to the OS matches the virtual hardware provided by QEMU. Other approaches can simply detect hypervisors in general. For example, Mark Lim discussed a general evasion for hypervisors in an article, which capitalizes on the fact that many hypervisors incorrectly emulate the behavior of the trap flag.

One of the earliest and most widely used mechanisms for malware to determine whether it’s running inside a VMware virtual machine is to use the backdoor interface of VMware to see whether there is any valid response from the VMware hypervisor. An example of such a check is shown in Figure 4.

Image 4 is a screenshot of many line of code where malware checks if it’s running inside a VMware virtual machine to see if there will be a valid response.
Figure 4. Malware checking if it’s running inside a VMware virtual machine.

Malware families can also query the computer manufacturer or model information using Windows Management Instrumentation (WMI) queries. This allows them to get information about the system and compare it with known sandbox and/or hypervisors strings.

Figure 5 shows how this is used to query against VMware, Xen, VirtualBox and QEMU. The same technique can also be found in Al-Khaser, which is an open-source tool that contains many anti-sandbox techniques.

Image 5 is a screenshot of many lines of code where Windows Management Instrumentation queries are being used to gather system information.
Figure 5. WMI queries used for querying computer information.

Figure 6 shows the software components that malware can potentially interact with, to reveal whether it’s executing in a virtual environment.

Image 6 is a diagram where the malware.exe is interacting with additional surfaces, both inside the guest virtual machine and the host operating system. These include the paravirtualization device driver, virtual machine backdoor interface, the virtual hardware stack, and the virtual machine monitor.
Figure 6. Additional surfaces that processes can interact with to assess whether they’re inside a VM.

Additionally, there is also often a great deal of information sprinkled around the guest VM that can easily provide clues as to what VM platform the guest OS is running underneath. In all cases, the specifics are dependent on the VM infrastructure used (e.g., VMware, KVM or QEMU).

The following are just a few examples of what malware authors can check for:

  • Registry key paths showing VM-specific hardware, drivers or services.
  • Filesystem paths for VM-specific drivers or other services.
  • MAC addresses specific to some VM infrastructures.
  • Virtual hardware (e.g., if a query reports that your network card is an Intel e1000, which hasn’t been made in many years, it can infer that you’re probably running with the Qemu hardware model).
  • Running processes showing VM platform-specific services to support paravirtualization, or systems for user convenience like VMware tools.
  • CPUID instruction that will, in many cases, helpfully inform software of the guest of the VM platform.

Mitigating VM Evasions

The main issue with most of these mitigations is that the mainstream virtualization platform alternatives are well known to malware authors. For ease of implementation, most sandboxes are based on systems like KVM, Xen or QEMU, which makes this class of evasions particularly tricky to defeat.

Every mainstream VM platform out there has been targeted by sandbox evasions. The problem is that nothing short of writing your own custom hypervisor to support malware analysis would effectively address this class of evasions.

… So that’s what we did!

Our detection team made the decision years ago to implement our own custom hypervisor tailored specifically for malware analysis. The dev teams went to great lengths to build (from scratch!) our own virtualization platform for dynamic analysis.

This decision has two advantages. The first is that we are not susceptible to the same fingerprinting techniques that are used against other VM infrastructure. We do not have any backdoor interfaces, but we do have different virtual hardware and a completely different codebase.

The second advantage is that, because we have built our own system, it is easier for us to adapt and address issues wherever we see malware using trickery on us for evasion purposes. For example, the linked article mentioned earlier discussed how many hypervisors incorrectly emulated the trap flag for guest VMs. Our malware analysts were able to close the loop with our dev teams to ensure that we emulated correctly and were not susceptible.

Lack of Human Interaction

This category includes evasions requiring specific human interaction. For example, a malware author would expect to see mouse clicks or some other event that would happen on a system with a “real” user driving it, but this would be absent in a typical automated analysis platform. Malware families often check for human interaction and cease execution if it looks like there is no user driving the system, because user activity is being simulated.

The following are the general themes we’ve observed for human interaction checks:

  • Prompting users for interaction. For example, dialogue boxes or fake EULAs that a sandbox might not know should be clicked to ensure detonation.
  • Checking for mouse clicks, mouse movement and key presses. Even the locations of mouse events or timing of keystrokes can be analyzed to determine whether they look “natural” versus programmatically generated.
  • Placing macros in documents to check for evidence of human interaction like scrolling, clicking a cell in a spreadsheet or checking a different worksheet tab.

Let’s take a look at a specific example (shown in Figure 7) of how malware might get the time elapsed since last user input (GetLastUserInput) and the time elapsed since the system has started (GetTickCount). It can then compare how much time has passed since the last key was pressed, to detect if there is any activity on the system.

Image 7 is a screenshot of a dissembler demonstrating how malware may obtain time elapsed for both system start and since last user input.
Figure 7. User interaction required to detonate.

Mitigating Human Interaction Evasions

When implementing a sandbox, we have control of the virtual keyboard, mouse and monitor. If for some reason the analyzed executable requires any input keys, we can send key presses to the analysis, or make sure to click the correct button to continue the execution of the executable. It’s really just a question of knowing how to automatically do what a human would do to put on a convincing show for the malware we’re executing.

Like with all the other areas of the VM detection problem, we need to remain vigilant to what malware families are looking for, and continually improve our evasion strategy. A recent example involved malware that required individual mouse clicks on multiple cells within an Excel spreadsheet. We had to go the extra mile to ensure that we had a solid recipe for detection in place, in case this was used against us in the future.

Timing and Computing Resource Evasions

Early on, one of the most common sandbox evasions was to just call sleep for about an hour before doing anything evil. By doing this, it would guarantee that the malware would be well beyond the short analysis time window used by almost all sandboxes, as it’s not feasible to run every sample for more than a few minutes.

The reaction to this by sandbox authors was to instrument sleep to shorten any long sleeps to small ones. After many more iterations of this cat-and-mouse game, we now have a staggeringly diverse set of ever-evolving ways for malware to waste time in sandboxes and thus prevent any meaningful analysis results.

Figure 8 shows one evasion technique using Windows timers and Windows messages. The idea is to install a timer that will be fired each second, which then increments an internal variable when it’s executing the timer’s callback.

Once the variable hits a specific threshold, it will send another Windows message to notify the sample to start the execution of the malware. The problem with this evasion is that sandboxes can’t simply reduce the timer's timeout to a low number because it might break execution for other software, but it still must be executed somehow.

Image 8 is a screenshot of many lines of code demonstrating an evasion technique that uses Windows timers and messages to installs a timer.
Figure 8. Example of sleep using timers and Windows messages.

Another example is shown in Figure 9, below, where the malicious executables simply call the time stamp counter instruction in a loop.

Image 9 is a screenshot of lines of code showing a sleep loop. The malware executables call a time stamp counter instruction in a loop.
Figure 9. Sleep loop using time stamp counter instruction.

Timing Evasion Mitigations

Timing evasions can be very difficult to counter, depending on the situation. As previously mentioned, we can always adjust sleep arguments and timers but this does not completely solve the problem.

Another strategy that we’ve found useful is that, because we control the hypervisor, we can use techniques to control all hardware and software to make time move faster inside the guest VM. It’s even possible to do this without having to change arguments or install any hooks. We can run executables for an hour within minutes in real time, which allows us to reach the malicious code faster.

Junk instruction loops or VM exit loops are probably the hardest scenario to counter. If a malware author executes a few million CPUID instructions, which take exponentially longer to perform underneath a hypervisor, it’s a dead giveaway that our code is running in a VM. This is another situation where having a custom hypervisor tailored for malware analysis is useful, because we can detect and log this kind of activity.

Pocket Litter Checks

The term “pocket litter” has been co-opted from the field of espionage, where the items in one's pocket can be used for “confirming or refuting suspects' accounts of themselves.” This is a term we’ve internally adopted for all evasions in which malware authors are checking to see if the environment shows evidence of being a real, targeted host.

In terms of sandbox environments, checking for “pocket litter” commonly includes looking for things like a reasonable amount of system uptime, a sufficient number of files in the My Documents folder or a good number of pages in the system’s browser cache. These are all things that would help corroborate that the system is “real” and not a sandboxed environment. Like with the other categories, the number of variations are seemingly infinite.

Figure 10 shows another example where the malware checks if there are more than two processors available and whether there is enough memory available. Usually sandbox environments don’t have as much memory available as regular PCs, and this check is testing whether the target system is likely to be a desktop PC or running inside a sandbox environment.

Image 10 is a screenshot of many lines of code where the malware is checking if there are more than two processors available, and also checks memory availability. This allows the malware to see whether the target system is a desktop PC or is running inside a sandbox.
Figure 10. Check for the minimum required number of processors and required memory to run.

In Figure 11, there is another example where an AutoIt executable exits if the volume disk serial numbers match those of emulators used by known antivirus vendors.

Image 11 is a screenshot of many lines of code where an AutoIt executable exits after if the volume disk serial numbers match those of emulators used by known antivirus vendors. Displayed are the volume serial numbers being checked.
Figure 11. Check for volume serial numbers.

Pocket Litter Check Mitigations

In terms of mitigations, there is no single broad stroke that can be used to cover all available techniques. Rather, we attempt to address these on a case by case basis, where we can.

For example, when we see checks for specific types of files in particular places being used by evasions (if it appears to be an innocuous change to the VM image) we add them for any related samples to see. This pocket litter approach can feel like a cat and mouse game because there really is no panacea that addresses all threat actor mice. Persistence is key.

Conclusion

We emphasize that we are in no way claiming to have “solved” all sandbox evasions. In fact, the situation is quite the opposite when you consider that evasion classes are more or less infinite.

If there is a single takeaway from our discussion, it is that there are too many sandbox evasions out there to effectively address every single one. Anyone who tells you their sandbox is 100% evasion-proof is overdue for a run-in with reality.

We have discussed some of the high-level category evasions in broad strokes, as well as some of the strategies we’re using to address them. Because we can’t come close to addressing them all comprehensively, we recommend a defense-in-depth strategy. This allows us to architect detection systems in such a way that we can still detect malware when an evasion is successful and there is no execution of the payload.

For us on the WildFire team, this means a departure from simply relying on system API calls and other observable activity as the sole basis for detection. Because we have our own hypervisor, we have been able to utilize our control of all hardware/software to instrument software in the VM in a way that is invisible to the malware that is running.

As we discussed in our previous post on hypervisor memory analysis in Advanced WildFire, our goal is to make a new kind of analysis engine that targets malware in memory. For any evasion technique discussed here, the code to execute it must, at some point, exist in memory in order for it to execute and then successfully detect it is being analyzed.

Image 12 is a diagram of the process of detecting malware in memory, where the malware is loaded into memory and then downloads its payload, and the payload detects it’s running in a sandbox and terminates. The final step is where Advanced WildFire targets the payload in memory during a sandbox run.
Figure 12. Detecting malware in memory.

In our system, we’ve shifted detection focus to the deltas in memory during execution. As shown in Figure 12, if the payload or any code is decoded, decompressed or decrypted in memory, our system will have visibility and a solid chance at catching it.

In closing, our advice to anyone building out an automated malware analysis system is to be as flexible as possible in terms of reacting to the broad categories of sandbox evasions out there. It is guaranteed that you will run into many variations of the themes we discussed here.

We also recommend that you architect your system in a way that is tolerant to sandbox evasions. In other words, when all else fails and there are no execution events to scrutinize for malicious behaviors, there should be additional methods to fall back on. An example of what this looks like in practice is how we can analyze memory in Advanced WildFire to detect evasive malware even when payloads choose to remain dormant and not execute.

Thanks for joining us on this odyssey as we toured all of the ways malware authors go out of their way to avoid detection. Happy hunting!

Palo Alto Networks customers receive protections from threats such as those discussed in this post with Advanced WildFire.

Indicators of Compromise

SHA256 Description Malware family
3bf0f489250eaaa99100af4fd9cce3a23acf2b633c25f4571fb8078d4cb7c64d WMI queries Trickbot
e9f6edb73eb7cf8dcc40458f59d13ca2e236efc043d4bc913e113bd3a6af19a2 Timing attack using SetTimer Sundown payload
3450abaf86f0a535caeffb25f2a05576d60f871e9226b1bd425c425528c65670 Sleep using time stamp counter instruction VBCrypt
091ffdfef9722804f33a2b1d0fe765d2c2b0c52ada6d8834fdf72d8cb67acc4b Volume Disk serial number check Zebrocy

 

SHA256 Description Potentially unwanted applications
96a88531d207bd33b579c8631000421b2063536764ebaf069d0e2ca3b97d4f84 VMware check PUA/KingSoft
de85a021c6a01a8601dbc8d78b81993072b7b9835f2109fe1cc1bad971bd1d89 GetLastUserInput check PUA/InstallCore
Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow