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 Intelligence Source: Google Threat Intelligence Group research
• Related Malware, Threat Groups, CVEs, 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 the confidence level of insider threat recruitment, the 24-48 hour timeline origin, the evaluation entity for LLM usage, the meaning of unauthorized transactions via legitimate APIs, and adjusted success criteria and Japanese terminology. Updated "Victim/Administrator Visibility" to describe observable events in screens, logs, and devices along with observation conditions. Explicitly structured "Impact on SOCs" as an analytical section, summarizing lessons learned from the case study in a clear and concise format.

2. Executive Summary

BREEZE COMET breaches environments through multiple vectors and connects to financial systems using custom backdoors and SOCKS5 tunnels to conduct unauthorized fund transfers. In reported cases, the threat actor executed hundreds of unauthorized transactions within 24 to 48 hours of establishing access to the target financial applications.

3. Attack Flow

Intrusion and Fraudulent Transfer Flow Based on Multiple Incidents

1. Gain initial access via password spraying, vishing posing as IT support, or connecting unauthorized hardware. Exploitation of vulnerable JBoss AS instances is noted in Trend Micro's report. Treat each vector as a separate incident.
2. Maintain access using RMM tools, XWORM, or custom backdoors.
3. Search for high-privileged accounts and mTLS credentials across Active Directory, cloud environments, and CI/CD pipelines.
4. Use COBALTSPIN's reverse SOCKS5 tunnel to pivot from the compromised environment and connect to targets within the financial network.
5. Abuse high-privileged accounts to access core financial applications. mTLS credentials are critical for authenticating payment instructions.
6. In reported incidents, the actor executed hundreds of unauthorized transactions in two waves within 24 to 48 hours of gaining access to the financial application, followed by log deletion. This timeframe is distinct from initial intrusion.

4. Threat Actor Position and Execution Location

• External threat actors over the internet, or individuals capable of plugging unauthorized devices into retail store networks. Code executes on compromised endpoints and servers.
• Axur reported attempts to recruit insiders, but this is not treated as confirmed successful entry via an insider.

5. Visibility for Victims and Administrators

Victims

• Receive a phone call from someone posing as IT support, requesting the installation of AnyDesk.

Administrators

• Inference: Authentication logs may show concentrated login failures for multiple accounts within a short period. 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 communication logs.
• Inference: When unauthorized DHCP-using devices connect, DHCP logs may show address assignments to unregistered terminals. In environments connected by COBALTSPIN, connection requests may appear in proxies capable of identifying WebSockets, and continuous outbound traffic may appear in flow logs.
• Inference: If file access auditing is enabled, unusual process access to mTLS private keys or administrative certificates may be recorded.
• Inference: If unauthorized transfers occur, payment API authentication and transaction records may show processing authenticated by legitimate credentials, accompanied by a large volume of transactions concentrated in a short timeframe. If event logs are deleted, events recording the deletion or missing records may be visible.

6. Success and Failure Conditions

Success Conditions

• Obtain initial access and reach high-privileged credentials in Active Directory, cloud, or CI/CD environments.
• Connect to the payment network and utilize the required mTLS credentials for authentication.
• Fraudulent transactions are not blocked by operational controls such as fraud detection or approval workflows.

Failure Conditions / Risk Mitigation

• Inference: Restrict unauthorized device connections using 802.1X and port security.
• Inference: Manage RMM tools via allowlists and restrict unauthorized program execution from user-writable directories.
• Inference: Protect mTLS private keys using hardware security modules (HSMs) to prevent external extraction. Prepare for host-level compromise where keys are accessible by requiring multi-step approvals or out-of-band verification for payment instructions.

7. What Happens Upon Success

• Unauthorized fund transfers and financial loss via abused payment APIs and other systems. Cases of hundreds of executed transactions have been reported.
• Unauthorized access to credentials related to Active Directory, cloud, CI/CD, and mTLS.
• Persistent access maintained via multiple backdoors and tunnels.
• Investigation hindrance through the deletion of logs and actor-created directories.

8. Observable Logs

• Email: Inference: In addition to vishing call records, check for emails and file downloads related to tax or invoice lures. Do not assume all intrusions occurred via email.
• Proxy/SWG/DNS: Traffic to compromised municipal domains, public memo-sharing sites, externally exposed file lists, WebSockets, and DNS tunnels.
• Endpoint/EDR: Execution of AnyDesk, XWORM, REALBREEZE, COBALTSPIN,LIGHTPAINT, MILDFROST, KICKPLATE, PowerShell, schtasks.exe, and their parent-child process relationships.
• Identity/IdP: Password spraying, RDP/SMB usage by service accounts, and usage of high-privileged cloud tokens. mTLS certificate authentication results must be verified via corresponding API and gateway logs.
• SaaS/Cloud: Access to CI/CD secrets, creation of Kubernetes Pods, modification of cloud resources, and payment API authentication/transaction records.
• Network: Inference: Check for DHCP assignments to unauthorized devices, SMB scans, reverse SOCKS5 traffic, and suspicious connections to financial system segments.

9. Attack Success Assessment

The following criteria are used to investigate individual environments and do not imply that every stage of success was observed in every article reference.

