Threat Brief: OWASSRF Vulnerability Exploitation

Posted on by Robert Falcone

Executive Summary

On Dec. 20, 2022, CrowdStrike published a blog discussing a new exploit method for Microsoft Exchange Server, which they named OWASSRF, referring to server-side request forgery in relation to Outlook on the web. (Outlook on the web is known as both Outlook Web Access and Outlook Web Application.)

The OWASSRF exploit method involves two different vulnerabilities tracked by CVE-2022-41080 and CVE-2022-41082 that allow remote code execution (RCE) via Outlook Web Access (OWA). The CVE-2022-41082 vulnerability was previously used by the ProxyNotShell exploit. However, the OWASSRF exploit method bypasses mitigations previously provided by Microsoft for ProxyNotShell. OWASSRF requires authentication to the Exchange Server prior to exploitation, thus we are seeing isolated rather than mass exploitation attempts.

Unit 42 observed that active exploitation of the OWASSRF vulnerability was occurring in late November and early December 2022.

Unit 42 did observe threat actor activity exploiting these vulnerabilities, in which the actor used a PowerShell-based backdoor that we are tracking as SilverArrow to run commands on the Exchange Server. The actors ran commands to do the following:

  • Create an administrator account
  • Install the AnyDesk remote desktop application
  • Create an SSH tunnel using PuTTY Link to remotely access Windows Remote Desktop Protocol (RDP)
  • Dump memory of the LSASS process to harvest credentials

Our Cortex XDR customers were protected against the RCE portion of the OWASSRF vulnerability, as XDR prevented the PowerShell scripts from running in the event of exploitation.

Palo Alto Networks customers receive protections through a variety of products and services, including the following:

Vulnerabilities Discussed CVE-2022-41080, CVE-2022-41082

Details of OWASSRF

On Dec. 20, 2022, CrowdStrike published a blog discussing a new exploit method for Microsoft Exchange Server, which they named OWASSRF. The exploit method involves two different vulnerabilities tracked by CVE-2022-41080 and CVE-2022-41082 that allow remote code execution (RCE) via Outlook Web Access (OWA). The CVE-2022-41082 vulnerability was previously used by the ProxyNotShell exploit, however, the OWASSRF exploit method bypasses mitigations previously provided by Microsoft for ProxyNotShell.

Both ProxyNotShell and OWASSRF use a server side request forgery (SSRF) vulnerability. However, the ProxyNotShell method used an AutoDiscover endpoint to exploit CVE-2022-41040, while OWASSRF uses the OWA frontend endpoint to exploit CVE-2022-41080. Much like ProxyNotShell, the newly found exploit method requires the actor to be authenticated to the server prior to exploitation.

According to a tweet by @Purp1eW0lf on Dec. 14, 2022, actors exploiting the OWASSRF vulnerability left an open directory on their web server that contains several of their tools, including the Python script that contains code to exploit OWASSRF. Additionally, the open directory included a readme file. Its contents (see Figure 1) describe how to use the script to exploit ProxyNotShell, and also suggest that this was developed specifically to bypass hotfixes for the ProxyNotShell vulnerability.

Image 1 is a screenshot showing the readme.txt of the threat actors' open directly. It contains instructions for the exploit code exploiting OWASSRF.
Figure 1. readme.txt on actors' open directory that contains usage for the exploit code that exploits OWASSRF

Using the code found in this open directory, we were able to better understand how this exploit works. After successfully authenticating to the Exchange Server, the exploit code will issue POST requests to /owa/mastermailbox%40outlook.com/powershell as seen in Figure 2, which is the same URL structure mentioned in CrowdStrike’s OWASSRF blog.

The POST request also includes a header X-OWA-ExplicitLogonUser that has a value of owa/mastermailbox@outlook[.]com. The header value is removed from the URL during processing. The change in the URL is likely the cause of the server side request forgery tracked in CVE-2022-41080.

It should be noted that this traffic would occur over HTTPS so the POST request would be within an encrypted session. Also, we determined that the email address does not necessarily have to be mastermailbox@outlook[.]com, as any email address would suffice.

Image 2 is a screenshot of showing the OWASSRF exploit scripts initial POST request.
Figure 2. Initial POST request to Exchange Server from OWASSRF exploit script.

After exploitation, the exploit code will run supplied PowerShell in the form of a base64-encoded string. The exploit code replaces $$POWERSHELL_ENCODE_PAYLOAD_HERE$$ in the XML seen in Figure 3 with the base64-encoded PowerShell and will send this XML to the Exchange Server to run.

Image 3 is a screenshot of message data sent to the Microsoft Exchange server to run encoded PowerShell. Highlighted are the argument and the filename.
Figure 3. Message data sent to an Exchange Server to run encoded PowerShell after exploiting OWASSRF.

Current Scope of the Attack

At the time of writing, Unit 42 is aware of eight organizations that have seen exploitation activity. In exploit attempts we observed on Dec. 2 and 3, the actors attempted to run PowerShell that was base64-encoded, as seen in Figure 4. The decoded PowerShell code is a backdoor that we are tracking as SilverArrow.

Image 4 is a screenshot showing an example encoded PowerShell script seen in OWASSRF exploit attempts.
Figure 4. Example of the encoded PowerShell script seen in OWASSRF exploit attempts in early December 2022.

The SilverArrow backdoor – decoded from what is seen in Figure 5 – is effectively a remote shell. It connects to a remote server (0xd8809226 or 216.128.146[.]38 in this specific case) and enters a loop to receive additional PowerShell commands that it will run and then respond to the server with the result. This particular remote shell provides the actors with a shell prompt of SL>, which is the basis of the name SilverArrow.

Image 5 is a screenshot of many lines of code showing the decoded PowerShell script delivered by OWASSRF exploit attempts.
Figure 5. Decoded PowerShell script delivered in OWASSRF exploit attempts in early December 2022.

All OWASSRF exploit attempts observed by Unit 42 have resulted in the same PowerShell backdoor. We have observed the following IP addresses used as command and control (C2) servers for these backdoors:

  • 216.128.146[.]38
  • 95.179.162[.]125
  • 192.248.176[.]138
  • 140.82.52[.]35
  • 45.32.144[.]71

Several of our XDR customers experienced exploit attempts, in which the post-exploitation PowerShell activity was prevented (see Figure 6). The prevention of the PowerShell code from executing blocked the threat actors from carrying out any post-exploitation activities.

Image 6 is a screenshot of the Cortex XDR program showing prevented PowerShell activity. It details alerts and what processes were terminated.
Figure 6. PowerShell activity prevented by Cortex XDR after OWASSRF exploitation.

Unfortunately, one Exchange Server did not have XDR in blocking mode and the OWASSRF exploit was successful on Nov. 28, 2022, which resulted in the execution of PowerShell code. After exploitation, the threat actors used PowerShell to run several commands. The threat actors used the whoami command, created a user named Admon and added the Admon user to the local administrators and remote desktop users groups (see Figure 7).

The actors also downloaded PuTTY Link (pta.exe) and the AnyDesk remote desktop application to the server, the latter of which the actors installed to start up with Windows to persist reboots. The actors used PuTTY Link to create an SSH tunnel to 217.69.10[.]255 to be able to access RDP on the local server, which further shows the threat actors’ interest in using remote desktop tools to interact with the compromised server. We are also aware of the threat actors creating SSH tunnels to the IP address 45.76.246[.]112.

Image 7 is a screenshot of the Cortex XDR program showing a tree diagram where the threat actor activity is displayed post-exploitation of the PowerShell activity.
Figure 7. PowerShell activity post-exploitation showing threat actor activity.

Shortly after the activity seen in Figure 7, the threat actors used their newly created Admon user account and their remote desktop access to dump the memory of the LSASS process. The actor used the legitimate Task Manager application in Windows to dump the LSASS process memory, as seen in Figure 8. We believe the threat actors dumped the LSASS memory and exfiltrated the dump file to extract credentials rather than doing so locally on the server, as we saw no processing of the dump file on the server.

Image 8 is a screenshot of the Cortex XDR program showing an alert where the threat actor used Task Manager to dump LSASS memory for credential gathering.
Figure 8. Threat actor using Task Manager to dump the memory of LSASS for credential gathering.

Interim Guidance

Unit 42 recommends customers apply the Nov. 8, 2022, security update to their Exchange Servers. Palo Alto Networks Cortex XDR protected customers from the payloads deployed by this exploit using the Anti Webshell Protection module and behavioral threat protection.

Unit 42 Managed Threat Hunting Queries

The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.

Conclusion

Unit 42 observed active exploitation of the OWASSRF method in the wild via the exploitation of CVE-2022-41080 and CVE-2022-41082. We are not seeing mass exploitation attempts of OWASSRF as it requires authentication to the Exchange Server. We saw isolated OWASSRF attempts to exploit Exchange Server in which the threat actors likely used credentials previously stolen by unknown means.

In known successful exploitation attempts, the threat actors used PowerShell to run additional commands to gain remote desktop access to the Exchange Server. This involved the creation of a new administrator account, the creation of an SSH tunnel using PuTTY Link to access Windows Remote Desktop and the installation of the AnyDesk application. The actors used these remote desktop tools to gather credentials, but we are unsure of the actors’ goals as the server was quickly mitigated.

Due to the availability of a proof-of-concept exploit script for the OWASSRF method, Palo Alto Networks highly recommends applying Microsoft’s Nov. 8, 2022, security update to your Exchange Servers to mitigate this vulnerability. Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information, release of proof-of-concept code and evidence of more widespread exploitation.

Palo Alto Networks Product Protections for OWASSRF

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

If you think you may have been compromised 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

Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention

Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with an Advanced Threat Prevention security subscription can automatically block sessions related to CVE-2022-41080 using Threat ID 93319 (Application and Threat content update 8658).

Cloud-Delivered Security Services for the Next-Generation Firewall

Known IPs and domains associated with this malicious activity are categorized as malicious by Advanced URL Filtering and DNS Security.

Cortex XSOAR

The Cortex XSOAR playbook, “CVE-2022-41040 & CVE-2022-41082 - ProxyNotShell,” was updated with more hunting, remediation and mitigation tasks to identify and respond to exploitation attempts. This playbook is part of the Rapid Response Pack, which includes various playbooks for trending vulnerabilities and threats and is available on Cortex Marketplace.

Cortex XDR

Cortex XDR Agent protected customers from the payloads deployed by this exploit using the Anti Webshell Protection module and behavioral threat protection.

Cortex XDR Agent running on version 7.8 and above with content version 810-32342 and above will block the exploitation attempt of the exploitation chain that we have identified. Please make sure your agents are configured in blocking mode for Exploit Protection, behavioral threat protection and the Anti Webshell Protection module.

Prisma Cloud

Prisma Cloud has detection capabilities in place for CVE-2022-41080 and CVE-2022-41082. Prevention capabilities also exist with runtime defenses on virtual machines (VMs), serverless functions and containers performing malicious operations on vulnerable containers. Compute agents should be installed on container hosts, serverless functions and VM instances, and ensure they are configured with the latest Prisma Cloud Intelligence Stream (IS) offering and have runtime protection set to active.

Indicators of Compromise

Infrastructure

140.82.52[.]35
217.69.10[.]255
45.76.246[.]112
216.128.146[.]38
95.179.162[.]125
192.248.176[.]138
140.82.52[.]35
45.32.144[.]71

Meddler-in-the-Middle Phishing Attacks Explained

Posted on by Samantha Stallings

Executive Summary

We’ve probably all received advice for how to avoid phishing, such as to be on the lookout for spelling errors or other mistakes that would alert us to the presence of fraudsters. However, this advice is only helpful for traditional phishing techniques. Meddler in the Middle (MitM) phishing attacks show how threat actors find ways to get around traditional defenses and advice.

MitM phishing attacks are a state-of-the-art type of phishing attack capable of breaking two-factor authentication (2FA) while avoiding many content-based phishing detection engines. Rather than showing a spoofed version of a target login page, a MitM attack uses a reverse-proxy server to relay the original login page directly to the user’s browser.

As of November 2022, several phishing attacks have used MitM tactics to compromise business email accounts and to successfully steal organizations’ confidential information. There are several popular MitM phishing toolkits that make it easy for hackers to launch their own MitM phishing attacks in just a few clicks.

These toolkits are continually expanding their sets of features while simultaneously becoming more intuitive and easy to use. Many already employ sophisticated cloaking techniques, allowing them to evade detection by traditional phishing detection systems. As such, we expect that the prevalence of these MitM phishing attacks will continue to rise in the near future.

Palo Alto Networks customers receive protection from the attacks discussed in this blog through Advanced URL Filtering by blocking MitM phishing pages in real time.

Related Unit 42 Topics Phishing, Credential Theft

Introduction: Traditional Phishing Attacks

The purpose of a phishing attack is to set up a false login page to trick users into entering their login credentials.

In traditional phishing attacks, attackers will usually create their own phishing page to mimic a legitimate login page. They might host this either on a newly created domain, compromise a legitimate domain and host their phishing page on this domain, or use an existing SaaS platform to host their phishing content.

“Phishing kits” simplify the process of creating and deploying phishing attacks by providing a set of programs and/or scripts that allow even inexperienced cybercriminals to launch their own phishing attacks. These kits often employ templated webpages that mimic targeted companies’ actual login pages. Web-based phishing-as a-service (PhaaS) platforms such as Caffeine (shown in Figure 1) and Robin Banks go one step further by providing easy-to-use interfaces that allow threat actors to configure and deploy phishing attacks.

Image 1 is a screenshot of the Phishing-as-a-Service platform caffeine, which provides features and tools for threat actors at cost.
Figure 1. The homepage for Caffeine, a phishing-as-a-service (PhaaS) platform first revealed in October 2022.

In traditional phishing attacks, the phishing page is typically hosted directly on the malicious or compromised server, and might not necessarily be a perfect replica of a legitimate login page. For example, if an attacker were to create a phishing page mimicking a GitHub login, they might not care to recreate all the various other features surrounding the core login feature, such as the “Forgot My Password” link.

An expert or careful observer might be able to notice subtle discrepancies between the legitimate GitHub login page and the spoofed phishing page and realize that the spoofed page is illegitimate. Figure 2 shows an example of how phishing pages can differ from the original target login page.

Similarly, automated content-based phishing prevention engines might notice that these illegitimate login pages contain signs of suspicious content (such as broken links or misspellings) and flag them as a possible phishing site.

Image 2 is a screenshot comparing two Microsoft login pages. The image on the left is a fake login page that does not use the correct fonts, but the look itself is very close to a real login page and includes Microsoft's logo. The image on the right is the authentic login page as of late November 2022.
Figure 2. Left: An example of a spoofed Microsoft login page used in a phishing attack. Right: Original Microsoft login page, as of Nov. 21, 2022.

Even with these flaws, the sheer number of recipients in these phishing campaigns mean that some targets could still fall victim to these attacks. Two-factor authentication (2FA), aka multifactor authentication (MFA), has become an increasingly popular way of adding an additional layer of security to protect against successful phishing attacks.

An example of 2FA in action is when, in addition to requiring a username and password, a legitimate login site also requires an additional form of authentication such as a one-time password (OTP) sent to the user’s registered email address. Even if an attacker were to gain access to a victim’s username and password via a successful phishing attack, they would not be able to log in as that user, because they would not be able to retrieve the OTP that would be sent during the malicious login attempt.

MitM Phishing Attacks

MitM phishing attacks are a new type of phishing attack that bypasses both content-based defenses and 2FA. Unlike traditional phishing attacks, which show a separate but spoofed version of a legitimate login page, MitM attacks show the user the exact same content that they would see on the legitimate login page. Instead of hosting a replica of a legitimate login page, MitM servers simply take the content rendered on the legitimate site and relay it to the end user, as shown in Figure 3.

In other words, MitM servers act as a proxy between the target and the legitimate login page. When the target enters their credentials into the proxied page, the MitM server stores the credentials away and forwards them to the legitimate login page, resulting in a successful login attempt. From the victim’s perspective, everything appears as if they had logged in to the legitimate page itself.

Furthermore, both connections (MitM server to legitimate site, and victim to MitM server) are served via the HTTPS protocol, so the victim will see that the connection is “secure” according to the padlock icon in the web browser’s address bar.

Image 3 is a visual representation of a Meddler-in-the-Middle phishing attack where the victim user is intercepted by the MITM phishing toolkit so the threat actor can then access the target web server.
Figure 3. Visual representation of a MitM phishing attack (reproduced from Catching Transparent Phish).

Since the content shown to the target is exactly the same as the content that they would see on the legitimate login page, this proxy-based approach makes it much harder for victims to visually discern that something suspicious is happening, and makes it very difficult for content-based phishing detection engines to notice anything suspicious.

To use a painting as an analogy, we can consider a traditional phishing attack to be like looking at a (potentially sloppy) replica of a $20 million Van Gogh painting made by a fraudulent artist. A MitM phishing attack is like viewing the original painting via a well-hidden mirror.

MitM attacks have several other benefits in addition to cosmetic ones. For example, if the user has 2FA set up, this proxy-based approach allows the MitM server to automatically bypass this 2FA as well.

After the MitM server forwards the username and password to the legitimate site, the legitimate site will then follow its normal behavior of sending an OTP to their client. The target – if tricked – will then input the one-time password into the MitM phishing page. This allows the MitM server to relay the password to the legitimate site, thereby fully completing the login attempt.

At this point, the MitM server would receive a real session cookie from the legitimate site. This persistent login allows the victim to continue to browse the site apparently as normal (though still via the attacker’s web server), further perpetuating the phishing attack’s air of legitimacy.

MitM Phishing Attacks in the Real World

At the time of writing, there are several tools that make it easy for hackers to deploy their own MitM phishing attacks in just a few clicks. Similar to traditional phishing kits, these MitM phishing kits provide a set of scripts – or in some cases, even graphical user interfaces (GUIs) – that make it easy for attackers to configure and launch MitM phishing attacks.

In Table 1, we introduce some of the more popular MitM phishing kits available at the time of writing. Each of these kits employ the core tactic of relaying the original login page to the victim’s browser, but they differ in their implementation details and additional features (e.g., cloaking and TLS certificate generation).

For example, Evilginx2 generates unique tokenized URLs (aka “lures”) that must be directly visited to show the phishing content. Requests to any other path result in a redirect to a benign site.

Name First Released/Reported Description
Evilginx2 July 2018 (first version released May 2017) Feature-rich MitM phishing kit with an easy-to-use command-line interface. Has cloaking features built in. Generates unique tokens (lures) that must be present in the URL to reveal the phishing content. The command-line interface for this tool is shown in Figure 4.
Modlishka January 2019 Automates several configuration steps and post-compromise actions, such as launching an instrumented Chrome instance with the stolen session cookie.
Muraena May 2019 Barebones MitM toolkit. Unlike some other toolkits that automatically create TLS certificates, Muraena requires the attacker to provide their own certificate.
EvilnoVNC September 2022 Uses a real web browser to render the login page on the attack server, and serves the content to the victim’s browser via VNC.
EvilProxy September 2022 Phishing-as-a-service platform for MitM phishing attacks. Provides an easy-to-use GUI for threat actors to set up and manage their own MitM phishing campaigns.

Table 1. Breakdown of popular MitM phishing kits.

Image 4 is a screenshot of the website offering the phishing kit Evilginx2.
Figure 4. Screenshot demonstrating the use of the Evilginx2 command-line interface to launch and execute a MitM phishing attack.

Before this year, MitM-related tactics had already been used to successfully impersonate large software organizations, expose hundreds of millions of users’ personal data, and steal millions of dollars from up-and-coming startups. However, these attacks did not necessarily use phishing per se as their primary attack vector. Now, MitM-based phishing attacks have started to take center stage.

Mid-2022 MitM Phishing Campaign

In July 2022, Microsoft reported a phishing campaign using Evilginx2 to steal targets’ Microsoft credentials. The campaign sent emails to potential victims prompting them to download an important attachment. After opening the attachment and routing through a series of redirects, the victim would arrive at a MitM phishing page like that shown in Figure 5. After the attackers successfully intercept an authentication cookie, they would log on to the compromised Outlook account and continually search for finance-related emails and attachments in order to find opportunities for payment fraud.

Image 5 is a screenshot of a Microsoft login page reported by Microsoft in July 2022.
Figure 5. MitM credential-stealing page that was a part of the campaign reported by Microsoft in July 2022.

In an attempt to avoid detection, the campaign used a variety of cloaking techniques to ensure that the phishing content would only load if the victim had navigated to the page via the original HTML attachment. By the time Microsoft’s threat intelligence article was published, more than 10,000 organizations had been targeted by this campaign over the span of several months.

According to Palo Alto Networks Advanced URL Filtering logs, our Advanced URL Filtering service had begun blocking web traffic to tokenized phishing URLs hosted on the attackers’ domains (e.g., login[.]mcrsfts-passwdupdate[.]com/HMxVQmxZ) as early as September 2021.

Late 2022 MitM Phishing Campaigns

In September 2022, a separate campaign was found to be using MitM phishing tactics to steal targets’ GitHub login credentials. Several domains were used to mimic a CircleCI login page, prompting victims to log in with their GitHub credentials (as shown in Figures 6 and 7).

Image 6 is a screenshot mimicking the landing page for circle-ci. From this landing page the user would then have their credentials stolen after logging in.
Figure 6. circle-ci[.]com. Example landing page for the September 2022 GitHub phishing campaign. Upon clicking “Log in with GitHub,” the user would be shown a MitM credential stealing page which mirrored GitHub’s actual login page.
Image 7 is a screenshot continuing the credential stealing process started in image 6. It is a screenshot of the credential-stealing page after leaving the circle-ci page.
Figure 7. MitM credential stealing page linked to by the webpage in the previous figure. The webpage is not hosted on the phishing server, but rather relayed from GitHub itself.

For targets with OTP-based 2FA set up, the MitM server also prompted them to enter the OTP, which was then forwarded to GitHub, allowing for a successful login. From there, attackers would persist in their access by quickly creating personal access tokens (PATs) or adding their own SSH keys to the victim’s account. That way, attackers would continue to have access to the compromised account even if the victim were to change their username and password.

In November 2022, it was revealed that Dropbox had fallen victim to a MitM phishing attack that allowed attackers to compromise and copy 130 private repositories. This shows that these MitM phishing attacks are already making a significant impact in the real world. In Dropbox's response to this attack, they stated that they plan to move their 2FA protocols from OTP to WebAuthn, which is a more phishing-resistant form of 2FA.

Present Day Phishing Activity

In recent weeks, our Advanced URL Filtering service has been detecting more MitM phishing URLs, with enterprise logins like Microsoft 365 being prime targets (shown in Figures 8 and 9).

Image 8 is a screenshot of a phishing URL that targeted Microsoft. It shows the Microsoft login page.
Figure 8. -r-us[.]co[.]uk. A MitM phishing page targeting Microsoft, detected by our Advanced URL Filtering service.
Image 9 is a screenshot of a phishing URL that targets Microsoft's online support page.
Figure 9. microsoftonlinesupport[.]cf. A MitM phishing page targeting Microsoft 365, detected by our Advanced URL Filtering service.
As MitM phishing kits grow in popularity and continue to expand their feature sets, we expect the prevalence of MitM phishing attacks to increase as well. Threat actors are already making strides in this direction. In fact, Evilginx 3.0 is expected to be released in the near future, along with an online course on how to successfully execute a MitM phishing attack.

Conclusion

MitM phishing attacks have already resulted in significant real-world breaches, and are expected to rise in prevalence as MitM phishing toolkits continue to expand and evolve. As such, it becomes increasingly important for organizations to protect themselves from these sorts of cutting-edge phishing attacks.

At the moment, actions that end users can take to protect themselves against MitM phishing attacks include:

  • Verifying the validity of a URL before inputting any credentials
    (e.g., ensure that a URL is really “github[.]com” and not something like “github-impersonator[.]org”).
  • Using a password manager to store and enter credentials. If you find yourself on a MitM phishing page hosted on a website that the password manager does not recognize, the password manager will warn you before entering your credentials.
  • Using more up-to-date MFA methods, such as hardware security keys or WebAuthn 2FA.

Furthermore, customers who subscribe to Palo Alto Networks Advanced URL Filtering service receive protection from MitM phishing attacks via our in-line phishing URL detection, including the MitM phishing URLs mentioned in this article. Advanced URL Filtering analyzes web traffic in real time to block attacks before they make their way to the target. That way, even if a MitM phishing attack uses cloaked URLs (as is the case with Evilginx2), Advanced URL Filtering can block the attack before credentials are stolen.

Indicators of Compromise

  • mcrsfts-passwdupdate[.]com
  • circle-ci[.]com
  • infollnes-r-us[.]co[.]uk
  • microsoftonlinesupport[.]cf

Additional Resources

What Is a Proxy Server
Multifactor Authentication (CISA)
Legitimate SaaS Platforms Being Used to Host Phishing Attacks
Catching Transparent Phish

Acknowledgements

The authors would like to thank Wei Wang and Javier Wang for their guidance in researching for and writing this article.

Updated December 21, 2022 at 1:00 p.m. PT.

Russia’s Trident Ursa (aka Gamaredon APT) Cyber Conflict Operations Unwavering Since Invasion of Ukraine

Posted on by Unit 42

Executive Summary

Since our last blog in early February covering the advanced persistent threat (APT) group Trident Ursa (aka Gamaredon, UAC-0010, Primitive Bear, Shuckworm), Ukraine and its cyber domain has faced ever-increasing threats from Russia. Trident Ursa is a group attributed by the Security Service of Ukraine to Russia’s Federal Security Service.

