BREEZE COMET: Breaching Financial Systems and Executing Fraudulent Transfers Using mTLS Credentials

1. Basic Information Article Title: 'Breeze Comet' Tears Into Brazilian & Global Financial Systems Publisher: Dark Reading Publication Date: 2026-09-03 Source: Dark Reading Related Information Source: Google Threat Intelligence Group research Related Malware, Threat Groups, CVEs, and Products: BREEZE COMET, UNC5669, Plump Spider, SHADOW-AETHER-064, COBALTSPIN, LIGHTPAINT, MILDFROST, KICKPLATE, XWORM, REALBREEZE, Pix, STR, Boleto, Active Directory, Kubernetes, JBoss AS Severity: High Review Update: 2026-09-05 Content review: Clarified confidence in insider recruitment, the 24-48 hour starting point, the entity evaluating LLM usage, the meaning of unauthorized transactions exploiting legitimate APIs, and success criteria. Revised "Victim and Administrator Perspective" to describe observable events on screens, logs, and devices, along with their observation conditions. 2. Executive Summary BREEZE COMET gains entry through multiple vectors and connects to financial systems using custom backdoors and SOCKS5 tunnels to execute fraudulent transfers. Cases have been reported where hundreds of unauthorized transactions were executed within 24 to 48 hours after establishing access to financial applications. 3. Attack Flow Summary of Intrusion and Fraudulent Transfer Flow from Multiple Cases The attacker gains entry via password spraying, vishing disguised as IT support, or connecting unauthorized hardware. Exploitation of vulnerable JBoss AS instances is noted in Trend Micro's report. Each vector is treated as a separate incident. The attacker maintains access using RMM tools, XWORM, and custom backdoors. The attacker searches for high-privileged accounts and mTLS credentials within Active Directory, cloud, and CI/CD environments. The attacker uses COBALTSPIN's reverse SOCKS5 tunnel to connect to targets within the financial network, using the compromised environment as a stepping stone. The attacker abuses high-privileged accounts to access core financial applications. mTLS credentials play a critical role in authenticating payment instructions. In reported cases, hundreds of unauthorized transactions were executed in two waves within 24 to 48 hours after access to the financial application was established. This time frame does not measure the duration from initial compromise. 4. Attacker Location and Execution Point An external attacker on the Internet, or an individual capable of connecting unauthorized hardware to a store network. Code is executed on compromised endpoints, servers, or similar systems. Axur reported potential attempts to recruit insiders, but this is not treated as a successful intrusion via an insider. 5. Victim and Administrator Perspective Victims A phone call is received from someone claiming to be IT support, requesting the installation of AnyDesk. Administrators Inference: Authentication logs may show multiple login failures across several accounts in a short time. This alone does not indicate successful login or compromise. Inference: In environments tracking process and script execution, records may remain regarding the launch of portable RMM tools or in-memory execution via PowerShell. Tool retrieval from GitHub may also appear in proxy or network communication logs. Inference: If an unauthorized device using DHCP is connected, DHCP logs may show address assignments to unregistered terminals. In environments connected by COBALTSPIN, proxies or similar devices capable of identifying WebSocket traffic may show connection requests, and traffic flow logs may show persistent outbound communications. Inference: If file access auditing is enabled, unusual process access to mTLS private keys or administrative certificates may be recorded. Inference: If fraudulent transfers occur, authentication and transaction logs for payment APIs may show requests authenticated using legitimate credentials along with a high volume of transactions concentrated in a short period. If event logs are deleted, event logs recording the deletion or missing log records may be observed. 6. Success and Failure Conditions Success Conditions Gaining initial access and reaching high-privileged credentials in Active Directory, cloud, and CI/CD environments. Connecting to the payment network and utilizing mTLS credentials required for authentication. Unauthorized transactions are not blocked by fraud detection, approval processes, or other business controls. Failure Conditions and Risk Mitigation Inference: Restrict unauthorized device connections using 802.1X and port security. Inference: Manage RMM tools via allowlists and restrict the execution of unauthorized programs from user-writable directories. Inference: Protect mTLS private keys using Hardware Security Modules (HSMs) or similar solutions to prevent export. Prepare for potential compromise of the hosts utilizing these keys by requiring multi-stage approvals or out-of-band verification for payment instructions. 7. What Happens Upon Success Unauthorized transfers and financial losses abusing financial APIs and related systems. Cases involving hundreds of transactions have been reported. Unauthorized access to credentials related to Active Directory, cloud, CI/CD, and mTLS. Persistent access via multiple backdoors and tunnels. Evasion of investigation through the deletion of logs and attacker-created directories. 8. Observable Logs Email: Inference: Check for emails and downloads related to tax or receipt file distribution, in addition to call records of vishing. Do not universally assume email was the vector. Proxy/SWG/DNS: Communications to compromised municipal domains, public memo-sharing sites, externally exposed file listings, WebSockets, and DNS tunnels. Endpoint/EDR: Execution of AnyDesk, XWORM, REALBREEZE, COBALTSPIN, LIGHTPAINT, MILDFROST, KICKPLATE, PowerShell, schtasks.exe, and their associated parent-child processes. Identity/IdP: Password spraying, RDP/SMB usage by service accounts, and usage of high-privileged cloud tokens. Authentication results for mTLS certificates are confirmed in corresponding API and gateway records. SaaS/Cloud: Access to CI/CD secrets, addition of Kubernetes pods, modification of cloud resources, and payment API authentication and transaction records. Network: Inference: Confirm unauthorized DHCP assignments, SMB scans, reverse SOCKS5 traffic, and suspicious connections to financial system segments. 9. Attack Success Determination The following criteria are used to investigate individual environments and do not imply that success at every stage was observed in a specific article. Attack Attempt Observed (Success Unconfirmed): Confirm attempts such as vishing or password spraying. Network connectivity alone does not confirm code execution or successful authentication. User Action Confirmed: Confirm that the victim user installed an authorized/unauthorized RMM tool. Physical connection of unauthorized hardware is recorded as a foothold for a separate vector and is not assumed to be a user action. Initial Execution Confirmed: Confirm the execution of attack-related RATs, backdoors, PowerShell, or malicious Kubernetes pods. Malware Execution or Successful Authentication Confirmed: Confirm malware execution or successful authentication by the attacker using service accounts, cloud tokens, or mTLS certificates. Distinguish this from authentication attempts or normal usage. Data Theft or Session Compromise Confirmed: Confirm the acquisition of data and credentials by the attacker, or compromise of an authenticated session. Access records to financial applications alone do not constitute confirmed data theft. Subsequent Compromise Confirmed: Confirm fraudulent transactions, deletion of logs by the attacker, or lateral movement to other environments. 10. Investigation Playbook Inference: Investigation recommendations based on observations and functional descriptions in the article. Trigger: Unauthorized RMM tools, unauthorized DHCP assignments, suspicious mTLS private key access, or abnormal transaction volumes. Initial Verification: Preserve records of phone calls, logins, device connections, processes, and payment processing, aligned by timestamp. Endpoints: Inspect RMM tools, custom backdoors, PowerShell, services, scheduled tasks, and log deletion. Authentication and Cloud: Verify the use and authentication results of Active Directory service accounts, cloud tokens, CI/CD secrets, and mTLS certificates. Subsequent Activity: Track internal connections via SOCKS5, payment API operations, fund destinations, and coordinated activities across multiple environments. Containment: Isolate compromised endpoints and unauthorized devices, revoke accounts, tokens, and certificates, and block tunnels. Coordinate with the payment operations department to determine whether fraudulent transactions can be stopped or canceled. Classification of Findings: Distinguish between contact/attempts, foothold establishment, credential harvesting, internal connectivity, payment authentication success, and fraudulent transfers. 11. Defense and Detection Ideas Inference: The following are suggestions for operational application. Do not conclude that an environment has been successfully compromised based solely on matching individual logs or IOCs. Single Event: Service registration of unauthorized RMM tools. Single Event: Suspicious mTLS private key access or abnormal payment transactions. Time-Series Correlation: Correlate vishing/RMM installation -> credential discovery -> SOCKS5 -> financial API authentication -> fraudulent transactions -> log deletion. Threat Hunting: Cross-search for portable RMM tools, names and behaviors of tools like COBALTSPIN, unauthorized DHCP assignments, and CI/CD secret access. Log Gaps: Reconstructing the attack path becomes difficult if call records, NAC, EDR, CI/CD, certificate authentication, and payment logs are siloed. Prioritized Mitigations: Prioritize strengthening controls for mTLS private keys and payment processing, RMM governance, 802.1X, and minimizing CI/CD secrets. 12. Facts / Inference / Hypothesis Facts BREEZE COMET (formerly UNC5669) is tracked by GTIG as a threat activity compromising financial services, retail, and e-commerce organizations in Brazil, aiming to execute fraudulent transfers by abusing payment systems such as Pix, STR, and Boleto. There is overlap with activities publicly reported as Plump Spider and SHADOW-AETHER-064. Mandiant reports password spraying, AnyDesk installation via IT support vishing, and the connection of unauthorized hardware to store networks. Trend Micro's report, referenced by GTIG, also includes the exploitation of vulnerable JBoss AS instances. GTIG notes that Axur reported potential attempts to recruit insiders. This description alone does not confirm that recruitment or a resulting intrusion was successful. The threat actor searched for CI/CD pipeline credentials, API keys, and cloud access tokens, as well as mTLS credentials and administrative certificates required for financial API authentication. The Rust-based COBALTSPIN operates as a reverse SOCKS5 proxy over WebSockets, relaying connections to targets within isolated financial networks. Backdoors such as LIGHTPAINT, MILDFROST, and KICKPLATE maintained multiple access paths using VPNs, DNS tunnels, services, the registry, and scheduled tasks. Based on customer reports and third-party forensic analysis, Mandiant reported cases where hundreds of unauthorized transactions were executed in two waves within 24 to 48 hours after establishing access to financial applications. Mandiant evaluated that Large Language Models (LLMs) were used to create scripts for reconnaissance, credential validation, mass deployment, and data exfiltration, based on the structure of recovery scripts, detailed comments, and boilerplate runtime headers. This is treated as an evaluation from the source analysis. Inference Preventing final-stage fraudulent transfers requires business-side verification of payment instruction validity and mTLS client usage, in addition to detecting authentication and network compromises. Because the attack spans physical ports, Active Directory, cloud environments, CI/CD pipelines, and payment APIs, relying on logs from a single department makes it difficult to capture the full picture. Hypothesis Related infrastructure discovered outside Brazil may indicate intent for broader targeting. However, this does not imply that fraudulent transfer losses of a similar scale have been confirmed in other countries. 13. MITRE ATT&CK Mapping T1566 Phishing (High): Induced RMM installation via IT support vishing. T1078 Valid Accounts (High): Abused service accounts and high-privileged accounts. T1090.001 Proxy: Internal Proxy (Medium): Corresponds to candidates for connecting to internal targets via COBALTSPIN in the compromised environment. Differentiate between external communication with C2 and internal relaying. T1552.001 Unsecured Credentials: Credentials In Files (High): Searched for mTLS, API, and other credentials from CI/CD environments and host files. T1070.001 Indicator Removal: Clear Windows Event Logs (High): Cleared event logs to conceal traces of lateral movement and API operations. 14. Unknowns and Additional Investigation The number of victim organizations and total financial losses. Breakdown of methods used to acquire mTLS private keys and their storage locations. Distribution hashes and the full picture of C2 infrastructure for each backdoor. Whether insider recruitment was successful and whether it was used for intrusion. 15. Impact on Global SOCs and Enterprises While this incident targets payment methods specific to Brazil, the technique of abusing legitimate credentials and payment APIs to execute fraudulent transactions is a relevant threat for financial and payment services globally. Inference: Review store port 802.1X controls, RMM governance, reduction of lifespan for CI/CD secrets, protection of mTLS private keys, and out-of-band approval workflows to prevent fraudulent transfers. 16. Summary by Target Audience For SOCs: Cross-correlate RMM installation, credential discovery, SOCKS5 traffic, mTLS authentication, financial API calls, transactions, and log deletion. For Administrators: Consider implementing 802.1X, RMM allowlists, minimization of CI/CD secrets, protection of mTLS private keys, and multi-stage payment approvals. For Users: If a phone call claiming to be IT support requests the installation of remote desktop tools, hang up and call back using a known, trusted phone number to verify.