1. Executive summary
Google Threat Intelligence Group's 1 September 2026 report describes financially motivated BREEZE COMET intrusions affecting Brazilian financial-services, retail and electronic-commerce organisations. Mandiant's investigations connect enterprise and cloud access with theft of credentials used to reach payment systems and conduct fraudulent transfers. The report covers activity investigated since 2024; its publication is not a statement that every described operation occurred in September 2026. Likely (B2), defenders will obtain a more complete view by investigating the path from administrative access to transaction-capable identities than by waiting for encryption or a conventional extortion demand; this is our assessment of the documented objective and access chain.
2. Contextual background
Google describes BREEZE COMET as specialising in manipulation of banking software and payment systems in Brazil. Its analysis identifies access to financial-network infrastructure, transaction-authorising credentials and knowledge of processing arrangements as important to the operation. The targeted population includes organisations able to initiate or support financial transactions, not only institutions labelled as banks.
The report also discusses compromised infrastructure outside Brazil as a possible sign of broader intent. That assessment should not be converted into a claim that successful financial intrusions have been confirmed in every country hosting such infrastructure. This article retains the Brazilian focus supported by the investigations and makes no independent geographical attribution.
Our recommendation is to begin with the local transaction process. Identify which application or service can issue a payment instruction, which identity authorises it and who can administer that identity. Then map the administrative and development systems able to change those components. A business-process map and a network diagram answer complementary questions.
3. Technical analysis
Mandiant reports several initial-access methods across the investigated activity, including password spraying and support impersonation that persuaded users to install remote-management tools. Google describes compromised, apparently trustworthy websites being used for delivery and command infrastructure. The report also includes an observation of rogue hardware connected to retail networks. These are separate reported paths, not mandatory steps in one universal sequence.
The report describes searches of development and cloud environments for pipeline credentials, application programming interface (API) keys and privileged tokens. It also reports searches for mutual Transport Layer Security (mTLS) credentials and administrative certificates associated with financial applications. The security significance is the permission attached to the material, rather than whether it resembles a conventional user password.
Google describes internal movement through compromised service accounts, remote desktop access and file-sharing protocols, alongside custom tunnelling. Its COBALTSPIN tool provides a path towards internal financial API infrastructure. Our assessment is that a review confined to the first endpoint can miss the business function the operator is attempting to reach.
The investigation also describes redundant access through multiple custom backdoors and cloud persistence. That supports checking for more than one access mechanism before restoring trust. It does not establish that every reported malware family was deployed together in every incident; responders should record the evidence for the tools and persistence actually present in their environment.
The source also reports changes intended to preserve access and impair visibility, including firewall modifications associated with installed VPN software and clearing relevant event records. Our recommendation is to compare security and network configuration against approved changes as part of the investigation. A newly permitted connection can be consequential even when its software is legitimate, while missing local records should prompt collection from independent network and identity sources.
4. Impact assessment
The principal objective described by Google is fraudulent transfer activity rather than encryption. In one reported sequence, Mandiant's analysis, client reporting and third-party forensics connected access to core financial applications with two waves of hundreds of fraudulent transactions within 24–48 hours. This is a case observation, not a general promise of an available response window.
Our recommended impact assessment separates unauthorised infrastructure access, exposure of transaction credentials and confirmed financial instructions. Each requires evidence. A compromised host may expose a credential without proving it was used; an unusual transaction needs reconciliation with the business records and approval process. Keep those distinctions visible as the investigation develops.
Bring security, payment operations and fraud specialists into the same incident timeline. Agree how suspicious technical events relate to transaction activity, which system is authoritative for each record and who can halt or restrict processing safely. This is an operational-response recommendation, not a conclusion about financial loss at any unnamed organisation.
The report does not provide a complete global victim population. This article therefore offers no extrapolated loss total or infection rate and names no organisation from criminal claims. Prioritisation should follow the local exposure of transaction-capable identities and systems.
5. Observed tooling and detection opportunities
These tools are described in Google's report. A family name is an investigation label, not a substitute for a validated local artefact.
| Tool | Reported role | Useful defensive question |
|---|---|---|
| COBALTSPIN | Rust tunneller providing internal network access | Which internal services did the compromised host reach? |
| LIGHTPAINT | Java backdoor that installs and configures a legitimate VPN | Was the network service and its configuration authorised? |
| MILDFROST | Java backdoor with domain-name-system communications | What process and application account generated the traffic? |
| KICKPLATE | Nim backdoor using a Windows Update Health Tools disguise | Does service or startup activity match approved software? |
| BOATBEAM | Go backdoor presenting a web-server façade | Is the listening service part of the approved application? |
VPN means virtual private network. Legitimate remote-management or tunnelling software should be assessed in context rather than treated as inherently malicious. Compare installation, execution, configuration and initiating identity with the approved service inventory and support record.
Google reports credential searches and internal discovery, providing a basis for looking at access to sensitive configuration, unexpected service-account activity and unusual connections towards financial workloads. Our proposed hunt starts with a suspicious identity or host and traces its reachable services. Record which activity was observed and which part of the path remains a hypothesis.
For payment infrastructure, correlate administration changes with transaction processing and deployment records. A privileged action during a normal maintenance window still needs an authorised actor and purpose. Conversely, a scheduled batch or approved support session can explain activity that initially appears anomalous. Preserve the evidence supporting either conclusion.
6. Incident response guidance
Define a coordinated containment decision with payment operations. Establish which transaction functions are at risk and what restrictions can be applied without creating an uncontrolled operational failure. Avoid assuming that disconnecting the first detected endpoint ends access to the financial application.
Preserve relevant endpoint, identity, application and transaction records. Retain timestamps and record any clock differences. The investigation should connect access events to the actual credentials and application functions involved, rather than infer a sequence from unrelated alerts occurring on the same day.
Review credentials accessible from the affected systems and arrange controlled replacement or revocation where exposure is established. For transaction certificates and service identities, coordinate with the owning application and counterparties as appropriate. Confirm the running service uses the replacement material and that previous access has been invalidated. A change request marked complete is not, by itself, that confirmation.
Investigate additional persistence on connected hosts and cloud workloads. Google describes multiple access methods and malicious Kubernetes workloads in the historical activity. The scope of recovery should follow the permissions and observed movement, with each inclusion or exclusion documented. Do not assume all cloud workloads are affected merely because one credential was exposed.
Before returning to normal operation, validate the relevant transaction controls and the integrity of the restored systems. Reconcile suspicious instructions against business records. Record any unresolved interval in which processing or administrative activity cannot be fully reconstructed, so that later evidence can be assessed against a clear baseline.
7. ATT&CK context
The following are our mappings of reported behaviour to MITRE ATT&CK definitions. They do not mean that MITRE independently investigated BREEZE COMET.
| Technique | Source-supported basis |
|---|---|
| T1219: Remote Access Tools | Reported use of remote-management tools to obtain or retain access |
| T1078: Valid Accounts | Use of compromised service accounts within the environment |
| T1552.001: Credentials In Files | Searches for pipeline, application and financial-access credentials |
These categories help allocate monitoring responsibility, but they do not capture the entire business objective. The transaction-capable service and its authorisation controls should remain part of the analysis even when the underlying technique is a familiar form of account abuse.
For validation, use controlled accounts and benign transactions approved by the business owner. Test whether investigators can trace a service identity back to its administration and deployment path. There is no need to reproduce the reported malware or fraudulent transfer activity to test that visibility.
Network reachability and transaction authority should be tested separately. Google describes both access to financial infrastructure and credentials capable of authenticating transaction instructions as operational requirements. Our recommended exercise should establish whether a compromised administrative identity could satisfy either requirement, and which independent control would prevent it from satisfying the other. Record the result for the specific application and service account rather than generalising from a network-segmentation diagram.
8. Mitigation recommendations
Google recommends controls spanning remote-management software, physical network access, identity security, network segmentation, Kubernetes and secret management. Its guidance includes limiting unauthorised devices at branch networks and restricting access to financial workloads. Apply those controls to the locally verified access paths, with a named owner for exceptions.
Our recommendation is to separate administration of payment services from ordinary workstation activity. Determine which hosts and identities are permitted to manage those services and verify that the enforced configuration matches the design. Review alternate support and emergency routes as part of the same exercise.
Remove unnecessarily exposed credentials from build, source and application configuration, and retain an auditable means of providing required secrets. Review both read access and the ability to replace transaction credentials. An account that cannot issue payments directly may still deserve attention if it can change the component that does.
Finally, give security and fraud teams a shared escalation path. Define the technical and business evidence needed to investigate an unusual transfer alongside suspicious system access. Exercise the handoff so neither team assumes the other owns an ambiguous case.
9. Historical context and limits
The report describes evolving activity across several years and Google reports evidence of generative-AI assistance in tool development. Its assessment cites characteristics of recovered scripts and operational tooling. That does not establish that an autonomous model independently selected targets or executed a complete intrusion.
Code and tool names should remain scoped to the source's observations. This article does not merge BREEZE COMET with other researchers' clusters on the basis of overlap or a shared utility. Similar access methods are useful defensive comparisons without proving a common operator.
10. Outlook and assessment
Likely (B2), investigations that follow privileges into payment functions will provide a more useful measure of risk than malware counts alone. The judgement rests on Google's documented focus on credentials, internal access and transaction processing, rather than a prediction about a particular institution.
Evidence of unexplained credential replacement, new administration paths or suspicious financial instructions should sharpen that investigation. Evidence that changes were authorised and transaction controls remained effective would narrow the finding. Preserve those alternatives until the technical and business records support a conclusion.
