Google Threat Intelligence Group reveló el 1 de septiembre de 2026 una campaña de BREEZE COMET contra bancos, procesadores, comercios, plataformas de comercio electrónico y proveedores de tecnología financiera en Brasil. El objetivo no es cifrar sistemas ni robar una base de datos para extorsionar: el actor busca comprender y manipular los procesos que autorizan pagos para ejecutar transferencias fraudulentas.
Mandiant investiga esta actividad desde 2024 y describe un adversario que combina acceso técnico, engaño telefónico, herramientas de administración remota, malware propio y conocimiento de la operación financiera. Las organizaciones observadas tenían capacidad para transaccionar mediante software bancario, APIs y sistemas como Pix, STR y Boleto. Esa posición explica por qué una cuenta privilegiada, un certificado de autenticación mutua o una integración de pagos puede valer más que miles de registros personales.
No hay evidencia pública de que BREEZE COMET esté atacando entidades colombianas o españolas. La advertencia para Colombia proviene de la similitud regional: fintech, adquirentes, agregadores, comercios y proveedores locales también conectan identidades corporativas, llaves criptográficas, APIs y procedimientos humanos para mover dinero. Google añade que la infraestructura del actor podría indicar intención de ampliar su huella hacia otros países de Latinoamérica y África. Esa observación expresa una posibilidad, no una campaña confirmada.
Qué confirmó la investigación sobre BREEZE COMET
GTIG identifica al grupo como un actor con motivación financiera, antes rastreado como UNC5669, y relaciona su actividad con operaciones publicadas bajo los nombres Plump Spider y SHADOW-AETHER-064. Desde 2024, Mandiant investigó compromisos en servicios financieros, retail y comercio electrónico de Brasil. El patrón común era el acceso a organizaciones capaces de iniciar o procesar transferencias.
El adversario necesita mantener presencia en varias cuentas de Active Directory o de nube, aprender los procedimientos de transferencia y reconocer integraciones, límites, controles antifraude y ventanas operativas. Para sostener ese trabajo en varios entornos comprometidos a la vez, desarrolló malware destinado a automatizar reconocimiento, movimiento lateral, persistencia, control remoto y extracción de información.
Google documentó que, en al menos un caso, BREEZE COMET ejecutó dos oleadas de cientos de transacciones fraudulentas durante las 24 a 48 horas posteriores a obtener acceso al núcleo financiero. Otra intrusión produjo un robo de decenas de miles de dólares. La fuente no atribuye esas transacciones a un único riel específico; presentar todas como operaciones Pix excedería la evidencia disponible.
Una cadena que une personas, endpoints y sistemas de pago
Los accesos iniciales observados muestran que el riesgo financiero no empieza siempre en una API. Mandiant vio pulverización de contraseñas y llamadas en las que el atacante se hacía pasar por soporte técnico para convencer al usuario de instalar AnyDesk. Axur corroboró el uso de phishing por voz y señaló intentos de reclutar personal interno. También se utilizaron sitios gubernamentales o municipales comprometidos para alojar malware, explotación de servidores JBoss y, en entornos de retail, hardware no autorizado conectado directamente a la red.
| Etapa | Comportamiento documentado | Control que debe probarse |
|---|---|---|
| Entrada | Contraseñas rociadas, vishing, AnyDesk, vulnerabilidades y dispositivos físicos no autorizados. | MFA resistente al phishing, mesa de ayuda verificable, exposición controlada y admisión de red. |
| Expansión | Persistencia en identidades, nube y varios entornos comprometidos. | Privilegio mínimo, segmentación, EDR y correlación entre identidad, endpoint y red. |
| Descubrimiento | Búsqueda de procesos financieros, secretos de CI/CD, APIs y certificados mTLS. | Bóveda de secretos, trazabilidad de lectura y separación entre desarrollo y pagos. |
| Fraude | Interacción con software financiero y ejecución coordinada de transferencias. | Doble control independiente, límites adaptativos y validación fuera del canal comprometido. |
La tabla revela una consecuencia práctica: ningún producto aislado cubre la cadena completa. Un control de fraude puede aprobar una operación técnicamente válida si el actor ya controla la identidad, el certificado y el procedimiento. Un EDR puede alertar sobre una herramienta remota, pero el analista necesita saber si ese endpoint puede alcanzar el entorno que firma pagos. La defensa debe correlacionar esas capas.
El verdadero objetivo son las capacidades de transacción
BREEZE COMET busca organizaciones con permisos para operar mediante software bancario, APIs y sistemas de pago. Para llegar a ese punto necesita acceso a la Red del Sistema Financiero Nacional de Brasil, material mTLS, cuentas privilegiadas y conocimiento del proceso. Los certificados de autenticación mutua son especialmente sensibles porque prueban la identidad de una aplicación ante otra; si se extraen junto con su clave privada y el contexto operativo, pueden convertir una sesión maliciosa en una conexión aparentemente legítima.
La investigación también halló búsquedas en plataformas de integración y entrega continua. El actor revisaba configuraciones y código en busca de credenciales embebidas, tokens cloud, claves de API y secretos relacionados con pagos. El problema no es solo que exista una contraseña en un repositorio: es que el pipeline de software suele unir desarrollo, artefactos, despliegue y producción. Una identidad sobredimensionada puede atravesar varias fronteras sin generar el tipo de alerta que produciría un malware ruidoso.
Por eso, el inventario debe describir capacidades, no únicamente activos. La pregunta no es “¿tenemos un servidor de pagos?”, sino “¿qué persona, servicio, certificado o job puede preparar, autorizar, firmar, transmitir, conciliar o revertir una operación?”. Cada capacidad requiere propietario, límite, registro y una segunda señal independiente.
Un arsenal propio que reduce el trabajo manual
GTIG atribuye al actor herramientas personalizadas con nombres como COBALTSPIN, LIGHTPAINT, MILDFROST, KICKPLATE, BOATBEAM y REALBREEZE. Cumplen funciones de puerta trasera, descubrimiento, persistencia, movimiento y automatización dentro de los entornos comprometidos. Nombrarlas ayuda a los equipos de detección, pero una defensa basada solo en hashes o archivos conocidos llegará tarde si el operador modifica sus componentes.
La fuente también presenta evidencia de uso de modelos generativos para apoyar el desarrollo de malware y scripts. Eso no significa que una IA ejecute autónomamente el fraude. El hallazgo relevante es más sobrio: el actor puede acelerar tareas de programación, adaptar herramientas y operar con mayor escala. Los controles deben detectar comportamiento —creación de servicios, ejecución remota, acceso a secretos, conexiones inusuales y cambios de cuentas— aunque el código que lo produce cambie.
Un programa continuo de gestión de vulnerabilidades ayuda a cerrar superficies como servidores expuestos y aplicaciones desactualizadas, pero debe conectarse con configuración, identidad y criticidad. Una vulnerabilidad en un sistema sin ruta hacia pagos no tiene la misma urgencia que un acceso remoto permitido desde el endpoint que administra certificados de producción.
Señales que una entidad financiera o comercio debe correlacionar
- Mesa de ayuda: llamadas que solicitan instalar RMM, saltarse un procedimiento o aceptar una sesión sin ticket verificable.
- Identidad: intentos distribuidos de contraseña, nuevos factores, autenticaciones desde infraestructura atípica y cambios de grupos privilegiados.
- Endpoint: AnyDesk u otra administración remota fuera del catálogo, servicios persistentes, herramientas transferidas y procesos hijos anómalos.
- Red física: nuevas direcciones, puertos activados, equipos sin inventario y conexiones desde zonas de tienda o soporte hacia segmentos sensibles.
- CI/CD: lectura masiva de variables, secretos, repositorios y configuraciones por una identidad o job que no suele hacerlo.
- Pagos: lotes, horarios, beneficiarios, límites o secuencias diferentes del comportamiento habitual, incluso cuando la autenticación sea válida.
Una señal por sí sola puede parecer administrativa. La llamada seguida de instalación remota, consulta de secretos y cambios de transferencia constituye una historia distinta. Conviene que SOC, fraude, tesorería, infraestructura, desarrollo y atención compartan identificadores y una línea de tiempo. Si cada equipo conserva su fragmento, el atacante opera en los espacios entre ellos.
La ingeniería social debe probarse en el proceso real
El vishing observado no explota desconocimiento técnico: explota la expectativa de recibir soporte. Una política que dice “no entregue su contraseña” es insuficiente si el procedimiento permite que un supuesto técnico pida instalar una herramienta, lea un código o cambie un factor. La validación debe ocurrir mediante un canal iniciado por el empleado hacia un directorio conocido, con un ticket que el interlocutor no pueda crear y confirmar por sí mismo.
Una evaluación de Ingeniería Social puede simular llamadas y solicitudes de soporte con reglas éticas, medir dónde se rompe el proceso y comprobar si la mesa de ayuda escala a tiempo. El objetivo no es culpar al usuario que contesta; es descubrir si el diseño le ofrece una forma rápida y segura de verificar identidad bajo presión.
La formación continua también debe usar escenarios del negocio: mantenimiento de una terminal, cambio de certificado, desbloqueo urgente, conciliación de un lote o acceso de proveedor. Cuando el ejemplo coincide con la jornada real, la persona reconoce la anomalía antes de que el atacante complete la narrativa.
Controles que resisten una identidad ya comprometida
La autenticación fuerte reduce accesos iniciales, pero el diseño financiero debe asumir que alguna sesión o equipo podría quedar bajo control. Las operaciones de alto impacto necesitan segregación real: quien prepara un lote no debe aprobarlo con la misma identidad, dispositivo, sesión ni canal. La segunda autorización pierde valor si ambos factores viven en el endpoint comprometido.
Los límites deben considerar comportamiento, no solo montos fijos. Un nuevo beneficiario, una secuencia fuera de horario, cambios simultáneos de cuenta y certificado, o cientos de transferencias desde un proceso que normalmente ejecuta pocas merecen fricción adicional. La confirmación fuera de banda debe utilizar una ruta que el atacante no controle y registrar quién aceptó la excepción.
Para los secretos, conviene usar certificados no exportables cuando la arquitectura lo permita, identidades de corta duración, bóvedas con aprobación y registros de cada lectura. Los pipelines no deberían conservar credenciales permanentes en variables o archivos. Un Ethical Hacking autorizado puede demostrar si un compromiso de usuario o CI/CD alcanza las funciones de pago, sin realizar transacciones reales.
Qué hacer durante las primeras 24 horas
- Separar contención y continuidad. Aislar identidades, endpoints y rutas sospechosas sin destruir registros ni improvisar cambios que bloqueen toda la operación.
- Proteger la capacidad de pago. Reducir límites, activar revisión manual y exigir autorización por un canal independiente para operaciones críticas.
- Preservar evidencia. Capturar registros de identidad, RMM, EDR, red, CI/CD, bóvedas, APIs, antifraude y conciliación con una línea temporal común.
- Rotar por secuencia. Cerrar la persistencia antes de renovar contraseñas, tokens y certificados; comprobar identidades derivadas y sesiones activas.
- Conciliar desde una fuente confiable. Comparar órdenes, autorizaciones, transmisión y liquidación para localizar operaciones que el sistema comprometido pudiera ocultar.
- Notificar con hechos. Coordinar fraude, jurídico, regulatorio, proveedores y dirección sin atribuir actor, país o monto más allá de la evidencia.
El Análisis Forense Digital debe responder no solo cómo entró el actor, sino qué capacidades financieras estuvieron a su alcance, qué secretos consultó y qué operaciones ocurrieron durante la ventana. Esa delimitación guía la rotación, la comunicación y la recuperación segura.
Lectura para Colombia y España
Colombia comparte un ecosistema de pagos inmediatos, integraciones abiertas, proveedores regionales, comercios y fintech en crecimiento. El informe no confirma víctimas colombianas; sí ofrece un modelo de amenaza aplicable. Las organizaciones deberían revisar qué terceros pueden iniciar transacciones, cómo se protege el material criptográfico, quién administra la integración y si fraude recibe señales de identidad y endpoint antes de aprobar.
Para España, la campaña también importa aunque su foco divulgado sea Brasil. Entidades financieras, proveedores de pagos y comercios europeos utilizan cadenas similares de APIs, certificados, software bancario, soporte remoto y pipelines. Una empresa con operaciones latinoamericanas debe evitar que una identidad global o un equipo de soporte permita saltar desde una filial hacia capacidades regionales de pago.
En ambos mercados, la dirección necesita una vista que conecte riesgo cibernético y exposición financiera. Un CISO as a Service puede coordinar responsables de tesorería, fraude, tecnología y seguridad, establecer escenarios de pérdida y traducirlos en pruebas, límites y decisiones de inversión.
Límites de la evidencia pública
Google describe investigaciones realizadas desde 2024 y publica sus hallazgos el 1 de septiembre de 2026. No identifica víctimas ni proporciona un recuento total de organizaciones, pérdidas o transferencias. Las dos oleadas de cientos de operaciones corresponden a un caso forense; no deben extrapolarse a toda la actividad del grupo.
La infraestructura observada puede sugerir expansión hacia Latinoamérica y África, pero no demuestra ataques en Colombia, España o cada país que aparezca en un recurso técnico. Los indicadores cambian y pueden ser compartidos por servicios legítimos o infraestructura comprometida. Toda búsqueda debe combinar contexto, comportamiento y evidencia local antes de declarar una intrusión.
Pruebe si una intrusión común puede convertirse en una transferencia
Insylux puede evaluar la cadena completa: ingeniería social, endpoints, identidades, secretos de CI/CD, segmentación, APIs y controles de autorización. El resultado debe mostrar hasta dónde llega un acceso realista y qué barrera reduce primero la posibilidad de fraude.
Solicite al Equipo Insylux una evaluación prioritaria de su ruta de pagos.
Fuentes y alcance
- Google Threat Intelligence Group y Mandiant, investigación de BREEZE COMET, 1 de septiembre de 2026.
- The Hacker News, síntesis independiente de la investigación y las transferencias observadas, 1 de septiembre de 2026.
Fuentes consultadas el 1 de septiembre de 2026. Las tácticas, herramientas y casos proceden de la investigación de GTIG/Mandiant. Las recomendaciones para Colombia y España, la tabla de controles y las prioridades de respuesta son análisis defensivo del Equipo Insylux.