• 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 the installation of RMM by the victimized user. Physical connection of unauthorized devices should be logged as a separate intrusion vector and not assumed to be user-driven action.
• Initial Execution Confirmed: Confirm the execution of attack-related RATs, backdoors, PowerShell, malicious Kubernetes Pods, or similar components.
• Malware Execution or Successful Authentication Confirmed: Confirm malware execution or successful authentication by the actor 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, or the compromise of authenticated sessions by the actor. Access records to financial applications alone do not confirm data theft.
• Subsequent Compromise Confirmed: Confirm fraudulent transactions, log deletion by the actor, or lateral movement to other environments.

10. Investigation Playbook

Inference: Investigation proposals based on article observations and functional descriptions.

• Trigger: Unauthorized RMM, DHCP assignment to unauthorized devices, suspicious mTLS private key access, or abnormal transaction volumes.
• Initial Verification: Preserve records of phone calls, logins, device connections, processes, and payment processing with synchronized timestamps.
• Endpoints: Investigate RMM, custom backdoors, PowerShell, services, scheduled tasks, and log deletion.
• Authentication & Cloud: Verify the usage and authentication results of Active Directory, service accounts, cloud tokens, CI/CD secrets, and mTLS certificates.
• Post-Exploitation Activity: Track internal connections via SOCKS5, payment API operations, transfer 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 payments department to verify whether fraudulent transactions can be stopped or canceled.
• Categorize Findings: Differentiate between contact/attempts, establishing a foothold, credential theft, internal connectivity, successful payment authentication, and fraudulent transfers.

11. Defense and Detection Ideas

Inference: The following are operational application proposals. Do not confirm a successful breach based solely on matching individual logs or IOCs.

• Single Event: Registration of unauthorized RMM services.
• Single Event: Suspicious mTLS private key access or anomalous 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, DHCP assignments to unauthorized devices, and access to CI/CD secrets.
• Log Gaps: Reconstructing the attack path is difficult if call records, NAC, EDR, CI/CD, certificate authentication, and payment logs are fragmented.
• Priority 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 threat activity compromising financial services, retail, and e-commerce organizations in Brazil, targeting unauthorized fund transfers by abusing payment systems such as Pix, STR, and Boleto. There is overlap with activity published as Plump Spider and SHADOW-AETHER-064.
• Mandiant reports password spraying, vishing impersonating IT support to deploy AnyDesk, and connecting unauthorized devices to retail 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 resulting intrusion was successful.
• The threat actor searched for pipeline credentials in CI/CD environments, API keys, 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 segmented financial networks.
• Backdoors such as LIGHTPAINT, MILDFROST, and KICKPLATE maintained multiple access paths using VPNs, DNS tunnels, services, registries, 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 of establishing access to financial applications.
• Mandiant assessed that LLMs were used to create scripts for reconnaissance, credential verification, mass deployment, and data exfiltration, based on the structure of retrieval scripts, detailed comments, and boilerplate runtime headers. This is treated as an assessment from the source analysis.

Inference

• Preventing final-stage unauthorized transfers requires business-side verification of payment instruction validity and mTLS client usage, in addition to detecting authentication and network compromises.
• Because the activity spans physical ports, Active Directory, cloud, CI/CD, and payment APIs, logs from a single department are insufficient to capture the full picture.

Hypothesis

• Related infrastructure discovered outside Brazil may indicate intent for wider targeting. However, this does not imply that unauthorized transfer losses of the same scale have been confirmed in other countries.

13. MITRE ATT&CK Mapping

• T1566 Phishing (High): Induced RMM installation via vishing impersonating IT support.
• T1078 Valid Accounts (High): Abused service accounts and high-privileged accounts.
• T1090.001 Proxy: Internal Proxy (Medium): Candidate matching connections to internal targets routed through COBALTSPIN in the compromised environment. Differentiate between external C2 communications and internal relay traffic.
• T1552.001 Unsecured Credentials: Credentials In Files (High): Searched for mTLS and API credentials in CI/CD environments and host files.
• T1070.001 Indicator Removal: Clear Windows Event Logs (High): Cleared event logs to hide traces of lateral movement and API operations.

14. Unknowns and Additional Investigations

• Total number of victimized organizations and total financial losses.
• Breakdown of methods used to acquire mTLS private keys and their storage locations.
• Distribution hashes for each backdoor and the overall C2 infrastructure.
• Whether insider recruitment succeeded and whether it was used for intrusion.

15. Impact on SOCs and Organizations

GTIG's case study demonstrates that access to payment APIs using legitimate credentials can still lead to unauthorized transactions. For financial and payment institutions, it is critical to link authentication and communication logs with the content of payment instructions, and to review out-of-band approval workflows.

Threat actors are also searching for CI/CD secrets and mTLS credentials. Organizations should audit retail port 802.1X controls, RMM usage restrictions, the minimization of CI/CD secrets, and the protection of mTLS private keys as vital measures against paths leading to payment systems.

16. Summary by Target Audience

• For SOCs: Cross-correlate RMM installation, credential discovery, SOCKS5 traffic, mTLS authentication, payment 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-step payment approval workflows.
• For Users: If a phone call claiming to be IT support requests the installation of remote-control tools, hang up and call back using a known, official channel to verify.