BREEZE COMET attackers use stolen mTLS credentials for fraudulent transfers, Google TI finds

Google's Threat Intelligence Group has documented a fraud campaign, tracked as BREEZE COMET, in which attackers compromise financial institutions, hunt for mutual TLS credentials, and then authenticate to payment systems as legitimate clients. According to Dark Reading's coverage of the research, in reported incidents the actors executed hundreds of unauthorized transactions within two days of reaching core financial applications. The Brazilian financial ecosystem, including the Pix instant payment rail, is among the targets, alongside global systems.

How the intrusions unfold

The research describes several distinct entry vectors, each treated as its own incident type: password spraying against user accounts, vishing calls in which the attacker poses as IT support and persuades staff to install remote-access software such as AnyDesk, and the physical connection of unauthorized hardware to retail store networks. Trend Micro separately noted exploitation of vulnerable JBoss AS application server instances.

Once inside, the actors establish persistence using RMM tooling, the XWORM malware family, and custom backdoors. From that foothold they search Active Directory, cloud environments and CI/CD pipelines for high-privileged accounts and mTLS credentials. A component the research calls COBALTSPIN opens a reverse SOCKS5 tunnel, pivoting from the compromised environment into financial network segments.

The final stage is abusing privileged accounts to reach core financial applications, where the stolen mTLS credentials authenticate payment instructions. In the reported cases the actor pushed through unauthorized transactions in two waves within 24 to 48 hours of gaining access to the financial application — a window measured from that point, not from the initial intrusion — and then deleted logs to cover the trail. Google associates the activity with clusters it tracks as UNC5669 and Plump Spider, and Brazilian security firm Axur reported attempts to recruit insiders, though this is not treated as a confirmed entry route.

Why mTLS credentials are the prize

Mutual TLS authenticates both ends of a connection with certificates, and many payment APIs treat possession of a valid client certificate and its private key as proof that a legitimate application is calling. That is exactly what makes stolen mTLS material valuable: once the key is in attacker hands, the payment infrastructure sees perfectly valid credentials, and fraudulent instructions arrive looking indistinguishable from routine, authorized traffic.

Signals defenders can monitor

The reporting and accompanying analysis lay out observable evidence worth hunting for. Authentication logs may show concentrated login failures across many accounts in a short period. Endpoint telemetry, where process and script execution is tracked, may capture portable RMM tools launching or PowerShell executing in memory, sometimes preceded by tool downloads from GitHub visible in proxy logs. DHCP logs can reveal address assignments to unregistered devices. Where proxies can identify WebSockets, connection requests from COBALTSPIN and continuous outbound traffic may appear in flow logs. If file access auditing is enabled, unusual process access to mTLS private keys or administrative certificates may be recorded. And critically, payment API logs may show transactions authenticated by legitimate credentials but clustered in an unusually short, high-volume burst — with deleted or missing event logs, or events recording the deletion itself, as a follow-on marker.

Practical defenses

The analysis suggests several mitigation lines. Enforce 802.1X and port security to keep rogue devices off the network. Manage RMM tools through allowlists and block program execution from user-writable directories. Store mTLS private keys in hardware security modules so they cannot simply be exported from a compromised host. Most importantly, plan for host-level key compromise: require multi-step approvals or out-of-band verification for payment instructions, so that a valid certificate alone cannot authorize a transfer. Monitoring access to CI/CD secrets, the creation of Kubernetes pods, and changes to cloud resources also matters, since those are the stores the actors rummage through for privileged material.

Why it matters

BREEZE COMET shows that in machine-to-machine finance, possession is effectively authorization. The assumption that a valid certificate means a legitimate caller collapses the moment the endpoint holding the key is compromised — and in this campaign endpoints fall to phone calls, sprayed passwords and rogue hardware rather than exotic exploits. Two implications stand out. First, key protection has to move into hardware, and payments need transaction-level backstops such as approval workflows and out-of-band checks, because certificate authentication cannot distinguish a thief holding the key from its rightful owner. Second, the operating tempo — hundreds of transfers inside two days, followed by log wiping — leaves security teams an extremely short detection window, which makes burst-style anomaly detection on payment APIs and rapid alerting on log deletion the difference between an incident and a loss.