As the conflict has continued on the ground and in cyberspace, Trident Ursa has been operating as a dedicated access creator and intelligence gatherer. Trident Ursa remains one of the most pervasive, intrusive, continuously active and focused APTs targeting Ukraine.

Given the ongoing geopolitical situation and the specific target focus of this APT group, Unit 42 researchers continue to actively monitor for indicators of their operations. In doing so, we have mapped out over 500 new domains, 200 samples and other Indicators of Compromise (IoCs) used within the past 10 months that support Trident Ursa’s different phishing and malware purposes.

We are providing this update along with known IoCs to highlight and share our current overall understanding of Trident Ursa’s operations.

While monitoring these domains as well as open source intelligence, we have identified multiple items of note:

  • An unsuccessful attempt to compromise a large petroleum refining company within a NATO member nation on Aug. 30.
  • An individual who appears to be involved with Trident Ursa threatened to harm a Ukraine-based cybersecurity researcher immediately following the initial invasion.
  • Multiple shifts in their tactics, techniques and procedures (TTPs).

Palo Alto Networks customers receive protections against the types of threats discussed in this blog by products including Cortex XDR, WildFire, Advanced URL Filtering, Advanced Threat Prevention and DNS Security subscription services for the Next-Generation Firewall.

Related Unit 42 Topics Russia, Ukraine, Gamaredon 
Trident Ursa APT Group akas Gamaredon, UAC-0010, Primitive Bear, Shuckworm

Targeting Beyond Ukraine

Traditionally, Trident Ursa has primarily targeted Ukrainian entities with Ukrainian language lures. While this is still the most common scenario for this group, we saw a few instances of them using English language lures. We assess that these samples indicate that Trident Ursa is attempting to boost their intelligence collection and network access against Ukrainian and NATO allies.

In line with these efforts to target allied governments, during a review of their IoCs we identified an unsuccessful attempt to compromise a large petroleum refining company within a NATO member nation on Aug. 30.

SHA256 Filename
b1bc659006938eb5912832eb8412c609d2d875c001ab411d1b69d343515291b7 MilitaryassistanceofUkraine.htm
0b63f6e7621421de9968d46de243ef769a343b61597816615222387c45df80ae Necessary_military_assistance.rar
303abc6d8ab41cb00e3e7a2165ecc1e7fb4377ba46a9f4213a05f764567182e5 List of necessary things for the provision of military humanitarian assistance to Ukraine.lnk (Note: File bundled in above .rar)

Table 1. English language samples used by Trident Ursa.

Beyond Just Hacking: Open Threats to Cybersecurity Community

One of our most surprising observations was when an individual named Anton (in Cyrillic, Антон) who appeared to be tied to Trident Ursa threatened a small group of cybersecurity researchers on Twitter, on the same day Russia invaded Ukraine (Feb. 24, 2022). It appears that Anton chose these researchers based on their tweets highlighting Trident Ursa’s IoCs in the days prior to the invasion.

The first tweets (shown in Figure 1) came from Anton (@Anton15001398) as the invasion was underway, to Ukraine-based threat researcher Mikhail Kasimov (@500mk500). In several tweets, he said, “run, i’m coming for you.” Likely figuring his first tweets to Kasimov were too unnoticeable, his last tweet included the #Gamaredon hashtag so it would be more publicly discoverable by other researchers.

Image 1 is a series of three tweets made by Twitter user Anton15001398 targeting Ukrainian-based threat researcher Mikhail Kasimov, whose Twitter account is 500mk500. In the tweets the actor uses the hashtag Gamaredon and tells Mikhail to “run, I’m coming for you.”
Figure 1. Threatening Mikhail Kasimov.

Later that same day, Anton used a different account (@YumHSh2UdIkz64w) to send Shadow Chaser Group (@ShadowChasing1) and TI Research (@tiresearch1) the ominous message “let's be friends. We do not want to fight, but we do it well!” as shown in Figure 2.

Image 2 is a screenshot of a tweet made by Twitter user YumHSh2UdIkz64w tagging Shadow Chaser Group’s Twitter account ShadowChasing1) and the TI Research Twitter account tiresearch1 with the message “let's be friends. We do not want to fight, but we do it well!” It uses the hashtag Gamaredon.
Figure 2. Warning away Shadow Chaser Group and TI Research.

Two days later, on Feb. 26, Anton sent his last and most threatening tweet yet (Figure 3). In it, he provides Mikhail Kasimov’s full name, date of birth and address along with the message, “We are already in the city, there is nowhere to run. You had a chance.”

Image 3 is a screenshot of a tweet made by Twitter user YumHSh2UdIkz64w targeting Ukrainian-based threat researcher Mikhail Kasimov. He reveals personal information that has been redacted in the screenshot with the message “We are already in the city, there is nowhere to run. You had a chance.” It uses the hashtag Gamaredon.
Figure 3. Doxing and threatening Mikhail Kasimov (full name, date of birth, and address redacted from the original tweet).

We imagine these direct, threatening communications from this purported Trident Ursa associate were unsettling to the recipients (especially Mikhail Kasimov, a researcher operating from within the war zone). To their credit, the targeted researchers were undaunted, and tweeted additional Trident Ursa IoCs over the weeks following these threats. Kasimov, along with a large number of other researchers from around the world, continues to routinely publish new IoCs for this APT.

DNS Shenanigans

Trident Ursa has used fast flux DNS as a way to increase the resilience of their operations, and to make analysis of their infrastructure more difficult for cybersecurity analysts. Infrastructure using fast flux DNS rotates through many IPs daily, using each one for a short time to make IP-based block listing, takedown efforts and forensic analysis difficult.

The use of this technique is the primary reason Unit 42 researchers focus on Trident Ursa’s domains instead of their IPs. Since June 2022, we’ve seen Trident Ursa use several other techniques in addition to fast flux to enhance their operational efficacy.

A number of legitimate tools and services have been used by this threat actor in their operations. Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate product being abused.

Bypassing DNS Through Legitimate Web Services

The first example of additional techniques we’ve observed uses legitimate services to query IP assignments for malicious domains. By using these services, Trident Ursa is effectively bypassing DNS and DNS logging for the malicious domains. For example, the sample SHA256 499b56f3809508fc3f06f0d342a330bcced94c040e84843784998f1112c78422 calls the legitimate service ip-api[.]com to get the IP associated with josephine71.alabarda[.]ru through the following URL: hxxp://ip-api[.]com/csv/josephine71.alabarda.ru.

As of the time of writing this post, this process returns the following:

Image 4 is a screenshot of two lines of code. It shows the process of bypassing the DNS and DNS logging.

The malware uses the IP returned through this communication for follow-on communications with the malicious domain. The only DNS query that would show up in logging would be the original request for ip-api[.]com.

Bypassing DNS Through a Messaging Service

In the second example, Trident Ursa uses Telegram Messenger content to look up the latest IP used for command and control (C2). In this way, the actor is attempting to supplement DNS for when targets successfully block malicious domains.

For example, the sample SHA256 3e72981a45dc4bdaa178a3013710873ad90634729ffdd4b2c79c9a3a00f76f43 calls to hxxps://t[.]me/s/dracarc. As of Nov. 18, this account (@dracarc) returned the Telegram post ==104@248@36@191==. This is converted to the IP 104.248.36[.]191 and it is used for follow-on communications.

Hiding True IP Assignment Through Separate IPs for Root Domain and Subdomains

On Nov. 15, we noticed that the Trident Ursa domain niobiumo[.]ru was assigned to the U.S. Department of Defense Network Information Center IP 147.159.180[.]73. We quickly identified that Trident Ursa had no operational control over, or use of, that IP.

Trident Ursa had seeded the fast flux DNS tables for its root domains with “junk” IPs in an attempt to confuse researchers and protect its true operational infrastructure. Instead of using root domains, they were instead using subdomains for their operations.

The true operational IP could only be found by querying DNS upon a subdomain. In this case (shown in Figure 4), querying upon subdomain aaa.niobiumo[.]ru returned the operational IP 64.227.67[.]175.

Image 4 is a table with columns listing name, class, type, data and time to live of domains, with the domains listed under the “name” column. An arrow points to the operational IP for the subdomain, and another arrow points to the DoD IP assigned for the root domain.
Figure 4. reg[.]ru name servers send a fake address for the domain and a real address for the subdomain (note: DNS lookup for aaa.niobium[.]ru as of Nov. 15).
We highlight two observations stemming from our analysis of Trident Ursa’s DNS activity:

  • For its operational infrastructure outside of Russia, Trident Ursa has relied primarily on VPS providers located within one of two autonomous systems (AS), AS14061 (DigitalOcean, LLC) and AS20473 (The Constant Company, LLC). Over the past six weeks, of the 122 IP addresses we identified outside of Russia, 63% of them were within AS14061 and 29% were within AS20473. The remainder were located across several AS owned by UAB Cherry Servers.
  • Over 96% of Trident Ursa’s domains continue to be registered and under the DNS of the Russian company reg[.]ru, a company that – to date – has taken no action to block or deny this malicious infrastructure.

Various Malware Types Used

Over the past few months, Trident Ursa has relied upon a couple of different tactics to initially compromise victim devices using VBScripts with randomly generated variable names and concatenation of strings for obfuscation. Each of these tactics ultimately rely on the delivery of malicious content through spear phishing.

The first delivery method we will look at uses .html files, and the second uses Word documents.

Phishing Using HTML Files

Trident Ursa delivers an .html file either as an attachment to their phishing email, or via a link to the .html file (in an attempt to bypass email threat scanning). They use seemingly benign URLs such as hxxp://state-cip[.]org/arhiv, as shown in Figure 5. This site appears to still be active at the time of writing this post.

Image 6 is a screenshot of a phishing email with a download button. The download button link uses Trident Ursa.
Figure 5. Example of phishing email with link used by Trident Ursa.

These .html files contain Base64-encoded .rar archives that in turn contain a malicious .lnk file. Once a user clicks on these .lnk files, they use the Microsoft HTML Application (mshta.exe) to download additional files via URL, as shown in Figure 6.

Image 7 is a diagram showing the exploitation path for phishing using malicious .lnk files. It begins with phishing and ends with VBScripts.
Figure 6. Exploitation path for phishing using malicious .lnk files.

Taking a deeper look into recent .lnk file SHA256 0d51b90457c85a0baa6304e1ffef2c3ea5dab3b9d27099551eef60389a34a89b, we see that the file is 99.8 KB, which is approximately 98 KB larger than your average .lnk file.

Based on our review of these larger than expected .lnk files used by Trident Ursa, the file contains random 10-character strings that we assess were appended during the creation process. These are used to confuse analysis, and they have no purpose we can identify for Trident Ursa’s operations.

Once opened, this .lnk shortcut uses mshta.exe to contact hxxps://admou[.]org/29.11_mou/presented.rtf via a command line argument.

Trident Ursa appears to be using various techniques to limit who can access this URL. As other researchers have highlighted, Trident Ursa appears to be using geoblocking in order to limit downloads of this file to specific geographic locations.

In this case, we assess the ability to download presented.rtf via this URL is limited to Ukraine. There are some exceptions to this, however.

It appears that these threat actors are currently trying to stymie threat researchers by blocking ExpressVPN and NordVPN nodes within Ukraine. In addition, it appears that the actor is potentially conducting additional filtering to further control access to payloads. For example, VirusTotal receives an HTTP status code of 200, indicating success when requesting the above URL, but the overall content length of the reply is 0 bytes.

If the filtering conditions are met, the target downloads presented.rtf (SHA256 3990c6e9522e11b30354090cd919258aabef599de26fc4177397b59abaf395c3) upon opening the .lnk. The presented.rtf file is actually an HTA file that contains VBScript code.

This HTA file decodes two embedded Base64-encoded VBScripts, one of which it will save to %USERPROFILE%\josephine, and the other it runs using Execute. The VBScript decoded and executed by the presented.rtf file is responsible for adding persistence by running the VBScript saved to the josephine file each time the user logs in. The VBScript file saved to josephine is the payload at the end of this installation process.

The first VBScript responsible for enabling persistent access to the system does so by creating a Windows scheduled task and a registry key, both of which are common Trident Ursa techniques. This script creates a new scheduled task named Filmora.Complete that runs the josephine script every five minutes, as shown in the scheduled task information displayed in Figure 7.

Image 8 is a screenshot of the Command Prompt interface demonstrating how the VBscript creates a scheduled task, which runs the josephine script.
Figure 7. Filmora.Complete scheduled task used to run payload every five minutes.

The script also creates an autorun registry key to automatically run the josephine VBScript when the user logs in. Figure 8 shows the autorun registry key named telemetry added to the system to run the VBScript at user login.

Image 9 is a screenshot of the Command Prompt interface showing the autorun registry key added to the system, named telemetry, and where it was added to the system to run the VBScript at user login.
Figure 8. Autorun registry key used to run VBScript at user login.

The josephine script acts as the functional code of the backdoor, which allows the threat actors to run additional VBScript code supplied by a C2 server. The script contains two different methods to determine the IP address of its C2 server, with which it communicates directly.

The first method involves pinging the domain THEN<random number>.ua-cip[.]org using the following Windows Management Instrumentation (WMI) query and checking the ProtocolAddress value to determine the C2 IP address:


If the script is unable to reach this domain, it attempts to access the Telegram URL hxxps://t[.]me/s/vzloms to get the C2 IP address. It does this by checking the response using a regular expression of ==([0-9\@]+)==.

After obtaining the C2 IP address, this script will communicate with its C2 by issuing a custom crafted HTTP GET request, as seen in Figure 9. The custom fields modified in the HTTP request include a hardcoded user-agent with the computer name, volume serial number and the string ::/.josephine/. appended, as well as a hardcoded string used in the Accept-Language field.

Image 11 is a screenshot of multiple lines of code showing custom HTTP GET request sent to the C2 server. Custom fields have been modified.
Figure 9. HTTP request sent to the C2 server.

The josephine script reads the responses to this HTTP request, decodes the Base64 data within the response and executes it as a VBScript. We have not observed an active C2 server providing VBScripts in response to HTTP requests from the josephine script.

Phishing Using Word Documents

The latest phishing documents we’ve seen Trident Ursa use have low detection rates in VirusTotal, likely due to their simplicity. For example, SHA256 c22b20cee83b0802792a683ea7af86230288837bb3857c02e242fb6769fa8b0c shows 0/61 detections as of Dec. 8, 2022.

Image 11 is a screenshot of the VirusTotal software showing the number of detections for SHA 256. In the screenshot, VirusTotal does not flag the file as malicious.
Figure 10. VirusTotal detections for c22b20cee83b0802792a683ea7af86230288837bb3857c02e242fb6769fa8b0c.

This file relates to a purported tender to purchase computer equipment for the National Academy of Security Service of Ukraine. The file contains no malicious code in and of itself. When opened, the file attempts to contact and download its remote template from hxxp://relax.salary48.minhizo[.]ru/MAIL/gloomily/along.rcs.

This template, along.rcs (SHA256: 007483ad49d90ac2cabe907eb5b3d7eef6a5473217c83b0fe99d087ee7b3f6b3) is an object linking and embedding (OLE) file that contains a macro that runs the malicious code. The macro itself resembles the VBScript code within the HTA file mentioned above, used to load additional scripts.

The installation VBScript saves the payload VBScript to %USERPROFILE%\Downloads\frontier\decisive and creates a scheduled task named GetSynchronization-USA to automatically run this payload every five minutes.

The payload VBScript is the same as the payload above. It attempts to get the C2 IP address via a ping to <random number>decisive.hungzo[.]ru and a regular expression on the response from a specific Telegram URL, hxxps://t[.]me/s/templ36.

Once it has the IP address, the script creates an HTTP GET request to hxxp://<IP address of C2>/snhale<random number>/index.html=?<random number> with custom HTTP fields it populates with the following activities:

  • Appending the computer name and volume serial number in the custom user-agent field, (windows nt 6.1; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/90.0.4430.85 safari/537.36, along with the static string ;;/.insufficient/.
  • Using frameS5V as the cookie value
  • Setting the Referrer to hxxps://developer.mozilla[.]org/en-US/docs/Web/JavaScript
  • Setting Accept-Language to ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
  • Setting Content-Length to 4649

Lastly, the script will Base64 encode the response to this URL and attempt to execute it.

Recently Seen Droppers

Over the past three months, we’ve seen Trident Ursa use two different, yet very similar, droppers. The first dropper, usually named 7ZSfxMod_x86.exe, is the traditional 7-Zip self-extracting (SFX) archive technique the actor has used for years.

In these SFX files, the installation configuration script runs an embedded VBScript using Windows Script Host (wscript.exe). The second dropper, usually named myfile.exe according to the executable’s RT_VERSION resource, is effectively a loader that drops two files and eventually runs them as VBScript using wscript.

7ZSfxMod_x86.exe

A recent sample (SHA256 ac1f3a43447591c67159528d9c4245ce0b93b129845bed9597d1f39f68dbd72f) runs the following installation script when opened:

Image 11 is many lines of code that show an installation script.

Along with the installation script, the archive contains a VBScript named 19698.mov (SHA256: f488bd406f1293f7881dd0ade8d08f2b1358ddaf7c4af4d27d95f6f047339b3a) referenced within the installation script. Similar to the examples above, the VBScript will try two different methods to obtain its C2 location.

First, the script runs a WMI query to ping the C2 domain <random number>delirium.sohrabt[.]ru. Should this fail, it also includes a second C2 location routine that will reach out to a Telegram page at hxxps://t[.]me/s/vbs_run14. It then uses a regular expression of ==([0-9\@]+)== to find an IP address within the response.

The script replaces the "@" characters with a "." within the match of the regex to make an IPV4 address in dot notation, and it writes the resulting IP address to the file %TEMP%\prDK6.

Once it has the IP address, the script creates an HTTP GET request to hxxp://<IP address of C2>/snhale<random number>/index.html=?<random number> with custom HTTP fields it populates with the following activities:

  • Appending the computer name and volume serial number in the custom user-agent field, mozilla/5.0 (windows nt 6.1; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/86.0.4240.193 safari/537.36, along with the static string ;;/.snventor/.
  • Using defective as the cookie value
  • Setting the Referrer to hxxps://www.unn.com[.]ua/ru/
  • Setting Accept-Language to ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
  • Setting Content-Length to 2031

The script, like the one mentioned above, reads the response to this beacon, decodes the Base64 data within the response and runs the result as a VBScript using the Execute method. This script also has a backup URL that it will use if it receives an HTTP response status other than 200 or 404, specifically hxxp://<IP address of C2>/snquiries<random number>/index.html=?<random number>.

Myfile.exe

A recent sample (SHA256: a79704074516589c8a6a20abd6a8bcbbcc5a39a5ddbca714fbbf5346d7035f42) works as a loader that drops two files and eventually runs them as VBScripts using the wscript application.

First, the executable reads its own file data and skips to the end of the Portable Executable (PE) file to access the overlay data that was appended to the executable. The executable then decrypts the overlay data in reverse by using XOR on each byte with the byte that precedes it. Using this data, the executable writes the cleartext to the following locations:

  • C:\Users\<username>\nutfgqsjs.fjyc
  • C:\Users\<username>\16403.dll

The binary concatenates some strings to the contents written to nutfgqsjs.fjyc before writing this file to disk, specifically lines of VBScript code to delete the initial executable and the two VBScript files. The executable concludes by running the nutfgqsjs.fjyc script by calling CreateProcessA using the following command line:

A screenshot of code showing the command line where the VBScript is running.

The nutfgqsjs.fjyc file is a VBScript file that contains a significant amount of comments that are meant to hide the actual code. This script includes the following functional code that runs the 16403.dll VBScript:

A screenshot of multiple lines of code showing the 16403.dll VBScript

The file 16403.dll is another VBScript with the functional code that decodes another VBScript and runs it. After several layers of decoding and replacing text, the ultimate VBScript eventually runs. This final VBScript uses the same techniques described in the .lnk and 7ZSfxMod_x86.exe descriptions above.

First, the script runs a WMI query to ping the C2 domain morbuso[.]ru. Should this fail, it also includes a second C2 location routine that will reach out to a Telegram page, specifically hxxps://t[.]me/s/dracarc. As of Nov. 18, this account (@dracarc) returned the following, ==104@248@36@191==. Using the regular expression of ==([0-9\@]+)== this is converted to the IP 104.248.36[.]191 and used for follow-on communications.

The script then creates an HTTP GET request to hxxp://<IPV4>/justly/CRONOS.icn?=Chr with custom HTTP fields it populates with the following activities:

  • Appending the computer name and volume serial number in the custom user-agent field, mozilla/5.0 (macintosh; intel mac os x 10_15_3) applewebkit/605.1.15 (khtml, like gecko) version/13.0.5 safari/605.1.15;; along with the static string ;;/.justice/.
  • Using jealous as the cookie value
  • It does not set Referrer in this instance
  • Setting Accept-Language to ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
  • Setting Content-Length to 5537

Lastly, the script will Base64 encode the response to this URL and attempt to execute it.

Conclusion

Trident Ursa remains an agile and adaptive APT that does not use overly sophisticated or complex techniques in its operations. In most cases, they rely on publicly available tools and scripts – along with a significant amount of obfuscation – as well as routine phishing attempts to successfully execute their operations.

This group’s operations are regularly caught by researchers and government organizations, and yet they don’t seem to care. They simply add additional obfuscation, new domains and new techniques and try again – often even reusing previous samples.

Continuously operating in this way since at least 2014 with no sign of slowing down throughout this period of conflict, Trident Ursa continues to be successful. For all of these reasons, they remain a significant threat to Ukraine, one which Ukraine and its allies need to actively defend against.

Protections and Mitigations

The best defense against Trident Ursa is a security posture that favors prevention. We recommend that organizations implement the following measures:

  • Search network and endpoint logs for any evidence of the indicators of compromise associated with this threat group.
  • Ensure cybersecurity solutions are effectively blocking against the active infrastructure IoCs.
  • Implement a DNS security solution in order to detect and mitigate DNS requests for known C2 infrastructure. In addition, if an organization does not have a specific use case for services such as Telegram Messaging and domain lookup tools within their business environment, add these domains to the organization’s block list or do not add them to the allow list in the case of Zero Trust networks.
  • Apply additional scrutiny to all network traffic communicating with AS 197695 (Reg[.]ru).

If you think you may have been compromised 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

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.
  • Advanced URL Filtering and DNS Security identify all phishing and malware domains associated with this group as malicious.
  • Next-Generation Firewalls with an Advanced Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signature 86694.

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with the Computer Emergency Response Team of Ukraine as well as our fellow Cyber Threat Alliance members. These organizations use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors.

Indicators of Compromise

A list of the domains, IP addresses and malware hashes is available on the Unit 42 GitHub.

Additional Resources

Russia’s Gamaredon aka Primitive Bear APT Group Actively Targeting Ukraine (Updated June 22)
Ukraine in maps: Tracking the war with Russia
Russia’s New Cyberwarfare in Ukraine Is Fast, Dirty, and Relentless

Digging Inside Azure Functions: HyperV Is the Last Line of Defense

Posted on by Daniel Prizmant

Executive Summary

Unit 42 researchers investigated Azure’s serverless architecture and found that we were able to break out of the serverless function to the underlying host. We also discovered that our host was actually a HyperV virtual machine that hosted several other serverless functions.

Azure serverless functions (commonly referred to as Azure Functions) is a serverless compute service that enables users to run event-triggered code without having to provision or manage the infrastructure. Being a trigger-based service, it runs code in response to a variety of events. In the case of our research, this event was a web page request.

We found out that for each function, a new container is generated by the host. Each container will be terminated and deleted after several minutes, to differentiate serverless function from traditional containers as a service.

The host in question hosted only functions that our Azure user had access to anyway, so no real damage could be done. It is clear Microsoft went to great lengths to stop people from getting to the host, so it is possible there are other findings yet to be uncovered there. There could be important information on the virtual machine that shouldn’t be visible, which could be discovered by a sufficiently motivated attacker.

Microsoft often uses containers to strengthen security but – because containers inherently aren’t as secure as virtual machines – they usually do not treat them as a security boundary. In this case, they implemented additional layers of security, which proved to be effective.

Prisma’s serverless solution has function discovery and vulnerability scanning for most cloud providers. These features effectively put another set of eyes on the organization’s serverless functions, alerting you in case known vulnerabilities are observed in those functions.

Related Unit 42 Topics Container Escape, Serverless, Containers, Cloud Security, Azure

Technical Overview

What Are Serverless Functions

Serverless functions are a feature of serverless computing (commonly shortened to ”serverless”), where the cloud provider supplies all computing resources for its customers on demand and manages all architectures, including cloud infrastructure.

A great example of an ideal application for serverless is a chatbot. Slack, for instance, uses a serverless application called marbot to send notifications to DevOps teams through Slack.

The name “serverless” is a bit misleading. Despite what its name implies, serverless computing still requires physical servers to execute the code. The major difference from traditional computing is that serverless abstracts away anything that isn’t directly related to the code itself, from the operating system the code runs on to the hardware of the machine actually running the code.

The Internals of Serverless Functions

The first question you might be asking yourself is how one starts to research a serverless platform. Anyone who has ever used Azure Serverless Functions knows that there are not many places to poke around. You can upload some code or change a few settings, as shown in Figure 1, but that’s about it.

Image 1 is a screenshot of Azure Serverless Functions displaying form fields for different runtimes. The two sections of the field are Instance Details and Operation system.
Figure 1. All the different runtimes available through Azure Functions.

We decided to start our research with a Python function over Linux, triggered by an HTTP request. (As a side note: For some runtimes, Windows is also available.)

Our next step was to get a working interactive shell inside the function, to better understand what we are dealing with, and to get some information about the machine running our code. We decided to go with a reverse shell for ease of use. We also decided to use the data transfer tool socat (shown in Figure 2) rather than netcat, as it supports a wider range of the protocols we deemed necessary for the rest of our research.

Image 3 is a screenshot of the Visual Studio Code program showing where the code to launch the reverse shell is stored in socat.
Figure 2. The socat binary in our project, in Visual Studio Code.

We simply dropped the socat binary in our project directory in Visual Studio Code and deployed the entire thing into the serverless function that we created earlier. The code to actually launch the reverse shell was very simple, as the entire logic lies in the socat application, as shown in Figure 3.

Image 3 is a screenshot of the Visual Studio Code program showing where the code to launch the reverse shell is stored in socat.
Figure 3. Our simple function code connecting to the reverse shell listener.

Executing our reverse shell landed us inside the function directory under a user-named app. We immediately found out we were running inside a container by using the

command. The machine hostname, which started with SandboxHost (shown in Figure 4), also hinted at that.

Image 4 is a screenshot of many lines of code showing a shell inside the serverless function.
Figure 4. A shell inside the serverless function.

There was nothing too interesting in the working directory we landed in. This directory included all the files we uploaded plus one additional lib folder, which contained the necessary libraries for Python to communicate with Azure.

The Container

This research started without a specific goal in mind, other than to improve Prisma serverless protections. However, after learning more about the architecture, we were eager to break out of the container and see how deep the rabbit hole goes.

After familiarizing ourselves with the container and its files, as well as our user permissions and such, we decided to check the environment variables because they often include interesting pieces of information. This time was no different. Among other interesting things, we noted the environment variables gave away the image name (shown in Figure 5).

Image 5 is a screenshot of 3 lines of code showing environment variables displaying an image name.
Figure 5. Image name in the environment variables.

Searching this image name in Google led us to a Microsoft official catalog that listed image names, which led to an official repository that provided all of Microsoft images, including the one we were looking at.

Having the image and being able to research it locally made our life much easier. We were eager to pull the image to our local machine and start investigating it.

Our first approach was to get the image “source code” (or Dockerfile, if you’re using Docker). Surprisingly, this appeared not to be a trivial task. After some searching, we found out there is a handy utility tool called Whaler that is designed to reverse engineer Docker images into the Dockerfile that created them. Figure 6 illustrates this process.

Image 6 is 3 lines of code where the tool Whaler is used to reverse engineer a Microsoft image. Whaler reverse engineers docker images into the Dockerfile that created it.
Figure 6. Reverse engineering Microsoft image using Whaler.

There are plenty of images that wrap Whaler, resulting in a one-line command that is easy to use. Using this method, we managed to generate a good-enough version of the Dockerfile, as shown in Figure 7. The most interesting part of that file was the last line.

Image 7 is a screenshot of multiple lines of code showing how Whaler has produced a reversed Dockerfile.
Figure 7. The “reversed” Dockerfile version.

It seems like the mesh folder contains some interesting files, in particular, the launch.sh script, which seems to be the first thing executed inside the container. At this point, we simply copied the entire mesh folder from inside the image to investigate it further.

There were some more scripts in there that called some other scripts in different scenarios. The interesting part of that folder was a binary called init, which runs in the background of every Azure serverless container. Lucky for us, this binary also came packed with symbols, so reverse engineering it was a breeze.

After investigating the functions and strings lists, one function was particularly interesting: init_server_pkg_mount_BindMount (shown in Figures 8a and 8b). After reverse engineering it, we discovered that this function binds a path inside the container to another path, which is also inside the container. This function also doesn’t require the user to be privileged, but it runs in the context of root! All you would need to do to bind one file to any other file, is to perform an HTTP query inside the container on the correct port, with the correct arguments.

Image 8a is a screenshot of three lines of code showing the signature of the function init_server_pkg_mount_BindMount.
Figure 8a. The init_server_pkg_mount_BindMount function signature.
Image 8b is a screenshot of multiple lines of code demonstrating how the function init_server_pkg_mount_BindMount parses sourcePath and targetPath from an HTTP request.
Figure 8b. The init_server_pkg_mount_BindMount function parses sourcePath and targetPath from the HTTP request.

In the process of this part of the investigation, we also discovered a lot of information about how Azure serverless architecture works behind the scenes. While this is outside the scope of this article, it would be possible to explore this matter in depth in its own article.

Escalating Privileges

To quickly recap, at this point in the research we were inside a container with an unprivileged user, but we had the ability to bind any one file to any other file as root. Our goal at this point was to escalate privileges to root, inside the container. There are probably several ways to achieve this, but we chose to replace the /etc/shadow file with the one we generated (shown in Figure 9), and then to change the user to root.

Image 9 is a screenshot of a few lines of code demonstrating how we generated /etc/shadow using OpenSSL.
Figure 9. Generating /etc/shadow using OpenSSL.

To accomplish this, we performed the following steps (also shown in Figure 10):

  1. Generated an /etc/shadow file with a known password for the root user.
  2. Uploaded said file to our local directory in the Function container.
  3. Used the running init service and the BindMount function to bind our local shadow file to the actual /etc/shadow file by querying http://localhost:6060.
  4. Changed user to root using the su - root command.
Image 10 is a screenshot of several lines of code demonstrating how privileges were escalated by binding the local shadow file to the actual /etc/shadow file with a query.
Figure 10. Escalating privileges.

Escaping the Container: I Am Root

The next step in our escape was to leverage our newly achieved root access to break out of the container. We chose to use an old exploit that was discovered by Felix Wilhelm years ago.


Figure 11. Breaking out of the container PoC.

Using this exploit is not trivial, and there are several requirements that need to be met in order for it to work:

  • We must be running as root inside the container.
  • The container needs to have SYS_ADMIN capability.
  • The container must either not have an AppArmor profile or allow the mount syscall.
  • The cgroup v1 virtual filesystem must be mounted read-write inside the container.

We had already achieved the first requirement earlier. Surprisingly, the rest of the requirements were also available in our container. This was surprising because, by default, Docker containers are launched with a restricted set of capabilities and do not have the SYS_ADMIN capability enabled. Furthermore, Docker usually starts containers with AppArmor policy by default, which prevents the use of the mount syscall even when the container is run with SYS_ADMIN. We confirmed we have all the necessary capabilities by running the capsh command on our shell status file under /proc/PID/status, as shown in Figure 12.

Image 12 is screenshots of several lines of code where capsh is run with sed scripting to confirm privileged user capabilities.
Figure 12. Using capsh with some sed scripting to print our privileged user capabilities.

As a detailed explanation of this exploit is slightly outside the scope of this blog, we recommend reading "Digging into cgroups Escape" to get a better understanding of this technique. In short, we’ll describe the exploit with the following steps:

  1. Find or create access to a cgroup controller (most versions of the exploit use RDMA).
  2. Create a new cgroup within that controller.
  3. Set notify_on_release for that cgroup to 1.
  4. Set the release agent to a file accessible from both the container and host.
  5. Start a quickly completing process within that cgroup that will trigger execution of the release agent on termination.

We decided to demonstrate achieving host execution context by running ps aux and comparing it to the container’s ps aux. In the video at the beginning of this section, you can see the entire exploit from start to finish in action. It is important to note that the machine hosting our container was a HyperV virtual machine and not a physical server.

Possible Impact and Conclusions

All the resources the virtual machine hosted were accessible by our Azure’s user regardless, so in that regard this escape had no actual immediate impact. This is an example of cloud providers' mitigations working as intended. In this case, their choice of not relying on the container as a security boundary plus implementing another line of defense proved to be a smart move.

However, this issue could have a huge impact if (for example) another vulnerability in the virtual machine itself is found. Furthermore, Microsoft is known to have fixed similar issues in the past, even if they’ve not called them vulnerabilities per se.

We felt like this was a good place to stop the research and post our findings, rather than investigating the virtual machine thoroughly. It is possible that the virtual machine contains important information or secrets that shouldn’t be visible to the serverless function user, or to a possible attacker. We are certain that other researchers in the cloud community would take it from here and investigate further, until Microsoft patches this issue.

After sharing our findings with Microsoft, they have taken the following defense-in-depth measures into consideration to better protect customers:

  1. Additional validation for bind mount APIs to prevent mounting over.
  2. Removing symbols from binaries where possible.

Appendix: Prisma’s Solution

Prisma’s serverless solution has function discovery and vulnerability scanning for most cloud providers. These features implement another set of eyes for the organization’s serverless functions, and they will alert in case of known vulnerabilities in those functions.

For AWS specifically, Prisma also offers deep visibility with Prisma’s Serverless Radar, compliance and detection of over-privileged roles, and serverless WAAS.

Furthermore, Prisma’s Serverless Defender also protects serverless functions at runtime. It monitors the customer’s functions to ensure they execute as designed. Per-function policies let the customer control the following:

  • Process activity – Enables verification of launched subprocesses against policy.
  • Network connections – Enables verification of inbound and outbound connections and permits outbound connections to explicitly allowed domains.
  • File system activity – Controls which parts of the file system functions can access.

Currently, Prisma Cloud supports AWS Lambda functions (Linux) and Azure Functions (Windows only).

The following runtimes are supported for AWS Lambda:

  • C# (.NET Core) 3.1
  • Java 8, 11
  • Node.js 12.x, 14.x
  • Python 3.6, 3.7, 3.8, 3.9
  • Ruby 2.7

The following runtimes are supported for Azure Functions (Windows only):

  • v3 - C# (.NET Core) 3.1, 5.0
  • v4 - C# (.NET Core) 4.8, 6.0
Image 13 is a screenshot of Prisma Cloud demonstrating how to enable serverless function defenses in the software.
Figure 13. Enabling serverless function defenses on Prisma.

Precious Gemstones: The New Generation of Kerberos Attacks

Posted on by Samantha Stallings

Executive Summary

Unit 42 researchers show new detection methods that help improve detection of a new line of Kerberos attacks, which allow attackers to modify Kerberos tickets to maintain privileged access. The most well-known example of this is the Golden Ticket attack, which allows threat actors to forge a ticket to masquerade as a high-privileged user.

These two newer attacks extend the Golden Ticket attack in that the forged tickets are not created from scratch, but instead based on modifying an existing ticket to include high-privileged access. We’ll discuss the difference between these three types of attacks, to explain why the newer ones are harder to detect.

The broad usage of Active Directory has made Kerberos attacks the bread and butter of many threat actors. Researchers have discovered the following new attack techniques that allow an adversary to gain unconstrained access to all services and resources within an Active Directory (AD) domain:

  • Diamond Ticket
  • Sapphire Ticket

Because of their similarity to the well-known Golden Ticket attack, threat actors might also use these attacks in future campaigns. People can better protect themselves by employing the new detection methods we’ll discuss for these new Kerberos attacks.

Palo Alto Networks customers receive improved detection for the attacks discussed in this blog through Cortex XDR.

Related Unit 42 Topics privilege escalation, Golden Ticket, Kerberos

Kerberos Refresher

To understand the ticket attacks and their implications, it helps to understand a few things about how Kerberos works. This includes some common terms for features used in these attacks, as well as the structure of how tickets are used.

Kerberos is a network authentication protocol that is primarily used in Active Directory (AD) environments. Thousands of companies across different industries use Active Directory technology for managing user accounts and other resources within an organization. Active Directory’s first version was released in Windows Server 2000 and since then, it has become particularly common in businesses and other large organizations that have a significant number of users and resources to manage.

Kerberos provides strong authentication by issuing tickets to authenticate users and allow access to services. The tickets are distributed by the key distribution center (KDC). In most environments, the KDC is installed on the domain controller (DC).

During the initial authentication, a Ticket Granting Ticket (TGT) is a ticket assigned to a user. The TGT is later used to authenticate the user to the KDC and request a service ticket from the Ticket Granting Service (TGS). Service tickets are granted for authentication against services.

A Kerberos authentication would consist of the following steps:

  1. The user requests (AS-REQ) a TGT from the KDC and the KDC verifies and validates the credentials and user information.
  2. After authenticating the user, the KDC sends an encrypted TGT back to the requester (AS-REP).
  3. The user presents the TGT to the DC and requests a TGS (TGS-REQ).
  4. The TGS is encrypted and sent back to the requesting user (TGS-REP).
  5. The user connects to the server hosting the service requested and presents the TGS (AP-REQ) in order to access the service.
  6. The application server sends an (AP-REP) to the client.
Image 1 shows the request flow between the user workstation, the domain controller, and the application server for Kerberos authentication
Figure 1. Kerberos authentication.

What Components Are in a Kerberos Ticket?

Each Kerberos ticket contains the following fields:

Kerberos Ticket
Tkt-vno Version number for the ticket format.
Realm The realm that issued a ticket.
sname Server name. All the components of the name are part of the server's

identity.
Enc-part Encrypted with the server's secret key.

Table 1. Kerberos ticket.

The enc-part contains different fields but we will focus on the following:

  1. cname – The name part of the client's principal identifier.
  2. authorization-data – used to pass authorization data from the principal on whose behalf a ticket was issued to the application service. This part includes the Privileged Attribute Certificate (PAC).

What Is a Kerberos Privilege Attribute Certificate (PAC)?

As Microsoft’s documentation states, the PAC is a structure that conveys authorization-related information provided by DCs. The PAC is used by authentication protocols that verify identities to transport authorization information, which controls access to resources.

The DC includes authorization data such as security identifiers (SIDs) and relative identifiers (RIDs) in the PAC.

Kerberos Delegation

A common use case for Kerberos delegation is a web server fetching user data from a database server. The database server can grant access to the user data only for the user. In this scenario, the web server will need to impersonate the user. This impersonation is called Kerberos delegation.

We will focus on constrained delegation in this blog, but you can read about the different Kerberos delegation methods in Protecting Against the Bronze Bit Vulnerability with Cortex XDR.

Constrained Delegation: Microsoft has implemented Kerberos extensions in order to avoid keeping the user’s TGT in memory. This extension is called S4U (Service for User), and it consists of S4U2Self and S4U2Proxy. S4U2Self allows a service to ask for a ticket to itself on behalf of any user. S4U2Proxy will allow a service to authenticate to a different service.

S4U2Self Extension

As described above, the S4U2self extension allows a service to receive the user’s authorization data in the ticket (i.e., the PAC).

To use this protocol extension, the user that issues the KRB_TGS_REQ must have at least one Service Principal Name (SPN) to allow the DC to encrypt the generated service ticket with the service secret key.

S4U2U KRB_TGS exchange flow:

  1. The service fills out the PA_FOR_USER data structure, which contains the information about the user on whose behalf the service requests the service ticket, and sends the KRB_TGS_REQ message to the TGS.
  2. The service ticket will be sent back to the service via KRB_TGS_REQ message. The PAC returned in the service ticket contains the authorization data.

U2U Authentication

User-to-User authentication is described in the Kerberos RFC as a method that “allows the client to request that the ticket issued by the KDC be encrypted using a session key from a TGT issued to the party that will verify the authentication.”

The KRB_TGS_REQ will have the following features:

  • additional-tickets: will contain the TGT from which the secret-key is taken
  • ENC-TKT-IN-SKEY: option indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided.
  • The service name (sname) can refer to a user and not necessarily a service with SPN.

U2U + S4U2Self

Combining the two methods together allows using the S4U2Self extension for users with no SPN. The service ticket received in this exchange is encrypted with the server’s secret-key (in this specific case the server can be a user with no SPN), therefore, the PAC of the target user can be decrypted using the server’s secret-key.

The KRB_TGS_REQ packet will have all the features of both methods.

How Do These Kerberos Attacks Work?

Both the Sapphire and Diamond Ticket attacks decrypt a legitimate TGT and change its PAC, and in order to do that, the adversary needs to have access to the KRBTGT account’s key (the password hash). The KRBTGT account, as described by Microsoft TechNet (now Microsoft Docs), is a local default account that acts as a service account for the KDC service.

Sapphire Ticket

The Sapphire ticket attack (introduced by Charlie Bromberg), requires getting credentials of any user in the domain. Let's call that user Joe. Joe’s credentials will be used to obtain a TGT (using a regular KRB_AS_REQ) and later to decrypt the PAC of a high-privileged user.

Once the TGT is received, the adversary will use the U2U + S4U2Self:

  1. Decide on the user they want to impersonate (high-privileged user)
  2. Generate a KRB_TGS_REQ with the following attributes:
    1. The PA_FOR_USER struct contains the impersonated user
    2. The service name (sname) is Joe’s username
    3. Joe’s TGT will be added to the additional-tickets field
    4. ENC-TKT-IN-SKEY flag in the KDC Option is set
  3. Obtain a service ticket for the impersonated user

KRB_TGS_REQ -

Image 2 is many lines of code and shows how to generate KRB_TGS_REQ using U2U + S4U2Self with a user named Joe.2 and
Figure 2. KRB_TGS_REQ created using U2U + S4U2Self methods.
Image 3 is many lines of code where the user named Joe begins to set configuration options.
Figure 3. ENC-TKT-IN-SKEY flag is set in the KDC Option.

KRB_TGS_REP

Image 4 is a few lines of code continuing to show how a user named Joe continues to set configuration options through the process.
Figure 4. U2U + S4U2Self TGS-REP.

As we know, a service ticket is encrypted with the service’s long-term secret, which means that if the adversary has Joe’s credentials, they will be able to decrypt the service ticket. The adversary also has the KRBTGT account’s secret key and therefore they can decrypt and modify Joe’s TGT, which is signed with said secret key.

To forge the Sapphire Ticket, the attacker will extract the PAC of the impersonated user, and modify Joe’s TGT in 2 ways:

  1. Replace Joe’s original PAC with the high-privileged PAC.
  2. Match the cname to be the impersonated user’s name.

This gives the attacker a usable TGT of a high-privileged user.

Diamond Ticket

The first part of the Diamond Ticket attack (introduced by Charlie Clark and Andrew Schwartz) is obtaining a TGT. This can be done by using one of the following techniques:

Once receiving the TGT in the KRB_AS_REP, the adversary can now decrypt the TGT using the KRBTGT account’s key and modify each part of the ticket.

After modifying the ticket, an attacker can escalate their privileges using one of the following approaches:

  • Generating a TGT to impersonate a domain admin or any other user in the domain.

In this scenario the attacker will need to change the cname field in the ticket as well as the PAC. This method will result in a forged ticket under the name of the domain admin (or any other user in the domain), which is pretty similar to the Golden Ticket attack.

  • Elevating a normal domain user’s privileges to domain admin privileges by modifying the PAC.

This method will supply the attacker with a ticket under the name of the low-privileged user with domain admin permissions.

How Powerful Are the New Kerberos Attacks?

Diamond and Sapphire Tickets are forged TGTs created by modifying a legitimate TGT, which gives it additional privileges or a new identity. While many Golden Ticket detections are based on the absence of a TGT creation by a legitimate DC, the new attacks manipulate a legitimate TGT that was issued by the DC, which makes them harder to detect.

After the TGT is forged, the attacker uses it to request a TGS to any service or resource they desire. For example, they can request access to all computers, files and folders in the domain.

What’s the Difference Between a Diamond Ticket and a Sapphire Ticket Attack?

In both attacks, the manipulation happens on the PAC of a legitimate TGT, but the main difference is in the way it is modified. With a Diamond Ticket, the modification is to the original PAC of the requested TGT, by adding additional privileges or modifying it completely. With a Sapphire Ticket, the attacker modifies the TGT by getting a legitimate PAC of a high-privileged user using Kerberos delegation, and replaces it with the original ticket’s PAC.

Can Anyone Forge TGTs?

In order to perform such an attack, the basic requirement is that the adversary needs access to the KRBTGT account’s password hash.

The KRBTGT account encrypts and signs all the Kerberos TGT tickets for the domain. All verification of Kerberos tickets, including encrypting and decrypting TGTs for the KDC service, is done by the KRBTGT. This means a forged TGT will be considered a valid ticket simply because it was encrypted with the KRBTGT account.

Moreover, the adversary has to encrypt the forged TGT with the KRBTGT password hash once the TGT is forged, to make sure the new TGT will pass the KDC’s verification and issue a service ticket to the desired service.

With that being said, it’s important to remember that getting the KRBTGT password hash is not an easy task. Doing so not only provides access to all the services and resources in the domain, but also enables network persistence.

Forged Ticket Attacks in the Wild

Forged ticket attacks have been sighted in the wild, such as in attacks by Playful Taurus, also known as APT15, Ke3chang and NICKEL. This group is attributed to actors operating out of China and has targeted oil, government, diplomatic, military and non-governmental organizations around the world since 2010.

An investigation done by NCC Group’s IR team in May 2017 states that, to gain persistence in the victim’s network in the event of remediation actions being undertaken, Playful Taurus used Mimikatz to dump credentials and generate Kerberos Golden Tickets.

In a different campaign around December 2021, MSTIC found that the same threat actor used malicious tools such as Mimikatz, WDigest, NTDSDump, and other password-dumping tools to gather credentials on a targeted system.

Mimikatz allows attackers to perform the following activities:

These simulate the Active Directory replication process and retrieve the user’s password hash. They can be used to collect the KRBTGT password hash.

  • Forge a Golden Ticket

Our assumption is that – because Sapphire and Diamond Ticket attacks resemble Golden Ticket attacks but are harder to discover – different threat actors (like Playful Taurus) are likely to use these attacks in the future.

Proposing Detection Methods for Forged Ticket Attacks

Due to the difficulty of finding the KRBTGT password hash, these attacks would probably cause a lot of noise even before the attack took place. In this case, the detection ideas that apply to Golden Ticket attacks are relevant here as well.

If you want to read more about such detections, check out our blog, Detecting and Preventing the Path to a Golden Ticket With Cortex XDR.

Sapphire Ticket

Since the Sapphire Ticket should appear valid (i.e., a ticket with a legitimate PAC), we would have a difficult time detecting its utilization solely by analyzing it. However, we can detect other suspicious activities on the host:

  • Signs of KRBTGT password hash theft
  • Suspicious tools usage
  • DCSync attacks in the environment or suspicious connections from the host to a DC
  • Irregular KRB_TGS_REQ with U2U + S4U2Self attributes
  • KRB_TGS_REQ by a high-privileged user from that host

If the adversary uses the ticket right after performing the attack, we will observe a TGT request and TGS from the same IP for two different users. There would be no indication for the second user’s (i.e., the one that appears in the TGS request) authentication to that machine. This can be monitored by Windows Event 4768 and 4769 as well as network traffic.

Image 5 is a screenshot of a TGT request by a low-privileged user with the account name for user Joe highlighted. The Client Address is also highlighted.
Figure 5. TGT request by low-privileged user.
Image 6 is a screenshot of a TGT request by a high-privileged user with the account name and client address highlighted.
Figure 6. TGS request by high-privileged user.

Diamond Ticket

Generating a Ticket for Domain Admin Account

The detection here is pretty similar to any Golden Ticket detector or the suggested Sapphire Ticket detector.

Elevating Normal Domain User’s Privileges

If the adversary uses this technique, it will look like legitimate authentication. The TGT and TGS requests will be for the same user, and the suggested detectors won’t be relevant.

This activity can be monitored by looking for anomalies in both the number of resources being accessed and what resources the user accessed. Attackers will likely be accessing high-privileged resources, so this activity will be new. Anomaly detection can be tricky in big environments and can cause distraction rather than finding an attack.

It’s important to note that the main difference between Diamond Ticket and Sapphire Ticket is that a Sapphire Ticket has an actual PAC of a real high-privileged user. In Diamond Ticket and Golden Ticket attacks, the PAC is modified by the attacker, and might therefore be inaccurate. This information can be used to detect these attacks.

Group Membership Detection

To make this detection method more approachable, let me introduce you to Windows event 4627(S): Group membership information. This event is generated with Windows event “4624(S): An account was successfully logged on,” and it shows the list of groups that the logged-on account belongs to.

Image 7 is a screenshot of Windows Event 4627. The window title is "Event Properties - Event 4627, Microsoft Windows security auditing."
Figure 7. Windows Event 4627.

Source - Microsoft

This requires OS Version Windows Server 2016, Windows 10 and above. To enable it, you must enable the Success Audit for the Audit Logon subcategory.

Monitoring this event will allow you to discover irregularities in the user’s group memberships. When an attacker wants to assign domain admin privileges to a forged ticket, they add the domain admin rid (512) to the PAC. Thus, during the login, it appears the user is part of the domain admins.

An example of this would be using Diamond Ticket attacks to elevate a low-privileged user (we’ll continue to use “Joe”) to domain admin privileges, as shown in Figures 8 and 9.

Image 8 is a screenshot of how low-privileged users appear in Windows Event 4627. Highlighted is Joe's name along with Joe's membership access as a domain admin.
Figure 8. Low-privileged user appears in domain admin.
Image 9 is a screenshot of the Domain Admins Properties window showing that Joe is not a member listed in the Members tab.
Figure 9. Joe is not a member of domain admins.

It is worth noting that, if an adversary impersonates a high-privileged user using a forged TGT, they might assign the wrong group membership. Therefore, it is worth paying attention to those as well.

To avoid false positives (when a user is intentionally added to a high-privileged group), event 4627 can be correlated with Windows events 4732 and 4728, which indicate when a user is added to a group.

Conclusion

In this blog, after a brief primer on relevant Kerberos terms and the attacks themselves, we discussed the privileges required to perform such attacks and the importance of monitoring different forged ticket attacks. Additionally, we examined possible detection ideas that might help cover Golden Ticket attacks as well as new attack methods.

Forged ticket attacks might be hard to detect with a cursory glance, since they can initially appear to be legitimate. However, if enough information is collected about suspicious network activity, malicious tool usage, or Windows events, we might be able to detect some of the most effective Kerberos attacks.

In addition, deploying a security platform such as Cortex XDR can provide an additional layer of protection and visibility to the various stages of the attack.

Additional Resources

Detecting and Preventing the Path to a Golden Ticket With Cortex XDR - Palo Alto Networks
Protecting Against the Bronze Bit Vulnerability with Cortex XDR - Palo Alto Networks
The Essential Guide to XDR - Palo Alto Networks
Understanding Microsoft Kerberos PAC Validation - Microsoft
The Kerberos Network Authentication Service (V5) - MIT
A Diamond (Ticket) in the Ruff - Semperis

Appendix: Glossary

Constrained delegation – Provides a safer form of delegation that could be used by services. When it is configured, constrained delegation restricts the services to which the specified server can act on the behalf of a user.

DCSync Attack – Abusing a Windows Domain Controller's application programming interface (API) to simulate the replication process from a remote domain controller.

Domain controller (DC) – A server computer that responds to security authentication requests within a computer network domain. It is a network server that is responsible for allowing host access to domain resources. Serves as the KDC in AD environments.

ENC-TKT-IN-SKEY – The option indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided.

Golden Ticket attack – Adversaries who have the KRBTGT account password hash may forge Kerberos ticket-granting tickets (TGT) called “Golden ticket” which enable adversaries to generate authentication material for any account in Active Directory.

Kerberos – Kerberos is a network authentication protocol that is primarily used in Active Directory environments.

Kerberos delegation – Kerberos delegation is a delegation setting that allows applications to request end-user access credentials to access resources on behalf of the originating user.

Key Distribution Center (KDC) – A key distribution center (KDC) in cryptography is a system that is responsible for providing keys to the users in a network that shares sensitive or private data.

KRBTGT account – A local default account that acts as a service account for the KDC service.

PA-FOR-USER – A struct used to identify the user, on whose behalf the service requests the service ticket, using the user name and user realm.

Privileged Attribute Certificate (PAC) – The PAC is a structure that conveys authorization-related information provided by domain controllers (DCs). The PAC is used by authentication protocols that verify identities to transport authorization information, which controls access to resources.

S4U – Kerberos extensions in order to avoid keeping the user’s TGT in memory. It consists of S4U2Self and S4U2Proxy.

S4U2Proxy – Will allow a service to authenticate to a different service.

S4U2Self – Allows a service to ask for a ticket to itself on behalf of any user.

Service Principal Names (SPN) – A unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account.

Ticket Granting Server (TGS) – A TGS validates the use of a ticket for a specified purpose, such as network service access.

Ticket Granting Ticket (TGT) – A user authentication token issued by the KDC that is used to request access tokens from the Ticket Granting Service (TGS) for specific resources/systems joined to the domain.

U2U authentication – A method to perform authentication when the verifier does not have access to a long-term service key. To address this problem, the Kerberos protocol allows the client to request that the ticket issued by the KDC be encrypted using a session key from a TGT issued to the party that will verify the authentication.

Updated December 13, 2022, at 8:25 a.m. PT. 

Compromised Cloud Compute Credentials: Case Studies From the Wild

Posted on by Samantha Stallings

Executive Summary

Cloud breaches often stem from misconfigured storage services or exposed credentials. A growing trend of attacks specifically targets cloud compute services to steal associated credentials and illicitly gain access to cloud infrastructure. These attacks could cost targeted organizations both in terms of unexpected charges for extra cloud resources added by the threat actor, as well as time required to remediate the damage.

This blog highlights two examples of cloud compute credentials attacks in the wild. While the initial access phase is important, we will focus on the post-breach actions executed during the attack, and share the flow of these two attacks against the cloud infrastructure. The attack flows show how threat actors abuse stolen compute credentials to pursue a variety of attack vectors (such as cryptomining, data theft, etc.) and abuse cloud services in unexpected ways.

To detect the attacks described below, cloud logging and monitoring best practices as outlined by Amazon Web Services (AWS) and Google Cloud are essential, as they provide visibility into activity at the cloud infrastructure level. This emphasizes how important it is to follow Amazon Web Services and Google Cloud logging and monitoring best practices.

Palo Alto Networks helps organizations address security issues in the cloud with Cortex XDR for cloud, which detects cloud attacks such as cloud compute credentials theft and Prisma Cloud, which manages identity entitlement with least privilege entitlements.

Related Unit 42 Topics Cloud, phishing, cloud security, coin miner

Key Principle of Working in the Cloud

Before diving in, we should understand a very basic and important rule of working in the cloud. An entity, whether a human or a compute workload, needs legitimate and associated credentials to access a cloud environment at the infrastructure level. The credentials are used for authentication (to verify the entity’s identity) and authorization (to verify what the entity is allowed to do).

As a best practice, when a compute workload executes API calls in the cloud (e.g., to query a storage service), the workload’s associated credentials should be dedicated only to it. They should also be used only by that workload or human, and not by anyone else.

As we will see in both examples, an important security principle that can help reduce risk in cloud compute credentials attacks is least privilege access. In particular, this means that the privileges associated with those credentials should be scoped down to the minimum set actually required by the code using them.This limits the actions an attacker can take when compute credentials are stolen.

Attack Case 1: Compromised AWS Lambda Credentials Led to Phishing Attack

An attacker was able to execute API calls on the behalf of the Lambda function by stealing the Lambda’s credentials. This allowed the attacker to execute multiple API calls and enumerate different services in the cloud environment, as shown in Figure 1. While most of these API calls were not allowed due to lack of privileges, the attack resulted in a phishing attack launched from a AWS Simple Email Service (SES) that the threat actor created.

Image 1 is a screenshot of Amazon Web Services showing a branch diagram of an attacker impersonating a Lambda function by stealing the Lambda’s token inside the cloud environment.
Figure 1. An attacker enumerating the cloud environment using a compromised Lambda function’s credentials.

This phishing attack not only resulted in unexpected costs for the organization, it also exposed other organizations to extra risk as well.

While the outcome of this attack caused substantial impact, it could have been greater. In this case the victim didn’t have an active SES, but if they had, the attacker could have abused it to launch an attack on the victim’s organization or they could even have used a legitimate email account for the phishing attack.

Due to the variety of cloud services used by organizations, it can be difficult to predict where a cloud attack will end. Going from cloud to phishing was not necessarily an expected path.

Attack Flow

An attacker was able to exfiltrate the Lambda’s environment variables and export them into their attacking machine (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN).

As the credentials were exfiltrated, the attack was launched with the following steps:

> WHOAMI - 2022-05-20T20:35:49 UTC

The attack started with the GetCallerIdentity command. This command is equivalent to whoami, as it provides information about the entity the credentials are associated with. From the response, the attacker can gain additional information such as the account ID and the credentials type that was stolen. They cannot, however, determine anything about the privileges associated with the identity.

> Identify and Access Management (IAM) Enumeration - 2022-05-20T20:35:55 UTC

The next phase of the attack was an identity and access management (IAM) enumeration. IAM is considered to be a crown jewel for an attack. By gaining access to IAM, an attacker can elevate permissions and gain persistence on the victim’s account.

The IAM enumeration included two API calls, which were denied due to lack of permissions:

  • ListAttachedRolePolicies
  • ListRolePolicies

It is fair to assume that the attacker noticed the lack of permission and therefore terminated the IAM enumeration after only two commands (possibly to avoid making unnecessary noise).

> General Enumeration 2022-05-20T20:39:59 UTC

After failing to enumerate IAM, the attacker started an enumeration on different services in different regions. This technique is much noisier as the attacker is trying to learn the architecture of the targeted account and, more importantly, gain access to sensitive information that could exist in the cloud account.

Some of the main services and API calls that were executed were:

Storage Enumeration

  • ListBuckets
  • GetBucketCors
  • GetBucketInventoryConfiguration
  • GetBucketPublicAccessBlock
  • GetBucketMetricsConfiguration
  • GetBucketPolicy
  • GetBucketTagging

EC2 Enumeration

  • GetConsoleScreenshot
  • GetLaunchTemplateData
  • DescribeInstanceTypes
  • DescribeBundleTasks
  • DescribeInstanceAttribute
  • DescribeReplaceRootVolumeTasks

Network Enumeration

  • DescribeCarrierGateways
  • DescribeVpcEndpointConnectionNotifications
  • DescribeTransitGatewayMulticastDomains
  • DescribeClientVpnRoutes
  • DescribeDhcpOptions
  • GetTransitGatewayRouteTableAssociations

Logging Enumeration

  • GetQueryResults
  • GetBucketLogging
  • GetLogRecord
  • GetFlowLogsIntegrationTemplate
  • DescribeLogGroups
  • DescribeLogStreams
  • DescribeFlowLogs
  • DescribeSubscriptionFilters
  • ListTagsLogGroup

Backup Enumeration

  • GetPasswordData
  • GetEbsEncryptionByDefault
  • GetEbsDefaultKmsKeyId
  • GetBucketReplication
  • DescribeVolumes
  • DescribeVolumesModifications
  • DescribeSnapshotAttribute
  • DescribeSnapshotTierStatus
  • DescribeImages

SES Enumeration

  • GetAccount
  • ListIdentities

General Enumeration

  • DescribeRegions
  • DescribeAvailabilityZones
  • DescribeAccountAttributes

> Backdoor 2022-05-20T20:43:22 UTC

While failing to enumerate IAM, the attacker tried (unsuccessfully) to create a new user by executing the CreateUser command.

> From the Cloud to a Phishing Attack 2022-05-20T20:44:40 UTC

As most of the API calls during the enumeration resulted in permission denied, the attacker was able to successfully enumerate SES. Therefore, the attacker launched a phishing attack by abusing the cloud email service, which included executing commands such as VerifyEmailIdentity and UpdateAccountSendingEnabled.

> Defense Evasion 2022-05-20T23:07:06 UTC

Finally, the attacker tried to hide some of his activities by deleting the SES identity by executing the DeleteIdentity command.

Additional Insights for Detection

A very important indicator of compromise (IoC) for this attack was the IP address 50.82.94[.]112.

API calls from the Lambda function are typically executed from its IP with the credentials (including AccessKeyId) that were generated for the Lambda. Therefore, every API call with that AccessKeyId is considered to be the Lambda function. However, during the attack, the threat actor was able to steal the Lambda's credentials, allowing the attacker to impersonate it.

Because of this, the IP is the key IoC as it is the way to detect that this is not the Lambda. The attacker was using the stolen credentials to impersonate and execute API calls on behalf of the Lambda function, but they were doing so from an IP address that wasn't attached to the Lambda, nor did it belong to the cloud environment.

Attack Case 2: A Compromised Google Cloud App Engine Service Account Deploying Cryptomining Instances

An attacker was able to steal the credentials for a Google Cloud App Engine service account (SA). There are many ways that attackers can accomplish this that are not necessarily related to any vulnerability in the cloud service provider. In many cases, for example, users store credentials in insecure locations or use easily guessed or brute-forced passwords.

In this case, the stolen SA was the default SA, which had a highly privileged role (Project Editor). This allowed the threat actor to launch an attack that ended with the creation of multiple high-core CPU virtual machines (VMs) for cryptomining purposes, as shown in Figure 2.

Image 2 is a screenshot of an attacker using a compromised app engine service account to find multiple cloud instances to mine.
Figure 2. An attacker abusing a compromised App Engine SA to allocate multiple cloud instances for mining.

When the threat actor launched thousands of VMs in the victim’s environment, it significantly increased their expected costs. Even if someone had noticed an attack like this in their environment after a short period of time, it would still have had a substantial cost impact.

Attack Flow

Google App Engine is a Google Cloud fully managed serverless platform, and the service account is the token. When the user creates an App Engine instance, the cloud provider creates a default SA and attaches it to the created App Engine.

This App Engine default SA has the editor role in the project. The editor role is highly privileged, which is a key factor the attacker took advantage of. This role allowed execution of high-privilege API calls, such as the following:

  • Compute workload launch
  • Firewall (FW) rule modification
  • SA key creation

> Privilege Escalation 2022-06-16T12:21:17.624 UTC

The attack started with an attempt to escalate privileges. As mentioned above, by default the App Engine’s SA has editor permissions on the project. With these permissions, the attacker tried to add the compute/admin role by adding the following object into the IAM policy:

Image 3 is a screenshot of 3 lines of code where the threat actor adds an object into the IAM policy in order to add an admin role.

As we can see, the appspot in the SA domain prefix indicates this SA belongs to an App Engine service.

> Allow Any/Any 2022-06-16T12:21:29.406 UTC

Next the attacker modified the FW rules on the project level. First, the attacker attempted to create a subnet (named default). Then, the attacker added the rule below into that subnet:

Image 4 is a screenshot of 12 lines of code where the threat actor has tried to create a subnet named “default” and is now adding a rule below that in the subnet to allow for cryptocurrency mining.

This action furthers the attacker’s goal of mining cryptocurrency. To enable unlimited cryptocurrency mining, the attacker removed any limitation on the networking level.

It is important to note the priority field. By setting this to zero, the attacker’s rule is set to the highest priority, meaning it will take effect first in the order of the existing FW rules.

> An Army of Miners 2022-06-16T12:21:38.916 UTC

Once setup was complete, the main phase of the attack began, launching VMs in multiple regions.

While the attacker could have created high CPU machines, in this case the attacker instead created a standard VM (e.g., n1-standard-2) equipped with four high performance GPUs (e.g., nvidia-tesla-p100):

Image 5 is a screenshot of many lines of code demonstrating how the threat actor created standard virtual machines, creating more than 1,600 in total.

Overall, more than 1,600 VMs were created during this attack.

> Backdoor 2022-06-16T13:25:56.037 UTC

The attacker assumed the SA key used for the attack would be detected and revoked, and therefore created multiple SA keys (for later usage) by executing the google.iam.admin.v1.CreateServiceAccountKey API call.

Additional Insights for Detection

As in the first case we discussed, the IP is an important IoC. In this case, the attack was launched from multiple IPs (nine different IPs overall), some of which were active Tor exit nodes.

Again, we expect the App Engine’s SA to be used from an IP within the cloud environment. It definitely should not be used from a Tor exit node.

Firewall rule modification is a common and popular technique used in attacks like these. Many organizations enforce network traffic rules that deny access to active mining pools, so attackers must modify firewall rules to accomplish their goals.

Lastly, by editing a network named default, the attacker tried to avoid detection. Unless this option is disabled, by default each new project is created with a default network. It seems the attacker was trying to take advantage of this, thus avoiding having to create their own network.

Conclusion: Compute Token Theft Is a Growing Threat

The theft of a compute workload’s token is the common denominator for both cases we’ve discussed. While both examples above involve serverless services, this attack vector is relevant to all compute services.

It is important to emphasize that this type of attack could occur from different attack paths – including application vulnerabilities or zero-day exploits such as Log4Shell – not only from misconfigurations or poor cloud security posture management (CSPM).

To handle such attacks, cloud audit logs are essential, both for detection and for investigation and response (IR). Cloud audit monitoring is even more critical for serverless workloads where agents cannot be installed, thus making it harder to stop such attacks.

Logging and monitoring best practices provided by AWS and Google Cloud give clear guidance for how to prevent such cases. The AWS GuardDuty service could also help with detecting and alerting on similar attacks, such as EC2 instance credentials used from another AWS account. An additional prevention method is to configure an interface endpoint policy for Lambda to limit the usage of Lambda only within a VPC.

Palo Alto Networks customers receive protections from compute token theft with:

  • Cortex XDR for cloud, which provides SOC teams with a full incident story across the entire digital domain by integrating activity from cloud hosts, cloud traffic, and audit logs together with endpoint and network data.
  • Prisma Cloud, which assists organizations in managing identity entitlement, addresses the security challenges of managing IAM in cloud environments. Prisma Cloud IAM security capabilities automatically calculate effective permissions across cloud service providers, detect overly permissive access, and suggest corrections to reach least privilege entitlements.

Find out how you can protect your organization from cloud environment attacks with Unit 42 Cloud Incident Response services to investigate and respond to attacks and Cyber Risk Management Services to assess your security posture before an attack takes place.

Learn How to Detect Cloud Threats at Ignite ’22
Attend the session “Unearth advanced threats using your network and cloud data,” at Palo Alto Networks Ignite ’22, the security conference of the future, to find out how to detect compromised cloud compute tokens. Our researchers will show you how to investigate and respond to cloud attacks with a live demonstration. Register now!

Vice Society: Profiling a Persistent Threat to the Education Sector

Posted on by Samantha Stallings

Executive Summary

Vice Society is a ransomware gang that has been involved in high-profile activity against schools this year. Unlike many other ransomware groups such as LockBit that follow a typical ransomware-as-a-service (RaaS) model, Vice Society’s operations are different in that they’ve been known for using forks of pre-existing ransomware families in their attack chain that are sold on DarkWeb marketplaces. These include the HelloKitty (aka FiveHands) and Zeppelin strains of ransomware as opposed to Vice Society developing their own custom payload.

In September 2022, a joint Cybersecurity Advisory (CSA) from the FBI, CISA and the MS-ISAC declared they had recently observed Vice Society actors disproportionately targeting the education sector with ransomware attacks. The CSA continued that attacks could increase as the 2022-23 school year begins and criminal ransomware groups perceive opportunities for successful attacks.

Vice Society first surfaced in the summer of 2021, and in that time frame it was seen exploiting the CVE-2021-34527 (aka PrintNightmare) vulnerability as part of their attack chain. The gang is also known to target backups and exfiltrate data from compromised systems to be leveraged for the purpose of double extortion, a common ransomware operation tactic where victims are pressured to pay a specified ransom amount in exchange for decryption and to avoid having sensitive data published on the attacker’s dedicated leak site.

Palo Alto Networks customers receive protections against ransomware used by Vice Society from Cortex XDR, as well as from the WildFire cloud-delivered security service for the Next-Generation Firewall. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.

Related Unit 42 Topics Ransomware

Vice Society Activity Timeline

Early reports of the extortion group Vice Society were shared on Twitter by malware researchers such as Michael Gillespie. These tweets depicted HelloKitty ransomware payloads appending a .v-society extension to encrypted files on June 10, 2021.

Since then, Vice Society has used a variety of different ransomware strains including the following notable examples:

  • In June 2021, Vice Society infected victims with HelloKitty.
  • In 2021 and 2022, Vice Society used Zeppelin to target Windows hosts.
    • During their 2021 infections, these attackers also exploited vulnerabilities such as PrintNightmare to escalate privileges and spread laterally across targeted networks.

Based on leak site activity we’ve observed in recent months, as shown in Figure 1, we saw a subtle spike at the turning point from 2021 to 2022. This was followed by one large spike of activity at the end of spring 2022.

Figure 1 is a graph chart showing that the Vice Society gang activity timeline of years 2021 and 2021, with increase during the school year.
Figure 1. Vice Society activity timeline (all leak site victim data).

Fast forward to fall 2022, when we saw another wave of Vice Society activity across the education sector, as shown in Figure 2, which prompted a flood of advisories and reports about the group.

The noticeable spikes in spring and fall give us a hint at some of their motivations. As education organizations are the group’s prime target, this could be an indication that they’re timing campaigns to coincide with this sector’s unique calendar year. The school year for most educational institutions in the U.S. typically starts in late August-September and ends in June. They might have been trying to time their attacks in 2022 with the transitions of the beginning and end of the school year.

Figure 2 is a graph chart showing years 2021 and 2022 showing a significant spike at the beginning of the school year for 2022, 2021. The graph starts in January and ends in December.
Figure 2. Vice Society activity timeline (education-specific leak site victim data).

Study of Vice Society’s Victims

Vice Society is notorious for targeting the education sector – K-12 and higher education institutions in particular (as referenced in the recent CISA Advisory). Other targeted sectors include healthcare and nongovernmental organizations (NGOs).

Common targets are small- to medium-size businesses, with no geographical focus apparent at this time. Rather, as noted in a report by SOCRadar, Vice Society focuses on targets of opportunity.

For years, sectors such as education and healthcare have suffered from many challenges in combating ransomware that have made them particularly attractive targets. A lack of budgeting for systems and security solutions has led many organizations to run legacy hardware that isn’t patched against the latest vulnerabilities.

Other challenges that could increase the overall attack surface of these organizations include difficulties in controlling and managing a large number of personal devices brought in by students and staff members. These personal devices introduce inherent risk because they may interact with personal files via cloud services.

Although these sectors might have dedicated IT or security teams that run traditional security solutions such as an intrusion detection system (IDS) or intrusion prevention system (IPS), ransomware threat actors are leveraging living off the land techniques that can effectively circumvent traditional signature-based detection mechanisms. These tactics require an extended detection and response (XDR) platform for more robust behavioral monitoring within a network.

The education and healthcare sectors also experience the common challenge of finding staff who are adequately trained to handle the ongoing threat of ransomware. And lastly, many of these organizations are charged with protecting some of the most sensitive and valuable personally identifiable information (PII) of any business sector.

Geographical Impact

Vice Society is primarily opportunistic, and its targets have included organizations across the globe. The group has infected organizations based in all regions, as shown in Figures 3 and 4, with the largest numbers in the U.S., followed by the U.K., Spain, France, Brazil, Germany and Italy.

Figure 3 is a heatmap of all continents where affected companies are highlighted in a wave. The largest number of cases is in the United States, followed by the United Kingdom, Spain, France, Brazil, Germany and Italy.
Figure 3. Global geographic distribution of organizations listed on Vice Society leak site.
Figure 4 is the chart version of Figure 3 showing the global geographic distribution of organizations. Cases are counted by country starting from the highest number of cases in the United States with 35 cases down to 1 case. The United Kingdom had the second highest number of cases at 18 with with Spain third at 7 cases.
Figure 4. Chart version of global geographic distribution of organizations listed on Vice Society leak site.

The CISA advisory mentions how Vice Society has disproportionately targeted educational institutions in the United States. Looking at leak site data in more detail, the group appears to be targeting more educational organizations based in California, as shown in Figure 5.

Figure 5 shows the United States distribution of organizations listed on the Vice Society leak site. 17 states were affected with the most cases in California, which had 9 cases total.
Figure 5. Vice Society United States victimology (all leak site victim data).

Impacted Industry Verticals

Although Vice Society has been in the headlines for targeting educational organizations, they also extort victims in many other industry verticals, as shown in Figure 6, including those supplying critical infrastructure, such as healthcare, government entities and manufacturing.

Figure 6 shows industry verticals targeted by Vice Society. Pie charts show individual industry with education being the highest affected at 40 cases. Second is healthcare with 13 cases and third is state and local government at 12 cases.
Figure 6. Industry verticals targeted by Vice Society (leak site data).

Leak Site Metric Comparisons

According to analysis of ransomware leak sites, Unit 42 has identified Vice Society as being in the top 10 of the most impactful ransomware gangs of 2022. We estimate that, since it started operations in 2021, Vice Society has impacted more than 100 organizations in total. More than 90 of the total published leak site infections occurred in the year 2022 alone.

Leak site data suggests that Vice Society has had the highest impact on education organizations this year, with at least 33 educational institutions having been listed on the group’s dedicated ransomware leak site. This impact is closely followed by ransomware families such as LockBit 2.0 and 3.0, as shown in Figure 7.

Figure 7 shows ransomware groups targeting educational organizations. Pie charts show that Vice Society targeted 33 organizations. Lockbit 2.0 is second at 16 cases and Lockbit 3.0 is second at 9 cases.
Figure 7. Top ransomware families targeting educational institutions in 2022 (leak site data).

Unit 42 Incident Response Data on Vice Society

Since Vice Society’s inception in 2021, Unit 42 has performed incident response (IR) engagements with clients who have been impacted by Vice Society. Let’s look at some of the data from these incidents.

Dwell Time

In Unit 42 IR cases regarding Vice Society, we observed dwell times as high as six days. This represents the time elapsed between the date of initial compromise and the date of initial discovery.

Ransom Demands

When tracking ransomware group operations, Unit 42 takes note of the initial and final ransom demands made by each ransomware group. This allows us to better understand how aggressive a particular ransomware gang’s demands might be for particular industry verticals, and to get a general view into the rate at which a particular actor might drive their demands down after negotiations take place.

Our observations of ransom demands by Vice Society across IR cases include:

  • Initial demands by this actor could exceed $1 million.
  • Final demands after negotiations were as high as $460,000.
  • The difference between initial demands and final demands could be significant. We saw decreases as large as 60%.

Vice Society Technical Details

Leak Site Synopsis

Over the past year, Vice Society has operated sites on the Tor network using the following .onion address:
vsociethok6sbprvevl4dlwbqrzyhxcxaqpvcqt5belwvsuxaxsutyad[.]onion

On Oct. 20, the primary .onion address became inactive, while the following site mirror was still active: ssq4zimieeanazkzc5ld4v5hdibi2nzwzdibfh5n5w4pw5mcik76lzyd[.]onion

Recently, the header for the group’s blog site bears a striking resemblance to the logo of a popular video game titled “Grand Theft Auto: Vice City” (shown in Figure 8).

Figure 8 is a screenshot of the Vice Society active leak mirror website. It is purple with imitation Grand Theft Auto branding. It shows a highlighted countdown indicating when ransomed material will be released.
Figure 8. Vice Society active leak site mirror (Oct. 20).

On Oct. 25, the original .onion address became active again. It was updated to include additional blog sections. As of early November, the “Our Blog” page showcased one article that highlights the group's notoriety, as shown in Figure 9.

Figure 9 is a screenshot of Vice Society's "Our Blog" section highlighting press received by the gang and requesting more press tips.
Figure 9. Vice Society leak site including additional blog content (early November).

The new “Our Partners” page takes the place of the main page from the previous incarnation of the leak site, including links to view leaked victim data.

The new “For Victims” page directs victims to the ransom note that is dropped as part of the group’s infection chain. This is followed by additional instructions in case the victim doesn’t respond to one of the contact emails provided in their ransom note. During the extortion process, the attacker typically gives victims seven days to fulfill ransom demands, as shown in Figure 10.

Figure 10 is a screenshot showing Vice Society's "For Victims" website section detailing instructions beyond what is included in their ransom note.
Figure 10. Vice Society leak site victims page.

The “For Journalists” page depicts a “Frequently Asked Questions” section to address general questions about the group, as shown in Figure 11.

Figure 11 is a screenshot of Vice Society's "For Journalists" website section that includes "Frequently Asked Questions including how they started, operation length, and other topics.
Figure 11. Vice Society leak site journalists page.

HelloKitty Usage

At the start of the group’s observed operations in 2021, Vice Society affiliates used the HelloKitty Ransomware variant as a primary payload in their infection chain.

This ransomware family was first observed in December 2020, primarily targeting Windows systems. This variant gets its name from its mutex: HELLOKITTYMutex.

In July 2021, as described in our HelloKitty ATOM, Unit 42 came across a Linux (ELF) sample with the name funny_linux.elf that had a ransom note with contents similar to those of HelloKitty for Windows samples. This Linux sample led to the discovery of additional HelloKitty samples for Linux dating back to October 2020. In March 2021, HelloKitty’s Linux variant was also observed in the wild to target ESXi servers.

Similar to ransomware variants like BlackCat, HelloKitty ransomware typically requires a key to execute, to hinder analysis efforts. In HelloKitty’s case, this key is typically obfuscated with AES 256 encryption. As mentioned in our previous report detailing emerging ransomware families in 2021, HelloKitty features multiple flags that could be set as command line arguments, which are detailed in Table 1 of the linked report.

Figure 12 is a screenshot of a ransom note from Vice Society using HelloKitty ransomware. It details what was stolen, how to recover files, how prove encryption, how to make contact, what steps to avoid, and a request to visit the Vice Society website using Tor.
Figure 12. Vice Society ransom note using HelloKitty ransomware.

When the encryption process is complete, encrypted files are typically appended with an extension using the following format: .v-society.<victim ID>.

Zeppelin Usage

As previously mentioned, the Vice Society group has also been known to adopt other ransomware families such as Zeppelin as a part of their infection chain. Upon execution, the ransomware binary deletes itself and drops a ransom note on the victim machine’s desktop titled !!! ALL YOUR FILES ARE ENCRYPTED !!!.TXT. The contact email address provided by the threat actor vary between samples, but the public v-society.official@onionmail[.]org address and the Tor .onion link remain consistent.

Figure 13 is a screenshot of a Vice Society ransom note using Zeppelin ransomware. It details what was encrypted, how to recover the encrypted files, who to contact, and what steps to avoid.
Figure 13. Vice Society ransom note using Zeppelin ransomware.

Additional execution details include the following:

  • Creating the HKCU\Software\Zeppelin registry key
  • Appending an extension with the format A1A-A80-4CD to encrypted files
  • Creating a file called README.txt.v-society
  • Imphash: 8acb34bed3caa60cae3f08f75d53f727
  • Creating a temp file with a .Zeppelin extension using the following format - C:\Users\<User>\AppData\Local\Temp\7D3ED7F1.Zeppelin

Conclusion

School districts with limited cybersecurity capabilities and constrained resources are often the most vulnerable to threat actors. The opportunistic targeting often seen with cybercriminals can put even school districts with robust cybersecurity programs at risk. K-12 institutions may be seen as particularly lucrative targets due to the amount of sensitive student data accessible through school systems or their managed service providers.

Vice Society and its consistent targeting of the education industry vertical, particularly around the September time frame, serves as a warning that this group has shaped their campaigns to take advantage of the school year in the U.S. It’s likely they’ll maintain use of these tactics to impact the cyberthreat landscape moving forward, as long as their activities continue to be lucrative for them.

Educational institutions should continue to implement security best practices and be wary of the ongoing threat of ransomware, especially during the start and end of the school year.

K-12 institutions and universities do have an advantage when it comes to protecting themselves that too few organizations use to its full potential. In a school environment, there are many educators who can help inform trainings for both staff and students to learn what they need to do to maintain security for everyone in the organization.

Vice Society’s use of multiple ransomware payloads across both Windows and Linux hosts shows that they’re continually evolving. They will likely continue leveraging additional ransomware strains in the future, as well as exploiting newly disclosed vulnerabilities.

As we do with other ransomware groups, Unit 42 strongly advises organizations that have been impacted by Vice Society to avoid paying a ransom if possible, and to instead consult a trusted IR negotiation team for the best course of action.

Palo Alto Networks customers receive protections against ransomware used by Vice Society from Cortex XDR, as well as from the WildFire cloud-delivered security service for the Next-Generation Firewall.

If you think you may have been compromised 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

Tactics, Techniques and Procedures (TTPs)

Unit 42 has observed the following TTPs being used by Vice Society in past incident response engagements involving the group. The following table illustrates these TTPs according to the MITRE ATT&CK framework.

TA0001 Initial Access
T1566 Phishing Vice Society is known to use phishing to gain initial access to victims’ systems.
T1078 Valid Accounts Compromised valid credentials have been used by Vice Society to gain initial access. 
T1190 Exploit Public-Facing Applications Internet-facing applications and systems vulnerabilities can be exploited, such as PrintNightmare (CVE-2021-1675) and (CVE-2021-34527), to gain initial access.
TA0002 Execution
T1047 Windows Management Instrumentation (WMI) Malicious commands are executed via WMI as a means of “living off the land” and avoiding detection.
T1053.005 Scheduled Task/Job Vice Society is known to execute commands via scheduled tasks/jobs.
T1059.001 Command and Scripting Interpreter: Powershell Vice Society utilizes PsExec for execution, persistence and defense evasion. 
T1059.003 Command and Scripting Interpreter: Command Shell Batch files are used by Vice Society to deploy the ransomware via PsExec.
TA0003 Persistence
T1543.003 Modify System Process To maintain access to compromised systems, Vice Society leverages Windows operating functions to execute encrypted PowerShell.
T1547.001 Registry Run Keys/Startup Folder Persistence is maintained after boot/reboot via malicious autostart registry keys.
T1574.002 DLL Side-Loading Vice Society utilizes legitimate programs to side-load the group’s own DLL to execute their payload. 
TA0004 Privilege Escalation
T1068 Exploitation for Privilege Escalation Software vulnerabilities, such as PrintNightmare (CVE-2021-1675) and (CVE-2021-34527), may be exploited in an attempt to elevate privileges. 
TA0005 Defense Evasion
T1036 Masquerading Files dropped in the victim’s environment by Vice Society may have been altered to appear legitimate.
T1055 Process Injection Legitimate processes have been corrupted by Vice Society via code injection, as a means to evade defenses. 
T1070 Indicator Removal on Host As with many other ransomware groups, Vice Society attempts to clear system, security and application logs on compromised machines. 
T1112 Modify Registry Vice Society attempts to disable Windows Defender by modifying the Registry.
T1497 Sandbox Evasion Vice Society attempts to thwart reverse engineering and/or dynamic analysis via various sandbox evasion techniques. 
T1562.001 Impair Defenses: Disable or Modify Tools Attempts to disable or modify endpoint security, such as Microsoft Defender, on compromised devices.
TA0006 Credential Access
T1003 OS Credential Dumping Vice Society is known to utilize ntds.dit and comsvcs.dll to extract credentials.
T1003.001 OS Credential Dumping: LSASS Memory  Vice Society utilizes comsvcs.dll to dump credentials from Local Security Authority Subsystem Service. 
T1003.003 OS Credential Dumping: NTDS Vice Society attempts to “live off the land” by utilizing ntds.dit and ntdsutil.exe to dump Active Directory Database in an effort to obtain credentials.
TA0007 Discovery
T1046 Network Service Discovery Vice Society has been seen using the recon tool called Advanced Port Scanner to identify running services and local network infrastructure. 
T1482 Domain Trust Discovery Vice Society has been seen using the attack path reconnaissance tool Bloodhound during the initial stages of their attack before ransomware is deployed.
TA00008 Lateral Movement
T1021 Remote Services RDP is used by the group for lateral movement.
T1021.002 Remote Services: SMB/Windows Admin Shares SMB shares have been used by Vice Society for lateral movement.
T1080 Taint Shared Content Network drives and other shared storage locations are used by Vice Society to deliver payloads.
T1570 Lateral Tool Transfer Lateral tool transfers have been used to move tools and files from one compromised system to another, including SMB and RDP.
TA0010 Exfiltration
T1020 Automated Exfiltration PowerShell scripts are used to exfiltrate data to external C2 servers.
T1041 Exfiltration over C2 Channel Tools such as PowerShell and PsExec are used to exfiltrate data directly to C2 servers.
T1048 Exfiltration Over Alternative Protocol Vice Society has used SMB in attempts to exfiltrate data.
T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage Cloud storage and transfer services such as Mega.nz, Anonfiles.com, File.io, and Sendspace have been used by Vice Society to exfiltrate victim data. 
TA0011 Command and Control
T1219 Remote Access Software Tools such as SystemBC and proprietary backdoors are known to be used by Vice Society.
TA0040 Impact
T1486 Data Encrypted for Impact Vice Society is known for its extortion tactics, encrypting devices and demanding a ransom.
T1531 Account Access Removal Vice Society is known to change passwords of compromised victim accounts and privileged users, such as email and administrator accounts.

Indicators of Compromise (IoCs)

HelloKitty Elf samples featuring Vice Society ransom note header:

  • 643a3121166cd1ee5fc6848f099be7c7c24d36f5922f58052802b91f032a5f0f
  • 754f2022b72da704eb8636610c6d2ffcbdae9e8740555030a07c8c147387a537
  • 78efe6f5a34ba7579cfd8fc551274029920a9086cb713e859f60f97f591a7b04
  • 16a0054a277d8c26beb97850ac3e86dd0736ae6661db912b8782b4eb08cfd36e

Zeppelin ransomware with the Vice Society ransom note header:

  • 4a4be110d587421ad50d2b1a38b108fa05f314631066a2e96a1c85cc05814080
  • 307877881957a297e41d75c84e9a965f1cd07ac9d026314dcaff55c4da23d03e
  • faa79c796c27b11c4f007023e50509662eac4bca99a71b26a9122c260abfb3c6
  • dd89d939c941a53d6188232288a3bd73ba9baf0b4ca6bf6ccca697d9ee42533f
  • 4440763b18d75a0f9de30b1c4c2aeb3f827bc4f5ea9dd1a2aebe7e5b23cfdf94
  • 24efa10a2b51c5fd6e45da6babd4e797d9cae399be98941f950abf7b5e9a4cd7
  • bafd3434f3ba5bb9685e239762281d4c7504de7e0cfd9d6394e4a85b4882ff5d
  • aa7e2d63fc991990958dfb795a0aed254149f185f403231eaebe35147f4b5ebe
  • 001938ed01bfde6b100927ff8199c65d1bff30381b80b846f2e3fe5a0d2df21d
  • Ab440c4391ea3a01bebbb651c80c27847b58ac928b32d73ed3b19a0b17dd7e75

Contact information:

  • vicesociety@onionmail[.]org
  • v-society.official@onionmail[.]org
  • LarryGold@onionmail[.]org
  • MollyThomson@onionmail[.]org
  • BruceBoyle@onionmail[.]org
  • SylvesterJones@onionmail[.]org
  • brendaevans4454@onionmail[.]org
  • warreinolds77@onionmail[.]org
  • DaltonReed@onionmail[.]org
  • FreddieFerrell@onionmail[.]org
  • lewiselsberry@onionmail[.]org
  • inezeng@onionmail[.]org
  • lonnieguzman@onionmail[.]org
  • thomasmoore@onionmail[.]org

Domains:

  • vsociethok6sbprvevl4dlwbqrzyhxcxaqpvcqt5belwvsuxaxsutyad[.]onion
  • Qu5dci2k25x2imgki2dbhcwegqqsqsrjj5d3ugcc5kpsgbtj2psaedqd[.]onion
  • Wavbeudogz6byhnardd2lkp2jafims3j7tj6k6qnywchn2csngvtffqd[.]onion
  • gunyhng6pabzcurl7ipx2pbmjxpvqnu6mxf2h3vdeenam34inj4ndryd[.]onion

Additional Resources

Threat Brief: Windows Print Spooler RCE Vulnerability (CVE-2021-34527 AKA PrintNightmare)
Emerging Ransomware Groups: AvosLocker, Hive, HelloKitty, LockBit 2.0
Threat Assessment: Zeppelin Ransomware
#StopRansomware: Vice Society | CISA
Dark Web Profile: Vice Society - SOCRadar® Cyber Intelligence Inc.
Michael Gillespie Twitter post
Unit 42 ATOM: HelloKitty
UNC2447 SOMBRAT and FIVEHANDS Ransomware: A Sophisticated Financial Threat | Mandiant

Blowing Cobalt Strike Out of the Water With Memory Analysis

Posted on by Dominik Reichel

Executive Summary

Unit 42 researchers examine several malware samples that incorporate Cobalt Strike components, and discuss some of the ways that we catch these samples by analyzing artifacts from the deltas in process memory at key points of execution. We will also discuss the evasion tactics used by these threats, and other issues that make their analysis problematic.

Cobalt Strike is a clear example of the type of evasive malware that has been a thorn in the side of detection engines for many years. It is one of the most well-known adversary simulation frameworks for red team operations. However, it’s not only popular among red teams, but it is also abused by many threat actors for malicious purposes.

Although the toolkit is only sold to trusted entities to conduct realistic security tests, due to source code leaks, its various components have inevitably found their way into the arsenal of malicious actors ranging from ransomware groups to state actors. Malware authors abusing Cobalt Strike even played a role in the infamous SolarWinds incident in 2020.

Related Unit 42 Topics Cobalt Strike, Sandbox

Overview of Cobalt Strike

The main driver for the proliferation of Cobalt Strike is that it is very good at what it does. It was designed from the ground up to help red teams armor their payloads to stay ahead of security vendors, and it regularly introduces new evasion techniques to try to maintain this edge.

One of the main advantages of Cobalt Strike is that it mainly operates in memory once the initial loader is executed. This situation poses a problem for detection when the payload is statically armored, exists only in memory and refuses to execute. This is a challenge to many security software products, as scanning memory is anything but easy.

In many cases, Cobalt Strike is a natural choice for gaining an initial footprint in a targeted network. A threat actor can use a builder with numerous deployment and obfuscation options to create the final payload based on a customizable template.

This payload is typically embedded into a file loader in encrypted or encoded form. When the file loader is executed by a victim, it decrypts/decodes the payload into memory and runs it. As the payload is present in memory in its original form, it can be detected easily due to some specific characteristics.

As malware researchers, we often see potentially interesting malicious samples that turn out to just be loaders for Cobalt Strike. It’s also often unclear if a loader was created by a red team or a real malicious actor, thus making attribution even more challenging.

In the next few sections, we’re going to take a closer look into three different Cobalt Strike loaders that were detected out of the box by a new hypervisor based sandbox we designed to allow us to analyze artifacts in memory. Each sample loads a different implant type, namely an SMB, HTTPS and stager beacon. We dubbed these Cobalt Strike loaders KoboldLoader, MagnetLoader and LithiumLoader. We will also discuss some of the methods we can use to detect these payloads.

KoboldLoader SMB Beacon

The sample we’re looking at was detected during a customer incident.

SHA256: 7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292

This 64-bit KoboldLoader executable uses various known tricks to try to bypass sandboxes and to make the analysis process more time consuming.

To bypass sandboxes that hook only high-level user mode functions, it solely calls native API functions. To make the analyst's life harder, it dynamically resolves the functions by hash instead of using plain text strings. The malware contains code to call the following functions:

  • NtCreateSection
  • NtMapViewOfSection
  • NtCreateFile (unused)
  • NtAllocateVirtualMemory (unused)
  • RtlCreateProcessParameters
  • RtlCreateUserProcess
  • RtlCreateUserThread
  • RtlExitUserProcess

The malware creates two separate tables of function hash/address pairs. One table contains one pair for all native functions, while the second table only pairs for Nt* functions.

For the Rtl* functions that were used, it loops through the first table and searches for the function hash to get the function address. For the Nt* functions that were used, it loops through the second table and simultaneously increases a counter variable.

When the hash is found, it takes the counter value that is the system call number of the corresponding native function, and it enters a custom syscall stub. This effectively bypasses many sandboxes, even if the lower level native functions are hooked instead of the high-level ones.

The overall loader functionality is relatively simple and uses mapping injection to run the payload. It spawns a child process of the Windows tool sethc.exe, creates a new section and maps the decrypted Cobalt Strike beacon loader into it. The final execution of the Cobalt Strike loader that in turn loads an SMB beacon happens by calling RtlCreateUserThread.

You can find the decrypted beacon configuration data in the Appendix section.

In-Memory Evasion

With our new hypervisor-based sandbox, we were able to detect the decrypted Cobalt Strike SMB beacon in memory. This beacon loader even uses some in-memory evasion features that create a strange sort of chimeric file. While it’s actually a DLL, the “MZ'' magic PE bytes and subsequent DOS header are overwritten with a small loader shellcode as shown in Figure 1.

Image of shellcode showing disassembled Cobalt Strike beacon loader.
Figure 1. Disassembled Cobalt Strike beacon loader shellcode.

The shellcode loader jumps to the exported function DllCanUnloadNow, which prepares the SMB beacon module in memory. To do this, it first loads the Windows pla.dll library and zeroes out a chunk of bytes inside its code section (.text). It then writes the beacon file into this blob and fixes the import address table, thus creating an executable memory module.

During the analysis of the file, we could figure out some of the in-memory evasion features that were used, as shown in Table 1.

Evasion feature Description Used in our sample
allocator Set how beacon's ReflectiveLoader allocates memory for the agent. Options are: HeapAlloc, MapViewOfFile and VirtualAlloc. No
cleanup Ask beacon to attempt to free memory associated with the reflective DLL package that initialized it. Yes
magic_mz_x64 Override the first bytes (MZ header included) of beacon's reflective DLL. Valid x86 instructions are required. Follow instructions that change CPU state with instructions that undo the change. Yes
magic_pe Override the PE character marker used by beacon's ReflectiveLoader with another value. No
module_x64 Ask the x86 reflective loader to load the specified library and overwrite its space instead of allocating memory with VirtualAlloc. Yes
obfuscate Obfuscate the reflective DLL’s import table, overwrite unused header content, and ask ReflectiveLoader to copy beacon to new memory without its DLL headers. Yes
sleep_mask Obfuscate beacon and its heap, in-memory, prior to sleeping. No
smartinject Use embedded function pointer hints to bootstrap beacon agent without walking kernel32 Export Address Table (EAT). No
stomppe Ask ReflectiveLoader to stomp MZ, PE and e_lfanew values after it loads beacon payload. No
userwx Ask ReflectiveLoader to use or avoid read, write or execute (RWX) permissions for Beacon DLL in memory. No

Table 1. Cobalt Strike evasion techniques that were used.

To sum up, the beacon loader and the beacon itself are the same file. Parts of the PE header are used for a shellcode that jumps to an exported function, which in turn creates a module of itself inside a Windows DLL. Finally, the shellcode jumps to the entry point of the beacon module to execute it in memory.

As discussed, there is no way for us to detect this beacon of our KoboldLoader sample successfully unless we can peer inside memory during execution.

MagnetLoader

The second loader we will look into is a 64-bit DLL that imitates a legitimate library.

SHA256: 6c328aa7e0903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0

This MagnetLoader sample tries to look like the Windows file mscms.dll in a few ways, by using the following similar features:

  • The same file description
  • An export table with many of the same function names
  • Almost identical resources
  • A very similar mutex

These features are also shown in Figure 2, where the malware file is contrasted with the valid mscml.dll.

Left-right comparison image using EXE Explorer where the malware file is contrasted with valid mcml.dll. Left shows MagnetLoader file description, export table and resources compared to msmcl.dll on right.
Figure 2. Comparison of file description, export table and resources of MagnetLoader (left) and mscml.dll (right) as seen with EXE Explorer.

MagnetLoader not only tries to mimic the legitimate Windows library statically, but also at runtime.

All of the exported functions of MagnetLoader internally call the same main malware routine. When one of them is called, the DLL entry point is run first. In the entry point, the malware loads the original mscms.dll and it resolves all the functions it fakes.

The addresses of these original functions are stored and called after a fake method is executed. Thus, whenever an exported function of MagnetLoader is called, it runs the main malware routine and afterward calls the original function in mscms.dll.

The main malware routine is relatively simple. It first creates a mutex named SM0:220:304:WilStaging_02_p1h that looks very similar to the original one created by mscms.dll.

The Cobalt Strike beacon loader gets decrypted into a memory buffer and executed with the help of a known trick. Instead of calling the beacon loader directly, the loader uses the Windows API function EnumChildWindows to run it.

This function contains three parameters, one of which is a callback function. This parameter can be abused by malware to indirectly call an address via the callback function and thus conceal the execution flow.

You can also find the decrypted beacon configuration data in the Appendix section.

LithiumLoader

This last Cobalt Strike sample is part of a DLL side-loading chain where a custom installer for a type of security software was used. DLL side-loading is a technique that hijacks a legitimate application to run a separate, malicious DLL.

SHA256: 8129bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f

This 32-bit LithiumLoader DLL is part of a custom attacker-created Fortinet VPN installation package submitted to VirusTotal as FortiClientVPN_windows.exe (SHA256: a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786).

The FortiVPN.exe file is not malicious or compromised. Because the file is signed, attackers used it to evade antivirus detection.

The installer is a self-extracting RAR archive that contains the following files:

File name Description
FortiVPN.exe Legit signed FortiClient VPN Online installer v7.0.1.83
GUP.exe Legit signed WinGup for Notepad++ tool v5.2.1.0
gup.xml WinGup config file
libcurl.dll LithiumLoader

Table 2a. FortiClientVPN_windows.exe file contents.

The self-extracting script commands are as follows:

Screenshot of the self-extracting script commands for the RAR file. There are five lines of code in total.
Table 2b. List of self-extracting script commands.

When the installer is run, all files get silently dropped to the local %AppData% folder and both executable files get started. While the FortiClient VPN installer executes, the WinGup tool side-loads the libcurl.dll LithiumLoader malware. The malware does so because it imports the following functions from a legit copy of the libcurl library as shown in Figure 3.:

An image showing the import address of WinGub.exe with libcurl.dll (4) highlighted in left column, with curl_easy_setopt and its ordinal and address highlighted in the right column.
Figure 3. Import address table of WinGup.exe.

This threat also tries to add the %AppData% folder path to the exclusion list in Windows Defender via PowerShell.

On the startup of GUP.exe, the malicious libcurl.dll file is loaded into the process space as it statically imports the functions shown in Figure 3, above. While all four libcurl functions are run, only curl_easy_cleanup contains a malicious routine that was injected while compiling a new version of the library. Thus, we’re not dealing with a patched version of the legitimate DLL. This is a cleaner solution that doesn’t break the code after the inserted malicious routine, as is often seen in other malware.

This curl_easy_cleanup function usually contains only one subroutine (Curl_close) and has no return value (as shown in its source code on GitHub). The altered function is as shown in Figure 4.

A screenshot of the modified curl_easy_cleanup export function showing 9 lines of code with int __cdel curl_easy_cleanup(Curl_easy *data) highlighted.
Figure 4. Modified curl_easy_cleanup export function of libcurl.dll.

The load_shellcode function decrypts the shellcode via XOR and key 0xA as shown in Figure 5.

A screenshot showing 28 lines of code with BOOL load_shellcode() highlighted. This function decrypts the shellcode via XOR and key 0xA on lines 14 and 22.
Figure 5. Shellcode loader function load_shellcode().

This function runs the Cobalt Strike stager shellcode indirectly via EnumSystemGeoID instead of directly jumping to it. This Windows API function has three parameters, the last one of which is a callback function abused by LithiumLoader.

The Cobalt Strike stager shellcode is borrowed from Metasploit and is the reverse HTTP shell payload, which uses the following API functions:

  • LoadLibrary
  • InternetOpenA
  • InternetConnectA
  • HttpOpenRequestA
  • InternetSetOptionA
  • HttpSendRequestA
  • GetDesktopWindow
  • InternetErrorDlg
  • VirtualAllocStub
  • InternetReadFile

The shellcode connects to the IP address of a university in Thailand.

LithiumLoader Detection Issues

At the time of writing this analysis, the Cobalt Strike beacon payload was no longer available. Without a payload or any actionable information in the execution report of API calls, it’s often challenging for a sandbox to determine whether the sample is malicious. This sample doesn’t have any functionality that can be classified as malicious per se.

Catching Cobalt Strike Through Analyzing Its Memory

In all three of these examples there are some common detection challenges. These samples do not execute in normal sandbox environments. But as we discussed, there is a wealth of information that we can use for detection if we look inside memory during execution, like function pointers, decoded stages of the loader, and other artifacts.

For many years now, it has been standard practice for sandbox systems to instrument and observe the activity of executing programs. If our team has learned anything over the years, it’s that this alone is not enough for highly evasive malware. This is why we’ve been working hard the past few years on figuring out how we can add more thorough processing for this type of highly evasive malware.

For accurate detection, one of the key features we’ve found to address highly evasive malware is that we need to look at memory as samples execute in addition to using the system API to get a better understanding of what’s happening.

An image showing a magnifying glass with a target inside with the text "Malware Process". An arrow extends from the target and text to an icon of a computer with "OS" on the monitor to stand for Operating System. The first part of the image text is "Industry standard: Focus mainly on interactions with system APIs. Memory analysis: Focus on memory during live sample execution in addition to observable malware actions.
Figure 6. High level Advanced WildFire detection strategy.

We’ve found that, in malware detection, it’s useful to look at the deltas in memory at key points of execution to extract meaningful information and artifacts. As our system processes a vast number of samples, there have been a lot of challenges to make this work at scale. However, a lot of clever engineering built on top of our flagship custom hypervisor tailored for malware analysis has helped make this idea a reality.

In these next few sections, we will detail some of the main types of data that we are currently collecting from memory to aid detection. This data can be utilized by both our analysts for manual signatures as well as machine learning pipelines, which we’ll be discussing in a future post.

Although we are focusing on memory here, we are by no means suggesting that instrumenting and logging API calls are not useful for detection. Our belief is that bringing execution logs and memory analysis data together creates a sum greater than its parts.

Automatic Payload Extraction

As previously discussed, it is increasingly common for malware authors to obfuscate their initial payloads. While using executable packers that can compress and obfuscate files to accomplish this is nothing new, it becomes problematic when it’s used in combination with evasion strategies, because there is no static or dynamic data that’s useful for an accurate detection.

There are infinite combinations of strategies for encoding, compressing, encrypting or downloading additional stages for execution. The ability to craft signatures for these payloads is obviously an important way that our analysts can catch lots of different malware components from frameworks like Cobalt Strike. If we can catch them in memory, it ultimately doesn’t matter if the malware decides not to execute.

The following simplified diagram in Figure 7 shows an example of what we might see in a couple of stages that were never present in the initial executable file.

Image of a simplified diagram highlighting the possible stages seen in a packed malware executable. On the left is the shellcode stage as part of an executable image, with arrows showing its progress through the stack and then to the heap. From the stack the shellcode moves to the PEs.
Figure 7. Typical stages we might see in a packed malware executable.

On the left side of the diagram, we see an example of a shellcode stage. Although the term “shellcode” was originally coined for hand crafted assembly utilized in exploits to pop a shell on a target system, the word has evolved to encompass any blobs of custom assembly written for nefarious purposes. Some malware stages are blobs of custom assembly with no discernable executable structure. A common pattern for malware authors taking this approach is to dynamically resolve all of the function pointers into a table for ease of access.

On the right side of the diagram, we see that the later stage is an example of a well-formed executable. Some malware stages or payloads are well-formed executables. These can be loaded by the OS via the system API, or the malware author might use their own PE loader if they’re trying to be stealthy in avoiding calling any APIs to do this for them.

Function Pointer Data

Another rich set of data we can pull from memory that we’ve begun to use for detection is dynamically resolved function pointers, as shown in Figure 8. Malware authors learned long ago that if they explicitly call out all of the WINAPI functions they plan to use in the import table, it can be used against them. It is now standard practice to hide the functions that will be used by the malware or any of its stages.

Shellcode hashing is another common stealthy strategy used to resolve pointers for functions without needing their string.

Image of dynamically resolved WINAPI pointers seen in a memory segment. On the left is a block showing the API pointer data. On the right are the targeted OS libraries.
Figure 8. Examples of dynamically resolved WINAPI pointers we might see in a memory segment.

In Advanced WildFire we have begun to selectively search for and use this information about which WINAPI function pointers were resolved in our detection logic.

OS Structure Modifications

Another useful source of detection data we’ve found from analyzing memory is to look for any changes to Windows bookkeeping structures (Malware authors love to mess with these!). These structures are important for the OS to maintain state about the process, such as what libraries have been loaded, where the executable image was loaded, and various other characteristics about the process that the OS might need to know later. Given that many of these fields should never be modified, it’s often useful to keep track of when and how malware samples are manipulating them.

The diagram in Figure 9 shows how a sample might unhook a module it loaded from the LDR Module list. Unhooking a module would mean that there is no longer a record that the module exists. So, for example, after doing this the Task Manager in Windows would no longer list it.

This diagram represents only one of many different OS Structure modifications we’ve seen, but it shows that there are many different types of OS structure modifications that are useful for the malware detection problem.

This image shows three fields on the left indicating the progression from the thread information block to the PEB LDR data structure. An arrow shows the progression from the Data Structure to the LDR Modules. The LDR Module ntdll.dll moves to LDR Module kernel32.dll and unhooks it from the malware to replace it with a separate .dll.
Figure 9. An example of how a module might be unhooked from the LDR Modules List.

Page Permissions

Finally, another useful source of detection data is a full log of all changes made to page permissions. Authors of packed malware often need to change memory permissions in order to properly load and execute further stages. Understanding which pages of memory had their permissions changed often provides important insights into where code was loaded and executed, which can be useful for detection.

Conclusion

Although Cobalt Strike has been around for some years, detecting it is still a challenge to many security software providers. That is because this tool works mostly in memory and doesn’t touch the disk much, other than with the initial loader.

We’ve looked into three new loaders and showed how they can be detected using a variety of techniques. These detection techniques are available within our new hypervisor based sandbox.

Figure 10 illustrates our detection reasons for KoboldLoader.

Screenshot identifying the malware. Listed is the verdict, detection reason 1, detection reason 2, the behaviors (redacted) and the memory analysis behaviors (redacted). The detection reasons include identifying the malware as Cobalt Strike and its variant, and its signatures. It also detected its beacon and shellcode loader.
Figure 10. Internal KoboldLoader sample analysis report.

Palo Alto Networks customers receive protections from these threats:

  • Advanced WildFire identifies the Cobalt Strike loaders and beacons as malicious.
  • Cortex XDR protects endpoints and identifies the loaders as malicious.

Indicators of Compromise

KoboldLoader

7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292
6ffedd98d36f7c16cdab51866093960fe387fe6fd47e4e3848e721fd42e11221
fc4b842b4f6a87df3292e8634eefc935657edf78021b79f9763548c74a4d62b8
062aad51906b7b9f6e8f38feea00ee319de0a542a3902840a7d1ded459b28b8d
a221c7f70652f4cc2c76c2f475f40e9384a749acd1f0dbaefd1a0c5eb95598d2

MagnetLoader

6c328aa7e0903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0

LithiumLoader

8129bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f
82dcf67dc5d3960f94c203d4f62a37af7066be6a4851ec2b07528d5f0230a355

LithiumLoader Installer

a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786
cbaf79fb116bf2e529dd35cf1d396aa44cb6fcfa6d8082356f7d384594155596

Appendix

KoboldLoader beacon configuration data:

BeaconType - SMB
Port - 4444
SleepTime - 10000
MaxGetSize - 1048576
Jitter - 0
MaxDNS - 0
PublicKey_MD5 - 633dc5c9b3e859b56af5edf71a178590
C2Server -
UserAgent -
HttpPostUri -
Malleable_C2_Instructions - Empty
PipeName - \\.\pipe\servicepipe.zo9keez4weechei8johR.0521cc13
DNS_Idle - Not Found
DNS_Sleep - Not Found
SSH_Host - Not Found
SSH_Port - Not Found
SSH_Username - Not Found
SSH_Password_Plaintext - Not Found
SSH_Password_Pubkey - Not Found
SSH_Banner - Not Found
HttpGet_Verb - Not Found
HttpPost_Verb - Not Found
HttpPostChunk - Not Found
Spawnto_x86 - %windir%\syswow64\dfrgui.exe
Spawnto_x64 - %windir%\sysnative\dfrgui.exe
CryptoScheme - 0
Proxy_Config - Not Found
Proxy_User - Not Found
Proxy_Password - Not Found
Proxy_Behavior - Not Found
Watermark_Hash - Not Found
Watermark - 666
bStageCleanup - True
bCFGCaution - True
KillDate - 0
bProcInject_StartRWX - True
bProcInject_UseRWX - False
bProcInject_MinAllocSize - 35485
ProcInject_PrependAppend_x86 - b'\x90\x90\x90\x90\x90\x90\x90'
b'\x90\x90\x90\x90\x90\x90\x90'
ProcInject_PrependAppend_x64 - b'\x90\x90\x90\x90\x90\x90\x90'
b'\x90\x90\x90\x90\x90\x90\x90'
ProcInject_Execute - ntdll.dll:RtlUserThreadStart
NtQueueApcThread
NtQueueApcThread-s
SetThreadContext
RtlCreateUserThread
kernel32.dll:LoadLibraryA
ProcInject_AllocationMethod - NtMapViewOfSection
bUsesCookies - Not Found
HostHeader - Not Found
headersToRemove - Not Found
DNS_Beaconing - Not Found
DNS_get_TypeA - Not Found
DNS_get_TypeAAAA - Not Found
DNS_get_TypeTXT - Not Found
DNS_put_metadata - Not Found
DNS_put_output - Not Found
DNS_resolver - Not Found
DNS_strategy - Not Found
DNS_strategy_rotate_seconds - Not Found
DNS_strategy_fail_x - Not Found
DNS_strategy_fail_seconds - Not Found
Retry_Max_Attempts - Not Found
Retry_Increase_Attempts - Not Found
Retry_Duration - Not Found

MagnetLoader beacon configuration data:

BeaconType - HTTPS
Port - 443
SleepTime - 3600000
MaxGetSize - 1402498
Jitter - 70
MaxDNS - Not Found
PublicKey_MD5 - 965fe5c869f3eea5e211fa7ee12130d3
C2Server - tileservice-weather.azureedge[.]net,/en-au/livetile/front/
UserAgent - Microsoft-WebDAV-MiniRedir/10.0.19042
HttpPostUri - /en-CA/livetile/preinstall
Malleable_C2_Instructions - Remove 1380 bytes from the end
Remove 3016 bytes from the beginning
Base64 URL-safe decode
HttpGet_Metadata - ConstHeaders
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
Host: tileservice-weather.azureedge[.]net
Origin: https://tile-service-weather.azureedge[.]net
Referer: https://tile-service.weather.microsoft[.]com/
Metadata
base64url
append "/45.40,72.73"
uri_append
HttpPost_Metadata - ConstHeaders
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
Host: tileservice-weather.azureedge[.]net
Origin: https://tile-service-weather.azureedge[.]net
Referer: https://tile-service.weather.microsoft[.]com/
ConstParams
region=CA
SessionId
base64url
parameter "appid"
Output
base64
print
PipeName - Not Found
DNS_Idle - Not Found
DNS_Sleep - Not Found
SSH_Host - Not Found
SSH_Port - Not Found
SSH_Username - Not Found
SSH_Password_Plaintext - Not Found
SSH_Password_Pubkey - Not Found
SSH_Banner -
HttpGet_Verb - GET
HttpPost_Verb - POST
HttpPostChunk - 0
Spawnto_x86 - %windir%\syswow64\conhost.exe
Spawnto_x64 - %windir%\sysnative\conhost.exe
CryptoScheme - 0
Proxy_Config - Not Found
Proxy_User - Not Found
Proxy_Password - Not Found
Proxy_Behavior - Use IE settings
Watermark_Hash - Not Found
Watermark - 1700806454
bStageCleanup - True
bCFGCaution - False
KillDate - 0
bProcInject_StartRWX - False
bProcInject_UseRWX - False
bProcInject_MinAllocSize - 17500
ProcInject_PrependAppend_x86 - b'\x90\x90'
Empty
ProcInject_PrependAppend_x64 - b'\x90\x90'
Empty
ProcInject_Execute - CreateThread
SetThreadContext
ProcInject_AllocationMethod - NtMapViewOfSection
bUsesCookies - False
HostHeader -
headersToRemove - Not Found
DNS_Beaconing - Not Found
DNS_get_TypeA - Not Found
DNS_get_TypeAAAA - Not Found
DNS_get_TypeTXT - Not Found
DNS_put_metadata - Not Found
DNS_put_output - Not Found
DNS_resolver - Not Found
DNS_strategy - round-robin
DNS_strategy_rotate_seconds - -1
DNS_strategy_fail_x - -1
DNS_strategy_fail_seconds - -1
Retry_Max_Attempts - Not Found
Retry_Increase_Attempts - Not Found
Retry_Duration - Not Found

To decrypt the configuration data we used SentinelOne’s Cobalt Strike Parser.

Additional Resources

EXE Explorer
Cobalt Strike Parser

Updated December 6, 2022, at 9:05 a.m. PT. 

Threat Assessment: Luna Moth Callback Phishing Campaign

Posted on by Erica Naone

Executive Summary

Unit 42 investigated several incidents related to the Luna Moth/Silent Ransom Group callback phishing extortion campaign targeting businesses in multiple sectors including legal and retail. This campaign leverages extortion without encryption, has cost victims hundreds of thousands of dollars and is expanding in scope.

By design, this style of social engineering attack leaves very few artifacts because of the use of legitimate trusted technology tools to carry out attacks. However, Unit 42 has identified several common indicators implying that these attacks are the product of a single highly organized campaign. This threat actor has significantly invested in call centers and infrastructure that’s unique to each victim.

Cybersecurity awareness training is the most effective defense against these stealthy and discreet attacks. However, Palo Alto Networks customers receive protection from the attacks discussed in this blog through the Next-Generation Firewall and Cortex XDR detecting data exfiltration or connections to suspicious networks.

Related Unit 42 Topics Phishing, BazarLoader

What Is Callback Phishing?

Callback phishing, also referred to as telephone-oriented attack delivery (TOAD), is a social engineering attack that requires a threat actor to interact with the target to accomplish their objectives. This attack style is more resource intensive, but less complex than script-based attacks, and it tends to have a much higher success rate.

In the past, threat actors associated with the Conti group have had great success with this attack style in the BazarCall campaign. Unit 42 has been tracking these types of attacks since 2021. Early iterations of this attack focused on tricking the victim into downloading the BazarLoader malware using documents with malicious macros.

This new campaign, which Sygnia has attributed to a threat actor dubbed "Luna Moth," does away with the malware portion of the attack. In this campaign, attackers use legitimate and trusted systems management tools to interact directly with a victim’s computer, to manually exfiltrate data to be used for extortion. As these tools are not malicious, they’re not likely to be flagged by traditional antivirus products.

Please note that the tools named in this post are legitimate. Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not imply a flaw or malicious quality to the legitimate product being abused.

The Typical Callback Phishing Attack Chain

The initial lure of this campaign is a phishing email to a corporate email address with an attached invoice indicating the recipient’s credit card has been charged for a service, usually for an amount under $1,000. People are less likely to question strange invoices when they are for relatively small amounts. However, if people targeted by these types of attacks reported these invoices to their organization’s purchasing department, the organization might be better able to spot the attack, particularly if a number of individuals report similar messages.

The phishing email is personalized to the recipient, contains no malware and is sent using a legitimate email service. These phishing emails also have an invoice attached as a PDF file. These features make a phishing email less likely to be intercepted by most email protection platforms.

The attached invoice includes a unique ID and phone number, often written with extra characters or formatting to prevent data loss prevention (DLP) platforms from recognizing it. When the recipient calls the number, they are routed to a threat actor-controlled call center and connected to a live agent.

Under the guise of canceling the subscription, the threat actor agent guides the caller through downloading and running a remote support tool to allow the attacker to manage the victim’s computer. This step usually generates another email from the tool’s vendor to the victim with a link to start the support session.

The attacker then downloads and installs a remote administration tool that allows them to achieve persistence. If the victim does not have administrative rights on their computer, the attacker will skip this step and move directly to finding files for exfiltration.

The attacker will then seek to identify valuable information on the victim’s computer and connected file shares, and they will quietly exfiltrate it to a server they control using a file transfer tool.

In this way, the threat actor is able to compromise organizational assets through a social engineering attack on an individual.

After the data is stolen, the attacker sends an extortion email demanding victims pay a fee or else the attacker will release the stolen information. If the victim does not establish contact with the attackers, they will follow up with more aggressive demands. Ultimately, attackers will threaten to contact victims’ customers and clients identified through the stolen data, to increase the pressure to comply.

Luna Moth Campaign Analysis

Unit 42 has responded to multiple cases related to a single campaign that occurred from mid-May to late October 2022. ADVIntel attributes this campaign to a threat actor dubbed Silent Ransom with ties to Conti. While Unit 42 cannot confirm Silent Ransom’s tie to Conti at this time, we are monitoring this closely for attribution.

These cases show a clear evolution of tactics that suggests the threat actor is continuing to improve the efficiency of their attack. Cases analyzed at the beginning of the campaign targeted individuals at small- and medium-sized businesses in the legal industry. In contrast, cases later in the campaign indicate a shift in victimology to include individuals at larger targets in the retail sector.

During the initial campaign, the phishing email frequently originated from an address using the format FirstName.LastName.[SpoofedBusiness]@gmail[.]com as seen in Figure 1. The attacker often spoofs the names of obscure athletes for these email addresses.

Unit 42 has also observed emails with the format [RandomWords]@outlook[.]co.th.

Phishing image, with subject line including "thank you for subscribing". Body of the email indicates that the subscription will be activated and paid in 24 hours. It also instructs the target to look at the attached invoice if they have any problems, and directs them to call their "customer support" number. The scheme, used by Luna Moth, is known as callback phishing.
Figure 1. Redacted phishing email.

The wording in the body of the phishing email has changed throughout the campaign. This was likely done to thwart email protection platforms. Regardless of what wording was used, the email always indicated the victim is responsible for the charges detailed in the attached invoice.

PDF documents containing an invoice number were attached to the phishing emails. Unit 42 observed fake invoices spoofing both an online class platform and a health club aggregator in this campaign.

Early incidents used a logo from one of the spoofed businesses at the top of the invoice. Later cases replaced this with the simple header welcoming the target to the second spoofed business on a plain blue background, as shown in Figure 2. Each invoice features a nine- or 10-digit confirmation number near the top, which is also incorporated into the filename. When the recipient contacts the threat actor, this confirmation number is used to identify them.

Image of the fake invoice file from later campaigns including the confirmation number and instructions for canceling the "subscription," urging the target to act within 36 hours. The fake invoice was used by Luna Moth as part of a callback phishing campaign.
Figure 2. Redacted fake invoice.

Early iterations of the extortion campaign recycled phone numbers, but later attacks either used a unique phone number per victim, or victims would be presented with a large pool of available phone numbers in the invoice.

The attacker registered all of the numbers they used via a Voice over IP (VoIP) provider. When the victim called one of the attacker’s numbers, they were placed into a queue and eventually connected with an agent who sent a remote assist invitation for the remote support tool Zoho Assist.

The footer of these invitation emails (shown in Figure 3) revealed the email address the threat actor used to register with Zoho. In most incidents, the attacker chose an address from an encrypted email service provider to masquerade as the same vendor used in the fake invoice.

Image showing a remote assist invitation for the remote support tool used by the Luna Moth threat group in their callback phishing campaign.
Figure 3. Redacted remote assistance invitation.

Once the victim connected to the session, the attacker took control of their keyboard and mouse, enabled clipboard access, and blanked out the screen to hide their actions.

Once the attacker blanked the screen, they installed remote support software Syncro for persistence and open source file management tools Rclone or WinSCP for exfiltration. Early cases also included remote management tools Atera and Splashtop, but recently the attacker appears to have tightened their toolset.

In cases where the victim did not have administrative rights to their operating system, the attacker skipped installing software to establish persistence. Attackers instead downloaded and executed WinSCP Portable, which does not require administrative privileges and is able to run within the user’s security context.

In cases where the attacker established persistence, exfiltration occurred hours to weeks after initial contact. Otherwise, the attacker only exfiltrated what they could during the call. The attacker exfiltrated data shortly before the attack.

The domains used early in the campaign were random words with a top-level domain (TLD) of .xyz. Later in the campaign, domains consistently followed the format of [5 letters].xyz. All observed domains fell into the 192.236.128[.]0/17 network range.

Exfiltration was followed with an extortion email, as shown in Figure 4. Like in other templates used in this campaign, the wording and format in the extortion email has evolved over time. In the cases Unit 42 investigated, the attacker claimed to have exfiltrated data in amounts ranging from a few gigabytes to over a terabyte.

Extortion email with subject line including "stole information and confidential data." In the body of the email, attackers take credit for stealing proprietary and confidential data, and indicate that they will leak this data to clients as well as the attackers' website and social media if they are not paid. They also indicate they will provide evidence of having deleted the data, though this behavior was not seen in all incidents.
Figure 4. Redacted extortion email.

The threat actor created unique Bitcoin wallets for each victim’s extortion payments. These wallets contained only two or three transactions and were emptied immediately after funding.

Attacker’s monetary demands ranged from 2-78 BTC. They researched the target organization’s revenue and used it to justify this extortion amount. However, attackers were quick to offer discounts of approximately 25% for prompt payment.

Paying the attacker did not guarantee they would follow through with their promises. At times they stopped responding after confirming they had received payment, and did not follow through with negotiated commitments to provide proof of deletion.

Prevention and Detection

The threat actors behind this campaign have taken great pains to avoid all non-essential tools and malware, to minimize the potential for detection. Since there are very few early indicators that a victim is under attack, employee cybersecurity awareness training is the first line of defense.

People should always be cautious of messages that invoke fear or a sense of urgency. Do not respond directly to suspicious invoices. Contact the requester directly via the channels made available on the vendor’s official website. People should also consult internal support channels before downloading or installing software on their corporate computers.

The second line of defense against this attack type is a robust security technology stack designed to detect behavioral anomalies in the environment. Palo Alto Networks customers receive protection from the attacks discussed in this blog through the Next-Generation Firewall and Cortex XDR detecting data exfiltration or connections to suspicious networks.

Conclusion

Unit 42 expects callback phishing attacks to increase in popularity due to the low per-target cost, low risk of detection and fast monetization. While groups that can establish infrastructure to handle inbound calls and identify sensitive data for exfiltration are likely to dominate the threat landscape initially, a low barrier to entry makes it probable that more threat actors will enter the fray.

Common observables suggest a pervasive multi-month campaign that is actively evolving. Therefore, organizations in currently targeted industries, such as legal and retail, should be particularly vigilant to avoid becoming victims.

All organizations should consider strengthening cybersecurity awareness training programs with a particular focus on unexpected invoices, as well as requests to establish a phone call or to install software. Additionally, expand investments in cybersecurity tools designed to detect and prevent anomalous activity, such as installing unrecognized software or exfiltrating sensitive data.

If you think you may have been compromised 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

Additional Resources

 

An AI Based Solution to Detecting the DoubleZero .NET Wiper

Posted on by Wenjun Hu

Executive Summary

Unit 42 researchers introduce a machine learning model that predicts the maliciousness of .NET samples based on specific structures in the file, by analyzing a .NET wiper named DoubleZero. We identify the challenges of detecting this threat through PE structural analysis and conclude by examining the cues picked up by the machine learning model to detect this sample.

While wipers are not necessarily new, the recent discovery of several new wipers associated with the ongoing Russia-Ukraine cyber activity has driven renewed public interest in understanding how to identify and defend against their use.

Palo Alto Networks customers receive protections from .NET malwares with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services, including WildFire and Advanced Threat Prevention.

Related Unit 42 Topics Machine Learning, WildFire, .NET Framework

DoubleZero Wiper

The wiper DoubleZero was revealed to the public by Ukraine CERT in March 2022. It is one of many wipers – including HermeticWiper, IsaacWiper and CaddyWiper – that were apparently targeted against their country.

DoubleZero is implemented in C#, and it is heavily obfuscated. This wiper is capable of typical, non-reversible and destructive actions that include the following:

  • Gaining the highest privilege in the host
  • Hunting down all available targeted files from every volume
  • Destroying targeted files or disk volumes within a short period of time

Unlike HermeticWiper and other wipers that damage the Master Boot Record (MBR) or GUID Partition Table (GPT), DoubleZero only wipes the first 4096 bytes in selected files using the file system driver. We limit our focus on the .NET samples feature engineering, but this Splunk article provides a more in-depth technical analysis of the wiper sample.

SHA256 3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe
File size 419.50 KB

Examining the PE File Structure

Researchers have been commonly using Microsoft Windows Portable Executable (PE) file structure to detect PE malware for many years. The thought behind this tactic is that variants of the same malware family can often share similarities in their file structure.

Machine learning models also detect PE malware based on the file structure. To do so, they have historically used PE header characteristics, imports and section attributes to recognize known malware characteristics.

While the .NET PE file structure is based on the PE format, a lot of its functionality is encoded within the .NET specific structures. In the next section, we’ll dive deeper into the .NET structural attributes.

An Inside Look Into .NET files

The .NET open source framework was introduced in 2002 and is available by default in most Microsoft Windows platforms. The framework provides developers with powerful, built-in methods to access the internet, file system and encryption. Having these options already available makes this framework attractive to both system administrators and malware authors.

Microsoft Windows PE loader will already know how to load and execute the .NET sample once the framework is ready, since .NET assembly re-uses the PE file format.

During code generation, the source code for .NET compatible languages is compiled to platform-agnostic Common Intermediate Language (CIL) byte code. A special .NET IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR can be found in the data directory for referencing the Cor20 header, as shown in Figure 1. The Cor20 header (otherwise known as the CLR header) contains .NET specific information like versioning and resource information and the location of the Metadata header. The resources, streams, type references, methods, CIL byte codes and usage of external assemblies are all in the metadata. For a more detailed description, please refer to our article on dotnetfile.

Diagram illustrating the .NET file structure including MZ and PE headers, data directory, and the text section including Cor20 and metadata headers as well as storage streams and CIL byte code,
Figure 1. A simple illustration of .NET file structure.

Unlike most PE files, where dependent libraries and APIs can be found in the import table, for a .NET file the import table contains just one module (the mscoree.dll) and one imported function (_CorExeMain for executables and _CorDllMain for dynamic load libraries). The resources are contained within the .NET storage stream instead of the .rsrc section.

The entry point of the PE header points to the _CorExeMain or _CorDllMain of the mscoree.dll, while the actual entry point can be found in the Cor20 header as shown in Figure 2. Thus, some of the most useful attributes to identify PE malware files do not contain many clues for .NET malware.

Diagram expanding on the Cor20/CLR header, default streams and metadata table
Figure 2. .NET specific structures and the data they hold.

The metadata table contains defined tables for Module, MethodDef and Assembly among others. By examining the .NET file structure, we can see it provides a lot more information about the file as compared to the PE file structure alone. Instead of only using the general PE features for the .NET machine learning solution, we added the data specifically parsed from the structure of .NET samples. These customized features improve the quality of our machine learning solutions.

Applying Machine Learning to .NET Malware Detection

We have trained a machine learning model on custom features learned on the PE file structure, .NET file structure and other file characteristics of .NET samples, as shown in Figure 3.

As .NET is an extremely popular file type in customer environments, it is necessary for us to have a quick turnaround time in case any disruptive false positives emerge. This means that our model’s functionality has to be well understood by researchers, and that the predictions could be reverse engineered.

Because .NET files are so ubiquitous, they also have a highly imbalanced distribution of benign vs. malicious samples. Consequently, the trained model has to ensure that we maintain extremely low false positive rates while retaining detection accuracy.

Diagram of detection workflow taking a sample and extracting features, then model training and evaluation leads to a final model
Figure 3. An overview of our detection workflow.

Detecting the DoubleZero Wiper

The malware sample has a single import, _CorExeMain, from mscoree.dll, consistent with other .NET executable files. It contains only .text and .reloc sections, all of which are native to the PE file format and have fairly low entropy. Hence, there’s not much we can learn from this file’s PE structure.

The CIL bytecode uses obfuscation to hide the string resources that are critical for pattern based detection. It also interleaves random code among actual operations, together with flattened control flow, to make the code harder to follow. However, we can glean a lot about the objective of this malware by observing the imported libraries and associated API calls found in the decompiled code.

The imports System.DirectoryServices.ActiveDirectory and System.Security.AccessControl indicate the intention to interact with the Active Directory and access control attributes of the files.

The regular expression function imported by System.Text.RegularExpressions is used to locate certain files by patterns.

The most significant signs of malicious code usage are the calls to the unmanaged DLL functions. Platform Invoke (P/Invoke) enables the managed codes in .NET to call the unmanaged functions. Calling the lower level APIs directly is a well known anti-analysis technique to evade API hooking by sandbox. The following unmanaged APIs are used in the sample:

  • ntdll.ntopenfile
  • ntdll.ntfscontrolfile
  • ntdll.rtlntstatustodoserror
  • ntdll.rtladjustprivilege
  • kernel32.closehandle
  • kernel32.getfilesizeex
  • kernel32.getlasterror
  • user32.exitwindowsex

In most of the use cases, there are equivalent managed functions in .NET runtime libraries to use. However, this sample intends to operate at a lower level with some of the unmanaged APIs in ntdll.dll.

The target files and the regular expression patterns are surprisingly stored as plain strings, as shown in Figure 4. This possible mistake by the threat actor allows us to get more insights about the objective of the sample.

Decompiled code snippet showing strings stored in plain text
Figure 4. An example decompiled code snippet where the sample uses regular expressions to search the target files.

Though obfuscation exists, we are still able to get the argument FsControlCode for the call to ntdll.NtFsControlFile, which is 0x980c8 = FSCTL_SET_ZERO_DATA. This is how the wiper writes 4K of null bytes to a targeted file that was opened by ntdll.NtOpenFile.

The sample calls ntdll.RtlAdjustPrivilege several times with privileges 9, 17, 18 and 19. These privileges are SeTakeOwnershipPrivilege, SeBackupPrivilege, SeRestorePrivilege and SeShutdownPrivilege respectively. These privileges are used to ensure the wiper has the access right to destroy the target file and reboot the system after all the actions are done.

Unlike HermeticWiper and ransomware like LockBit, DoubleZero doesn’t delete the shadow copies that can possibly be used to recover files from the damage. However, the wiper does kill any process named lsass. Lsass is important to the Windows system, and any application that kills this process is most likely malicious.

The aforementioned file characteristics give us clues that the machine learning model uses to detect the sample. Though obfuscation is more common among malicious .NET files, because the sample uses several unmanaged APIs as well as sensitive target path patterns, these stand out as potentially malicious indicators.

Conclusion

Researchers have been using PE file structure to detect variants within malware families for years, as they often share similarities in their file structure. Despite the .NET framework being well known, it can still be challenging to detect files using this strategy. Some of the most useful attributes for identifying PE malware files don’t offer many clues for identifying .NET malware.

We have highlighted the fundamental difference between .NET and PE samples to help identify where those clues could be hiding. In doing so, we illustrated that machine learning feature engineering can be improved by correctly parsing out the .NET specific data structure.

We also showed that imported libraries, unmanaged API calls and unencrypted strings are the most useful features for detecting .NET malware. While a recent wiper called DoubleZero was analyzed as an example, the features that are important for detecting .NET can be generalized, and this feature can be broadly useful for future research efforts.

Palo Alto Networks customers receive protections from .NET malware with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

Indicators of Compromise

3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe

Additional Resources

DoubleZero Wiper
Threat Update DoubleZero Destructor
HermeticWiper
IsaacWiper and HermeticWizard
CaddyWiper
dotnetfile Open Source Python Library: Parsing .NET PE Files Has Never Been Easier

Network Security Trends: May-July 2022

Posted on by Erica Naone

Executive Summary

Recent May-July 2022 observations of network security trends and exploits used in the wild reveal that attackers have been making use of newly published remote code execution vulnerabilities. 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 the 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,976 newly published vulnerabilities, a large portion (almost 11.6%) involves cross-site-scripting.
  • Lists of major vulnerabilities identified by evaluating more than 340 million attack sessions including remote code execution, directory traversal and information disclosure.
  • 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 May-July 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 denial-of-service.
  • 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 Cloud-Delivered Security Services, including Threat Prevention, WildFire, Advanced URL Filtering 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, cross-site request forgery, directory traversal, command injection, improper authentication, security feature bypass
Related Unit 42 Topics Network Security Trends, exploits in the wild, attack analysis

Analysis of Published Vulnerabilities, May-July 2022

From May-July 2022, a total of 5,976 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,976 CVEs that have an assigned severity score of medium or higher can be seen in the following table:

Severity Count Ratio PoC Availability Change
Critical 1133 19.0% 5.5% -2.3%
High 2399 40.1% 3.8% -1.0%
Medium 2444 40.9% 3.4% -0.2%

Table 1. Severity distribution for CVEs registered May-July 2022, including only those rated medium-critical.

Medium severity: 40.9%, high severity: 40.1%, critical severity: 19.0%
Figure 1. Severity distribution for CVEs registered May-July 2022, including only those rated medium-critical.

Our classification of vulnerabilities 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 having 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 discussed, the critical-severity ratios increased while high-severity and medium-severity PoC ratios decreased slightly.

Vulnerability Category Distribution

It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 23.5% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 76.5% 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.

Red = critical, yellow = high, blue = medium. In order from most to least prevalent vulnerability category: cross-site scripting, SQL injection, information disclosure, privilege escalation, denial of service, traversal, command injection, code execution, out-of-bounds write, buffer overflow, use-after-free, improper authentication.
Figure 2. Vulnerability category distribution for CVEs registered May-July 2022.

Cross-site scripting remains the most reported vulnerability during May-July 2022. We also saw that the prevalence of SQL injection vulnerabilities increased during this time, and many of the vulnerabilities in this category are ranked critical. The number of SQL injection and cross-site scripting vulnerabilities slightly increased and out-of-bound vulnerabilities decreased. Most of the recently published cross-site scripting and information disclosure attacks are usually at medium or high severity (rather than critical).

Red = critical, yellow = high, blue = medium. In order from most to least prevalent vulnerability category: cross-site scripting, SQL injection, information disclosure, privilege escalation, denial of service, traversal, command injection, code execution, out-of-bounds write, buffer overflow, use-after-free.
Figure 3. Vulnerability category distribution compared with the previous quarter.

Network Security Trends: Analysis of Exploits in the Wild, May-July 2022

Data Collection

By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from May-July 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 340 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 340 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.

Network security trends in attack severity. Medium severity: 47.2%, high severity: 21.5%, critical severity: 31.3%
Figure 4. Attack severity distribution, May-July 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 a decrease in critical- and high-severity attacks and an increase in medium-severity attacks. However, we still focus more on critical-severity attacks because of their greater potential impact. Many published vulnerabilities are scored medium severity, but attackers typically leverage more severe vulnerabilities for exploits. Defenders should prioritize preventing and mitigating high- and critical-severity network attacks.

Network security trends in vulnerability severity compared with the previous quarter. Red=critical, yellow = high, blue = medium. Medium shows an increase of over 20% since last quarter, high shows less than 10% decrease, and critical shows almost 20% decrease.
Figure 5. Vulnerability severity distribution compared with the previous quarter.

When Did the Network Attacks Occur?

Red = critical, yellow = high, blue = medium, green = total. The bar graph shows attack severity distribution by millions of sessions divided weekly between May-July 2022.
Figure 6. Severity of exploits in the wild measured weekly from May-July 2022.

During May-July 2022, attackers gradually increased their exploitation of vulnerabilities of medium severity, and the number of attacks gradually increased (the last set of data records eight days of attack volume instead of seven days).

As we’ve seen in the past, attackers frequently use recently disclosed vulnerabilities, especially those from 2021-22. 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.

Network security trends in observed attacks, categorized by the year in which the exploited CVE was disclosed. Red = CVEs disclosed 2021-2022, yellow = CVEs disclosed 2019-2020, blue = CVEs disclosed 2016-2018, green = CVEs disclosed 2010-2015, orange = CVEs disclosed prior to 2010. The bar graph shows attack severity distribution by millions of sessions divided weekly between May-July 2022.
Figure 7. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from May-July 2022.

Exploits in the Wild, May-July 2022: A Detailed View of Network Security Trends

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 information disclosure. Attackers typically want to gain as much information and control as possible over the systems they target. Traversal attacks decreased this quarter.

Network security trends in attack category and severity. Red = critical, yellow = high, blue = medium. Attack categories in order of prevalence: remote code execution, information disclosure, traversal, cross-site scripting, DOS, memory corruption, buffer overflow, hacktool, improper authentication, exploit-kit, command injection, and privilege escalation.
Figure 8. Attack category and severity, May-July 2022.
Red = critical, yellow = high, blue = medium. Attack categories in order of prevalence: remote code execution, information disclosure, traversal, cross-site scripting, DOS, memory corruption, buffer overflow, hacktool, improper authentication, and exploit-kit.
Figure 9. Attack category distribution compared to 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 Germany then the Netherlands. Attacks from the Netherlands and Romania 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.

Network security trends pie chart showing locations of observed attacks. United States = 49.6%, Germany = 17.2%, The Netherlands = 10.2%, France = 5.7%, Romania = 3.3%, Canada = 1.4%, Russian Federation = 1.3%, United Kingdom = 1.1%, China = 0.9%, Others = 9.4%
Figure 10. Locations ranked in terms of how frequently they were the origin of observed attacks from May-July 2022.
Bar chart showing percentage change in location of observed attacks. United States = >20% decrease, Germany = >10% increase, The Netherlands = <10% increase, France = <5 increase, Romania = <5% increase, Canada = ~1% increase, Russian Federation = >1% decrease, United Kingdom = >1% increase, China = <1% decrease, Others = >1% decrease
Figure 11. Attack originate distribution compared to the previous quarter.
Network security trends heat map where attacks appear to originate. The United States is deepest red, followed by Germany and the Netherlands
Figure 12. Attack geolocation distribution from May-July 2022.

Conclusion

The vulnerabilities disclosed from May-July 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 Best Practice Assessment 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 8638 and above).

Additional Resources

Typhon Reborn With New Capabilities

Posted on by Riley Porter

Executive Summary

In early August 2022, Cyble Research Labs (a cybercrime monitoring service) uncovered a new crypto miner/stealer for hire that the malware author named Typhon Stealer. Shortly thereafter, they released an updated version called Typhon Reborn. Both versions have the ability to steal crypto wallets, monitor keystrokes in sensitive applications and evade antivirus products.

This new version has increased anti-analysis techniques and more malicious features. The threat actors have also improved their stealer and file grabber features.

Palo Alto Networks customers receive protections from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

Malware Sale and Advertisements

The threat actors behind Typhon Stealer were advertising their creation through an underground website as shown in Figure 1, while providing development and distribution updates through their existing Telegram channel.

Website post showing the feature set for Typhon Stealer v.1.1.0 - July 17 update.
Figure 1. Screenshot of underground website for older version of Typhon Stealer.

Typhon Reborn: Stealer With New Features

The original version of Typhon Stealer was updated and released with the new name of “Typhon Reborn.” This new version has increased anti-analysis techniques and it was modified to improve the stealer and file grabber features.

Figure 2 is a screenshot of the latest offerings, listed in a private Telegram channel.

Telegram message listing new features and changes in Typhon Reborn.
Figure 2.Typhon Reborn’s new features as listed in a Telegram message.

In their Telegram channel, the malware author stated that the current price for this stealer is $100 for a lifetime subscription, as shown in Figure 3. They also have claimed that the final compressed Typhon Reborn payload size has been reduced to around 2.3 MB depending on the stealer's build configuration.

Figure 3.Telegram post stating Typhon Reborn’s price.
Figure 3.Telegram post stating Typhon Reborn’s price.

In the Telegram post, we see that the author has added multiple new features and disabled a few old features (e.g. keylogger, clipper miner, etc.). These differences are visible by viewing the code blocks in Typhon 1.2 and the latest Reborn version. Figure 4 shows modules for block list and CryptoApps are present in the latest version.

Module list for Typhon 1.2, to illustrate which have been added or removed between versions
Figure 4a. Typhon 1.2 code block showing available features. This can be compared to the Typhon Reborn code block in Figure 4b.
Module list for Typhon Reborn, to illustrate which have been added or removed between versions
Figure 4b. Typhon Reborn code block showing available features. This can be compared to the Typhon 1.2 code block in Figure 4a.

Technical Analysis

Typhon Reborn was released with multiple new features and configurable options. These new features include block listed usernames and countries, new message clients and a crypto-extension stealer for Google Chrome and Microsoft Edge. The author also removed a few existing features, including the keylogging ability as well as the clipboard stealing and crypto mining features.

Keylogging and crypto mining code is typically easy to detect in dynamic analysis platforms. We speculate the removal of these features was to lower the chances of antivirus detections. The author stated in his release notes that the features that were removed, would be moved to their own projects in the future.

Anti-Analysis Techniques

All of Typhon Reborn’s new anti-analysis checks, once triggered, run the cleverly named MeltSelf method, as shown in Figure 5. This method kills the threat’s process and deletes itself from the disk.

Typhon Reborn’s new anti-analysis techniques include the following:

  • Checking for debugging arguments
  • Detecting virtual machines
  • Checking for debuggers
  • Checking the size of the physical disk
  • Checking for well known analysis processes (blocklisting)
  • Checking for well known sandbox usernames
  • Checking for victim country
Anti-analysis checks that will run "MeltSelf," which terminates the threat's process and deletes itself from disk if it's triggered.
Figure 5. Anti-analysis functions.

Command Line Debugger

Typhon Reborn also checks the command line arguments included to launch the stealer. If the command line argument contains the –-debug keyword, the stealer will “MeltSelf,” as shown in Figure 6.

Typhon Reborn checks the command line arguments included to launch the stealer, for the keyword –-debug.
Figure 6. Detection of command line debugging.

Disk Size for Various Operating Systems

While a disk size check is not a new evasion in general, it is a new feature added to Typhon Reborn (shown in Figure 7). It checks to ensure the disk space is of a certain size based on the operating system. If the current disk is below 30 GB for Windows versions 7 and 10, the stealer again runs “MeltSelf.”

Windows 11 70 GB
Windows 10 30 GB
Windows 7 30 GB

Table 1. The stealer checks disk space based on the operating system.

Code snippet that checks to ensure the disk space is over a certain size based on the operating system.
Figure 7. Anti-analysis check based on disk size, on various operating systems.

Block List Processes

Typhon Reborn has included a larger list of potential analysis processes to check for. The process names included are all well known analysis tools, and if detected, Typhon Reborn will “MeltSelf”

ollydbg

processhacker

tcpview

autoruns

de4dot

ilspy

dnspy

autorunsc

filemon

procmon

regmon

idaq

 idaq64

immunitydebugger

wireshark

dumpcap

hookexplorer

lordpe

petools

resourcehacker

x32dbg

x64dbg

fiddler

Table 2. Block list of processes.

Block List of Usernames

Typhon Reborn has also added a username check to its anti-analysis techniques as shown in Figure 8. The usernames listed below are known to be used in various public and private sandboxes to execute malware. If the malware is executed under any of the following usernames, the malware calls “MeltSelf.”

IT-ADMIN   

Paul Jones 

WALKER     

Sandbox    

Timmy      

John Doe   

CurrentUser

 sand box

maltest

malware

virus

sandbox

Emily

test

Table 3. Block list of usernames.

Code snippet to check for usernames known to be used in various public and private sandboxes.
Figure 8. Check for block list of usernames.

Block Listing Commonwealth of Independent States (CIS) Countries

Typhon Reborn’s new victim country code check enables the attacker to configure locations of machines they do not wish to execute on. During execution of the stealer, the location code checks rely on the third party service ipinfo[.]json to determine the victim’s physical location. If this service is unavailable, the victim's time zone code is used to determine the country of origin instead. If the victim’s machine is located in one of the CIS countries, the stealer will cease execution, as shown in Figure 9.

Code snippet to check if the victim’s machine is located in one of the CIS countries, which will run "MeltSelf" if it's triggered.
Figure 9. Check for block listed countries including those in the CIS.

The samples we were able to acquire did not use this feature. However, the code is supported and configurable at build time.

Checking for a Single Instance

Malware checking is a common technique to make sure only a single instance is running, to avoid multiple instances competing for system resources. Typhon Reborn also implements this check.

Typhon Reborn specifically checks to see if the executable's name is in the startup path. If it is, the malware will “MeltSelf.”

Additional Features in New Version

Typhon Reborn removed the keylogger, clipper, miner and worm features that had been available in previous versions. While it is not explicitly stated why the malware author removed these features from the current codebase, we speculate that they were moved to separate projects to be available for an additional fee in future versions.

Crypto-Extension Stealer for Microsoft Edge and Google Chrome

The previous version of this stealer supported stealing cryptocurrency wallet files, but Typhon Reborn has extended this feature to specifically target Google Chrome and Microsoft Edge crypto app browser extensions.

Code snippet that checks for the presence of cryptocurrency wallet extensions in Google Chrome browser.
Figure 10. Crypto extension for Chrome.

Some of the extensions targeted by Typhon Reborn include Binance, Bitapp, Coin98 and more. Also, they specifically target Microsoft Edge’s web browser extensions for Yoroi, Metamask and Rabet wallets.

Code snippet that checks for the presence of cryptocurrency wallet extensions in Microsoft Edge browser.
Figure 11. Crypto extensions for Microsoft Edge browser.

User and Network Details

Typhon Reborn is now capable of gathering additional victim data, including the following:

  • Machine username
  • Operating system information
  • Antivirus software used
  • Wireless network information
  • Network interface data
  • Language

Below is a screenshot of the data that is scraped and sent to the malware author’s Telegram channel.

Code snippet to format user and network data for exfiltration to the threat operator.
Figure 12. Formatting user and network data.

Typhon Reborn also gathers extended Wi-Fi information. Most of this data is fairly innocuous, such as language, computer name, OS and antivirus if present. However, this version of Typhon Reborn extracts all wireless networking passwords from the victim’s host machine and writes those in a Wifi Passwords.txt file.

Code snippet that gathers victims' Wi-Fi information and writes it to "Wifi Passwords.txt" file.
Figure 13. Stealing Wi-Fi passwords.

The techniques Typhon Stealer uses for data exfiltration have not changed from its previous version. However, we included the screenshot below to illustrate how the malware author is leveraging Telegram’s API and infrastructure to exfiltrate all data stolen by Typhon Reborn.

"Code snippet that illustrates how the malware author is leveraging Telegram’s API and infrastructure to exfiltrate data. "
Figure 14. Example of content sent over Telegram API to attacker.

Conclusion

Typhon Stealer provided threat actors with an easy to use, configurable builder for hire. They are continuing to update their code to enhance their tools and techniques to evade security systems and exfiltrate data smoothly.

Their configurable builders lower the required technical skill set for potential clients. Typhon Reborn’s new anti-analysis techniques are evolving along industry lines, becoming more effective in the evasion tactics while broadening their toolset for stealing victim data.

The longer their malware can run without detection, the more valuable the malware is. With the addition of new cryptocurrency wallet targets, the stealer has shown that there are clearly still more sources of lucrative data, and thus a thriving market for malware for hire services.

Palo Alto Networks customers receive protections from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

Indicators of Compromise

A12933ab47993f5b6d09bec935163c7f077576a8b7b8362e397fe4f1ce4e791c  Typhon Reborn Stealer
48133d1aaf1a47f63ec73781f6a2b085b28174895b5865b8993487daec373e0a Typhon Stealer

Unit 42 Finds Three Vulnerabilities in OpenLiteSpeed Web Server

Posted on by Aviv Sasson

Executive Summary

The Unit 42 research team has researched and discovered three different vulnerabilities in the open source OpenLiteSpeed Web Server. These vulnerabilities also affect the enterprise version, LiteSpeed Web Server. By chaining and exploiting the vulnerabilities, adversaries could compromise the web server and gain fully privileged remote code execution. The vulnerabilities discovered include:

  1. Remote Code Execution (CVE-2022-0073) rated High severity (CVSS 8.8)
  2. Privilege Escalation (CVE-2022-0074) rated High severity (CVSS 8.8)
  3. Directory Traversal (CVE-2022-0072) rated Medium severity (CVSS 5.8)

OpenLiteSpeed is the Open Source edition of LiteSpeed Web Server Enterprise, which is developed and maintained by LiteSpeed Technologies. LiteSpeed Web Server is ranked the sixth most popular web server. Analysis from Palo Alto Networks Cortex Xpanse and Shodan reveals that LiteSpeed serves roughly 2% of all Web Server applications, with nearly 1.9 million unique servers globally.

Unit 42 responsibly disclosed the vulnerabilities to LiteSpeed Technologies with suggested remediation on Oct. 4, 2022. LiteSpeed Technologies swiftly released a patch version (v1.7.16.1) on Oct. 18, 2022, to mitigate the reported vulnerabilities.

Organizations using OpenLiteSpeed versions 1.5.11 up to 1.7.16 and LiteSpeed versions 5.4.6 up to 6.0.11 are advised to update their software to the latest matching release – v1.7.16.1 and 6.0.12.

Palo Alto Networks customers using Prisma Cloud WAAS or Next-Generation Firewalls with Advanced Threat Prevention receive protection from these vulnerabilities by new rules and signatures that block the attack.

Related Unit 42 Topics Containers

Background

LiteSpeed is a performance-focused web server. According to our findings there are 1.9 million internet facing LiteSpeed Server instances online.

As part of our initiative to contribute to the community to improve security and increase security awareness, we decided to audit OpenLiteSpeed, which is the open source version of the LiteSpeed Web Server.

We tried to imitate the actions of an adversary and engaged in research with the intention of finding vulnerabilities and disclosing them to the vendor. This research has resulted in finding three vulnerabilities that affect both the enterprise and open source solutions. These could be chained and exploited by an adversary who has the credentials for the admin dashboard, in order to gain privileged code execution on vulnerable components.

Remote Code Execution

This vulnerability has been assigned the CVE ID of CVE-2022-0073.

At the first stage of the attack, we tried to gain remote code execution and found that the OpenLiteSpeed Web Server admin dashboard is vulnerable to a command injection vulnerability. A threat actor who managed to gain the credentials to the dashboard, whether by brute force attacks or social engineering, could exploit the vulnerability in order to execute code on the server.

The vulnerability exists in the External App Command field, which allows users to specify a command that will be executed when the server starts.

This functionality is considered dangerous and therefore mitigations for abusing it were implemented. We managed to bypass the mitigations and abuse this functionality to download and execute a malicious file on the server with the privileges of the user nobody, which is an unprivileged user that traditionally exists in Linux machines.

Privilege Escalation

This vulnerability has been assigned the CVE ID of CVE-2022-0074.

After gaining code execution on the server we wanted to take it a step further and escalate our privileges from nobody to root.

While exploring the OpenLiteSpeed Docker image as nobody, we found a misconfiguration in the PATH environment variable that could be exploited into a privilege escalation using the CWE untrusted search path.

When executing a binary with a relative path, the operating system will look at the PATH variable, which contains a list of directories. It will then search for that binary in the listed folders, in the same order that the directories are presented.

The issue in this case was that the second directory in PATH was /usr/local/bin, which is a directory that the user nobody controls.

This leads to a situation where an attacker could execute code as an unprivileged user (such as nobody) to place a malicious file and disguise it as a legitimate binary in /usr/local/bin, with the intention for it to be executed by highly privileged processes because it is in the second directory on the PATH environment variable.

We were able to exploit this by abusing the script entrypoint.sh as shown in Figure 1, which runs as root and executes the binary grep repeatedly.

Code snippet from the entrypoint.sh script which runs as root and executes the binary grep repeatedly.
Figure 1. Entrypoint.sh script showing vulnerable usage of the grep command.

By chaining these vulnerabilities, we were able to gain remote code execution and escalate our privileges to root, as shown in Figure 2.

Code snippet chaining the vulnerabilities to gain remote code execution and escalate privileges to root.
Figure 2. Proof of successful exploitation.

This vulnerability requires the controlled user to have write permissions to /usr/local/bin, which is usually not the case by default. In the OpenLiteSpeed docker container, this directory is writable by the user nobody by default.

Directory Traversal

This vulnerability has been assigned the CVE ID of CVE-2022-0072.

The last issue we found was a directory traversal vulnerability that could allow an attacker to bypass security measures and access forbidden files. An attacker that compromised the server could create a secret backdoor and exploit the vulnerability to access it.

When browsing in LiteSpeed, the server will make sure that clients only access endpoints that should be visible to them. It does so by verifying that the requested URL does not contain characters that will result in a directory traversal and thus allow them to access forbidden endpoints.

This verification is done by two regular expressions, on lines 2060 and 2061. We managed to bypass those regular expression verifications, and we were able to access paths that we were not able to access initially.

Exploitation of this vulnerability allows adversaries to access any file in the web root directory, but it is limited only to that directory.

Mitigations

Unit 42 responsibly disclosed the vulnerabilities to LiteSpeed Technologies with suggested remediation on Oct. 4, 2022. LiteSpeed Technologies has released a patch version v1.7.16.1 for OpenLiteSpeed and 6.0.12 for LiteSpeed, which addresses the disclosed vulnerabilities.

The command injection mitigation regex that we previously mentioned was changed to include binaries such as curl, fetch and wget to prevent downloading external scripts to mitigate CVE-2022-0073.

The rewrite condition regexes previously mentioned were changed in order to mitigate CVE-2022-0072.

The ols-dockerfiles repository was patched as well, to set the PATH variable with the user nobody’s controlled path positioned last, preventing binary execution hijacking to mitigate CVE-2022-0074.

Conclusion

Web technologies, including web servers, have come a long way in the last few decades. They have become much more secure, but vulnerabilities are still being found as technologies are still evolving at a rapid pace.

As part of the commitment of Palo Alto Networks to advancing cloud security, we actively invest in the public cloud and web application research that includes advanced threat modeling and vulnerability testing of cloud platforms, web servers and related technologies

Palo Alto Networks customers receive protection from this kind of attack through the following products and services:

  1. Prisma Cloud WAAS customers received a virtual patch designated to mitigate this threat, and they remain protected until patches are applied to vulnerable assets.
  2. Next-Generation Firewalls with Advanced Threat Prevention signatures 93190 and 93191 can block the aforementioned attacks.

We'd like to thank LiteSpeed Technologies for quickly responding and patching the reported issues, and professionally handling the disclosure process.

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.

Updated Nov. 15, 2022, to adjust authorship to focus on the discoverer of the vulnerabilities.

Cobalt Strike Analysis and Tutorial: Identifying Beacon Team Servers in the Wild

Posted on by Durgesh Sangvikar

Executive Summary

As Cobalt Strike remains a premier post-exploitation tool for malicious actors trying to evade threat detection, new techniques are needed to identify its Team Servers. To this end, we present new techniques that leverage active probing and network fingerprint technology. This is a fundamental change from previous passive traffic detection approaches.

Over the course of our Unit 42 blog series covering the adversary framework tool Cobalt Strike, we document the encoding and encryption techniques of its HTTP transactions. Specifically, we analyzed the advanced, flexible traffic profiles used by Cobalt Strike’s Beacon command-and-control (C2) communication to evade detection by defenders.

Beacon implants communicate to an attacker-controlled application called Team Server. Team Server and the Beacon’s C2 traffic allow adversaries to easily and effectively cloak malicious traffic as normal, benign traffic. This is made possible by a modular, extensible domain-specific language called Malleable C2.

Sanctioned adversaries (such as Red/Blue team members, pentesters and ethical hackers) as well as malicious actors can use premade or custom Malleable C2 profiles. These profiles can be exceedingly difficult to continually develop traditional defenses against, such as conventional firewall threat prevention.

In previous approaches, Team Server detections could only be made after a Beacon binary was implanted on a victim’s system and attempted to “phone home” to an attacker-controlled server. Our new techniques can proactively detect Team Servers in the wild before an active C2 connection from a victim’s system has been initialized.

We will also demonstrate the following:

  • How Team Servers behave when they receive specially-crafted HTTP requests
  • What kind of network fingerprint can be inferred and with what confidence
  • Details of some real-life malicious C2 between Beacon and Team Server in the wild

Palo Alto Networks customers receive protections from and mitigations for Cobalt Strike Beacon and Team Server C2 communication in the following ways:

Related Unit 42 Topics Cobalt Strike, C2, Tutorials

Probing and Fingerprint Identification Technology

The Cobalt Strike Team Server, also known as CS Team Server, is the centralized C2 application for a Beacon and its operator(s). It accepts client connections, orchestrates remote commands to Beacon implants, provides UI management, and various other functions.

During our research and development of Advanced Threat Prevention’s inline deep learning detection for Cobalt Strike traffic, we began experimenting with forging C2 requests to suspected malicious Team Servers on the Internet. Through our analysis of attacker-controlled server responses, we developed a variety of techniques to classify previously undetected Cobalt Strike Team Servers before an attack can occur.

In the following sections, we share our findings on the following identification techniques:

Active Probing Over HTTP HTTP/S OPTIONS Request and Response Fingerprint

The Team Server is a Linux program running an HTTP server configured to respond to a variety of HTTP requests. When the server receives requests with the HTTP OPTIONS method, the server will return HTTP status code 200 and Content-Length: 0.

Figure 1 shows an HTTP request and response to a Team Server. The URI provided in an HTTP OPTIONS request is disregarded as the same response is returned regardless of URI.

Image showing an HTTP OPTIONS request and HTTP 200 response to a Team Server.
Figure 1. HTTP OPTIONS request with HTTP 200 response.

HTTP/HTTPs GET Request and Response Fingerprint

When a Team Server starts, the HTTP server exposes certain URIs. Figure 2 shows the list of URIs.

The URLs stager and stager64 are masked if the profile has the set host_stage "false"; option set. The HTTP server will return HTTP status code 404 if the URI begins with a forward slash (/).

Image showing a list of URIs from the Team Server, including associated port number (80), type (beacon), and descriptions.
Figure 2. List of the URIs from the Team Server.
Request to Stager URI

When a user sends the following HTTP request to a Team Server, the server will return the 32-bit Beacon binary to the client. Figure 3 shows the HTTP request and response. Note the lack of a forward slash (/) at the beginning of the URI path.

Image showing an HTTP GET request and response for a 32-bit Beacon payload.
Figure 3. HTTP GET request and response for a 32-bit Beacon payload.
Request to Stager64 URI

To receive a 64-bit Beacon payload, a user must send an HTTP GET request to the URI stager64. Figure 4 shows the HTTP request and response for a 64-bit Beacon payload.

Image showing an HTTP GET request and response for a 64-bit Beacon payload.
Figure 4. HTTP GET request and response for a 64-bit Beacon payload.
Request to Beacon.http-get URI

Certain preset URI paths can be configured in the Malleable C2 profile to serve static data. If a user sends a GET request to the URI beacon.http-get, the Team Server responds with the data that has been specified in its profile. Specifically, it sends the output section within the server tag of the http-get configuration.

If the output section only contains the command print;, the server responds with HTTP status code 200 and Content-Length: 0. Figure 5 shows the HTTP request and response with the default profile.

Image showing an HTTP request and response with the default profile.
Figure 5. HTTP request and response with default profile.

If Team Server initializes with the Malleable C2 Gmail profile, the server responds with static data presented as described above. In this profile, GET requests to beacon.http-get result in a response containing a JavaScript payload.

Figure 6 shows the HTTP request and response generated by a Beacon session preset with the Gmail Malleable C2 profile.

Image showing an HTTP request and response with the Gmail Malleable C2 Gmail profile.
Figure 6. HTTP request and response configured with the Gmail Malleable C2 Gmail profile.
Request to Beacon.http-post URI

Team Server’s behavior is the same for a GET request to the URI beacon.http-post as it is for the URI beacon.http-get. Figure 7 shows the HTTP request and response for a Team Server instance that initializes with the default Malleable C2 profile.

Image showing an HTTP request and response for a Team Server instance that initializes with the default Malleable C2 profile.
Figure 7. HTTP request and response configured with the default Malleable C2 profile.

Figure 8 shows an HTTP transaction when a GET request for beacon.http-post is sent to a Team Server instance that has initialized with the Gmail Malleable C2 profile.

"Image showing an HTTP transaction when a GET request is sent to a Team Server instance that has initialized with the Gmail Malleable C2 profile. "
Figure 8. HTTP request and response configured with the Malleable C2 Gmail profile.
URI Checksum

Team Server utilizes a custom one-byte checksum of the request URI as a condition to serve the 32-bit or 64-bit version of the Beacon binary. A simple checksum algorithm implemented in Java named checksum8 is used to calculate the checksum of the request URI.

As shown in Figure 9, for 32-bit payloads, the code compares the URI checksum result to the literal integer 92L (where the L suffix is Java syntax for integer type long). For 64-bit payload requests, the algorithm compares the checksum to 93L.

Image showing code to check the URI checksum. For 32-bit payloads, the code compares the URI checksum result to the literal integer 92L. For 64-bit payload requests, the algorithm compares the checksum to 93L.
Figure 9. Code to check the URI checksum.

When a user sends a GET request to a Team Server, the URI is passed to checksum8 and is compared to both integer values 92L and 93L. If the checksum satisfies one of the conditions, the server will respond with the raw bytes of the appropriate Beacon binary.

Figure 10 details an example of a URI that computes to a value that satisfies the checksum8 condition, as well as the Team Server’s response with the Beacon binary payload. This information was extracted from Beacon configuration scripts, which continue to provide threat intelligence that is useful for preventing Cobalt Strike connections.

Image showing an HTTP GET request and response with a URI that satisfies checksum8, as well as the Team Server’s response with the Beacon binary payload.
Figure 10. HTTP GET request and response with a URI that satisfies checksum8.
Random URI

If a user sends a randomized URI path, the Team Server will respond with HTTP status code 404 with Content-Length: 0. Figure 11 shows the HTTP response from a Team Server when a user sends a GET request with the URI randomURI.

Image showing an HTTP GET request and response from a Team Server for a randomURI path.
Figure 11. HTTP GET request and response for a randomURI path.

Active Probing Over DNS

Cobalt Strike’s DNS listener enables Beacon implants to covertly utilize the DNS protocol to communicate with the Team Server. The DNS-based Beacon uses the DNS TXT, AAAA, and A records for task monitoring and other related functions. The configuration is set by data channel mode in the Malleable C2 profile.

Figure 12 shows a DNS request originating from a Beacon querying the TXT record for the domain aaa.stage[.]xx.

Image showing a Beacon DNS request querying the TXT record for the domain aaa.stage[.]xx.
Figure 12. Beacon DNS request for TXT record.
Once the request is received, the Team Server responds with the base64-encoded Beacon binary in the TXT record response, as shown in Figure 13 below:

Image showing the Beacon DNS Listener response with the base64-encoded Beacon binary.
Figure 13. Beacon DNS Listener response (base64-encoded data).

Team Server Found in the wild

Based on the fingerprints and signals discovered, we utilized open source threat intelligence feeds including ZoomEye, Shodan and Censys to scour the internet in search of undetected Cobalt Strike Team Servers in the wild.

The following table details IP/port and URI indicators of compromise (IoCs) related to live Team Server instances we discovered in the wild in September 2022. We utilized Shodan’s feed service to collect IP addresses of potential Team Servers before sending 32-bit stager probes to test the daemon for positive indicators. Once a candidate returns the expected Cobalt Strike response, we initialize a TCP connection with netcat to test, verify and extract the served stager bytes as shown in Figure 14.

Image showing the successful HTTP/S probing for Team Server via stager check.
Figure 14. Successful HTTP/S probing for Team Server via stager check.
IP Address:Port Payload Type GET-URI POST-URI
43[.]129[.]7[.]189:8080 windows-beacon_http-reverse_http /updates /aircanada/dark.php
117[.]50[.]37[.]182:80 windows-beacon_http-reverse_http /api/x /api/y
42[.]192[.]206[.]174:80 windows-beacon_http-reverse_http /dpixel /submit.php
194[.]37[.]97[.]160:80 windows-beacon_http-reverse_http /cx /submit.php
92[.]222[.]172[.]39:80 windows-beacon_http-reverse_http /ptj /submit.php
79[.]141[.]169[.]220:443 windows-beacon_http-reverse_http /pixel.gif /submit.php

Table 1. IP/port and URI IoCs related to live Team Server instances.

Conclusion

Cobalt Strike is a potent post-exploitation adversary emulator that continues to evade conventional next-generation solutions, including signature-based network detection. However, Advanced Threat Prevention’s inline deep-learning models and heuristic techniques provide defenses against Cobalt Strike Beacon and Team Server C2 communication before they occur.

The probing and fingerprint technology detailed in this publication is very efficient and reliable in identifying Cobalt Strike instances in the wild with a very high degree of certainty. A single modern network security appliance is not sufficient to provide comprehensive coverage against complex malicious tools such as Cobalt Strike. Only a combination of security solutions including firewalls, sandboxes, endpoint agents and cloud-based machine learning can integrate the required data to prevent advanced adversaries from mounting successful cyberattacks from end to end.

Palo Alto Networks customers receive protection from this kind of attack by the following:

If you think you may have been compromised 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

CS Samples

  • 50ea11254f184450a7351d407fbb53c54686ce1e62e99c0a41ee7ee3e505d60c

CS Beacon Samples

  • /lNj8
    • SHA256 hash:
      • e712d670382ad6f837feeb5a66adb2d0f133481b5db854de0dd4636d7e906a8e

CS Teamserver IP addresses

  • 92[.]255[.]85[.]93
  • 43[.]129[.]7[.]189
  • 117[.]50[.]37[.]182
  • 42[.]192[.]206[.]174
  • 194[.]37[.]97[.]160
  • 92[.]222[.]172[.]39
  • 79[.]141[.]169[.]220

Additional Resources

Cobalt Strike Training
Cobalt Strike Malleable C2 Profile
Cobalt Strike Decryption with Known Private Key
Cobalt Strike Analysis and Tutorial: How Malleable C2 Profiles Make Cobalt Strike Difficult to Detect
Cobalt Strike Analysis and Tutorial: CS Metadata Encoding and Decoding
Cobalt Strike Analysis and Tutorial: CS Metadata Encryption and Decryption
Cobalt Strike Attack Detection & Defense Technology Overview

Threat Brief: CVE-2022-3786 and CVE-2022-3602: OpenSSL X.509 Buffer Overflows

Posted on by Erica Naone

Executive Summary

On November 1, 2022, OpenSSL released a security advisory describing two high severity vulnerabilities within the OpenSSL library (CVE-2022-3786 and CVE-2022-3602). OpenSSL versions from 3.0.0 - 3.0.6 are vulnerable, with 3.0.7 containing the patch for both vulnerabilities. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

In the days leading up to the security advisory, many were saying these vulnerabilities had the potential to be as bad as the Heartbleed vulnerability, and even OpenSSL originally stated that CVE-2022-3602 was going to be rated critical. Several factors seem to indicate that these vulnerabilities will not be easy to exploit and pose much less risk than originally thought:

  • Both vulnerabilities require a malicious X.509 certificate that has been signed by a valid certificate authority (CA).
  • A vulnerable server/client must parse client-side/server-side X.509 certificates to be affected by either of the CVEs.
  • OpenSSL 3.0.0 was released in September 2021 and is much less widely used than OpenSSL 1.x.x, limiting the attack surface significantly as compared to Heartbleed. Based on data from the attack surface management tool Cortex Xpanse, we estimate the number of internet-facing OpenSSL 3.x installs to be less than 1% of the total OpenSSL installs.
  • CVE-2022-3786 only allows bytes containing the character “.” (decimal 46) to be entered on the stack. Therefore an attacker has no ability to control the payload even though they can gain an arbitrary length overflow. This results in a denial of service (DoS) but not remote code execution.
  • CVE-2022-3602 does allow for an attacker to gain a 4-byte overflow. However, default compiler settings of the OpenSSL project enable stack cookies and – outside of some edge case scenarios – the 4-byte overflow will overwrite the stack cookie and crash the program on Windows.
    • Even without stack cookies enabled, successful exploitation will be highly dependent on the stack layout, which can change with compiler types and selected compiler options.
    • On Linux there appears to be padding of a seed variable before the stack cookie and the 4-byte overflow overwrites this uninitialized variable instead of the stack cookie, and it does not crash the program.

Palo Alto Networks recommends customers apply the latest patch, because both vulnerabilities have been shown to cause a denial of service at the very least. There is publicly available proof-of-concept code that will enable anyone who manages to create a malicious certificate and successfully sign it, to crash unpatched servers.

OpenSSL is also distributed as source code, so compiler options are completely up to the end user, who may opt out of modern memory mitigations such as stack cookies, ASLR, DEP/NX, etc. Such decisions would make exploitation easier and raise the risk of remote code execution for CVE-2022-3786.

Palo Alto Networks customers receive protections from and mitigations for CVE-2022-3786 and CVE-2022-3602 in a variety of ways, including the following:

  • Next-Generation Firewalls and Prisma Access with an Advanced Threat Prevention security subscription can automatically block related sessions.
  • A Cortex XSOAR playboook can help automate remediation.
  • Cortex XDR customers receive protections against remote code execution memory corruption exploits.
  • XQL queries provided below can be used with Cortex XDR to help track attempts to exploit these CVEs.
  • Cortex Xpanse customers can identify impacted versions through its “Insecure OpenSSL [CVE-2022-3602 and CVE-2022-3786]” policy.
  • Prisma Cloud customers can identify vulnerable resources under the vulnerabilities tab.
Vulnerabilities Discussed CVE-2022-3602, CVE-2022-3786

Details of the Vulnerability

As described by OpenSSL in a security advisory, both vulnerabilities (CVE-2022-3786 and CVE-2022-3602) are “triggered through X.509 certificate verification, specifically name constraint checking.” They also note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate, or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.

Both vulnerabilities occur within the ossl_punycode_decode function of the OpenSSL library.

Both vulnerabilities require the following to successfully exploit:

  • A malicious X.509 certificate that is signed by a valid CA
  • A vulnerable server that is parsing the client-side TLS certificate

The malicious certificate will have a subjectAltName that specifies the otherName field with an SmtpUTF8 email address. The certificate will also have a namedConstraint field with an email address that includes punycode. These two certificate items combined allow the parsed certificate data to reach the ossl_punycode_decode function within the OpenSSL library. The namedConstraint field will contain the payload that is decoded to a 513 byte overflow.

The vulnerability described in CVE-2022-3786 allows an attacker to achieve a stack overflow of arbitrary length, which is limited to the “.” character (decimal 46), by crafting a malicious email address within the attacker-controlled certificate as described above.

The vulnerability described in CVE-2022-3602 is an off-by-one vulnerability that allows an attacker to obtain a 4-byte overflow on the stack by crafting a malicious email address within the attacker-controlled certificate as described above. On Windows systems the overflow will either result in a crash (most likely scenario) or a potential remote code execution (much less likely).

OpenSSL distributes the OpenSSL library with stack cookies enabled by default. Testing of CVE-2022-3602 by OpenSSL and external researchers has shown the 4-byte overflow will overwrite the stack cookie resulting in a crash. However, OpenSSL is distributed as source and therefore compiler options are completely up to the end user, who may opt out of modern memory mitigations such as stack cookies, ASLR, DEP/NX, etc. Such decisions would make exploitation easier and raise the risk of remote code execution for CVE-2022-3786.

On Linux systems, research has shown there is an uninitialized seed value on the stack just before the stack cookie. This uninitialized seed value on Linux systems gets overwritten and no ill effects have been witnessed. This vulnerability received quite a bit of attention in the week leading up to the security advisory, and several excellent blogs describe it in detail (in particular, posts from Datadog Security Labs and Colm MacCarthaigh).

Current Scope of the Attack

There are no known instances of exploitation of either of these vulnerabilities. Proof of concept code does exist that results in crashing of the process. Assuming an attacker is able to craft a certificate signed by a valid CA, denial of service attacks would be possible.

Interim Guidance

Update to the most recent version of OpenSSL as soon as possible. OpenSSL also recommends that organizations operating TLS servers should consider disabling TLS Client Authentication if it is being used, until patches are applied.

Conclusion

OpenSSL’s latest security bulletin describes two memory corruption vulnerabilities that initially were thought to be critical and potentially as bad as the Heartbleed vulnerability (at least in the case of CVE-2022-3602). Ultimately both were rated high risk and deemed not likely to result in remote code execution.

Based on OpenSSL’s blog post on the issue, they and several external researchers (Datadog, Colm MacCarthaigh and unnamed researchers who assisted OpenSSL during their investigation), have done extensive research that supports this conclusion. Although this was probably the best outcome we could have hoped for on such a widely used library, Palo Alto Networks still recommends customers apply the latest patch. Both vulnerabilities have been shown to cause a denial of service at the very least. There is also at least one publicly available proof of concept that will enable anyone who manages to create a malicious certificate, and successfully sign it, to crash unpatched servers.

Palo Alto Networks Product Protections for OpenSSL Vulnerabilities

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

If you think you may have been compromised 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

Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention

Both Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) and Prisma Access with an Advanced Threat Prevention security subscription can automatically block sessions related to CVE-2022-3602 using Threat ID 93212 (Application and Threat content update 8638).

Cortex XSOAR Automated OpenSSL Vulnerability Management

The related Cortex XSOAR automation playbook can help you:

  • Automate incident data enrichment
    • Tag CVE indicators
    • Link indicators to incidents in your environment
  • Automate endpoint hunting
    • Hunt for Windows OS and/or Linux OS endpoints and retrieve OS endpoint IDs
    • Hunt for active processes running OpenSSL 3.x running in the above mentioned OS environments, Azure Sentinel logs and/or Splunk
  • Take remediation action
    • Download the latest version of OpenSSL
    • Install the latest version of OpenSSL across relevant endpoints
  • Notify analysts
    • Send analysts a notification if further investigations are needed
Image showing a sample section of the XSOAR automation playbook
Figure 1. A sample section of the Cortex XSOAR playbook designed to help with OpenSSL vulnerabilities.

This playbook is part of the Rapid Response Pack, which includes various playbooks for trending vulnerabilities and threats. The Cortex XSOAR playbook for CVE-2022-3786 and CVE-2022-3602 is now available in the Cortex Marketplace.

Cortex XDR

Cortex XDR customers receive protections against remote code execution memory corruption exploits (including those that may be possible in relation to these vulnerabilities) through its multi-layered security approach.

Cortex XDR customers can also make use of the XQL queries suggested by the Managed Threat Hunting team in the section below to search for signs of exploitation.

Unit 42 Managed Threat Hunting Queries

The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below.

Host Insights indexes endpoint host files with the Search and Destroy feature, enabling analysts to sweep across endpoints in near-real time to rapidly locate files, such as vulnerable OpenSSL software.

Cortex XDR Pro endpoint customers without Host Insights can search for the presence of OpenSSL using the following query:

Cortex XDR customers with Unit 42 managed services subscriptions, including Unit 42 Managed Threat Hunting and Unit 42 Managed Detection and Response, automatically received a Threat Impact Report with technical details and guidance.

Cortex Xpanse

Cortex Xpanse customers can identify impacted versions through its “Insecure OpenSSL [CVE-2022-3602 and CVE-2022-3786]” policy. The policy is available to all customers with a default state of On.

Screenshot showing Cortex Xpanse Insecure OpenSSL policy
Figure 2. Cortex Xpanse "Insecure OpenSSL [CVE-2022-3602 and CVE-2022-3786]" policy.

Prisma Cloud Vulnerability Management

If you are using Prisma Cloud, you can detect affected resources under the Vulnerabilities tab. The scan automatically detects and alerts on vulnerable entities with the vulnerable OpenSSL package.

You can also search for CVE-2022-3786 and CVE-2022-3602 through the Vulnerability Explorer to list the affected resources in your environment.

Image showing detection of CVE-2022-3602 in the Vulnerability Explorer within Prisma Cloud
Figure 3. CVE-2022-3602 in Prisma Cloud.

Updated Nov. 4, 2022, at 8 a.m. PT. 

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow