El crimen ya no cobra con tarjetas, roba con APIs

Durante años, el crimen organizado en Latinoamérica se movió donde estaba el volumen: tarjetas clonadas, phishing al consumidor, fraude en comercios. En septiembre de 2026, dos informes de inteligencia de amenazas describieron un cambio de patrón que cualquier empresa con integraciones de pago debería leer con atención. El objetivo ya no es la tarjeta del cliente. El objetivo es la API que mueve el dinero.

Qué pasó

El 1 de septiembre, Google (vía su equipo de Threat Intelligence) publicó el informe sobre BREEZE COMET, un actor con motivación financiera especializado en manipular "sistemas de pago y software bancario en Brasil para ejecutar transferencias fraudulentas". Su lista de blancos es explícita: organizaciones con permiso para operar transacciones a través de software bancario, APIs y sistemas de pago como Pix, STR y Boleto. Son bancos, procesadores de pago, comercios, exchanges, y también proveedores de software fintech y bancario.

Una semana después, el 8 de septiembre, la prensa especializada cubrió un segundo caso descrito en el 2026 Threat Hunting Report de una firma de ciberseguridad: Slim Spider, un actor activo desde marzo de 2026 y no documentado antes, atacando instituciones financieras brasileñas. Según esa cobertura, el actor roba credenciales temporales de la nube desde los metadata endpoints de instancias, enumera los secrets de un credential manager, y usa credenciales comprometidas para entrar a pipelines de CI/CD y desplegar implantes en un clúster Kubernetes administrado. Uno de esos implantes se llamó spi, suplantando el nombre de la infraestructura que procesa Pix, y usaba un panel ("Painel Pix") para ejecutar transferencias masivas no autorizadas.

Nota de transparencia: el informe primario sobre BREEZE COMET fue consultado directamente. El caso Slim Spider se cita a través de la prensa especializada que referencia el reporte de la firma, no de una lectura directa del PDF.

Por qué el blanco es la integración, no el usuario

El fraude retail clásico busca víctimas individuales: miles de transacciones pequeñas, cada una de bajo valor. La intrusión a la que se refieren estos informes busca una cosa distinta: una sola credencial que autoriza muchas transferencias legítimas. Es la diferencia entre robar una cartera y robar la llave del cuarto donde está la caja.

Google documenta además los requisitos que el actor necesita cumplir para lograr el fraude. Leídos juntos, describen exactamente la superficie que administra un equipo de TI interno:

1. Acceso a la red del sistema financiero (la RSFN, en el caso brasileño).
2. Credenciales mTLS para enviar payloads autenticados con órdenes transaccionales a Pix o STR.
3. Acceso persistente a Active Directory y a los entornos de nube.
4. Entender los procedimientos de transferencia, controles de red, integraciones fintech y sistemas antifraude de la víctima.

El punto 4 es el más incómodo. Para robar, el atacante tiene que estudiar cómo está cosida la empresa por dentro: dónde termina el ERP, dónde empieza la pasarela, qué conecta el core bancario con el e-commerce. Esa costura, la integración, es lo que un CTO conoce mejor que nadie y, con frecuencia, lo que menos ha revisado con ojos de riesgo.

Los 4 requisitos del atacante, aplicados a su empresa

Traducido a preguntas concretas:

• Credenciales de integración. ¿Dónde viven hoy los certificados mTLS, los tokens de API y los secrets del credential manager? ¿Están en variables de entorno en texto plano, en un repositorio, o en un gestor con rotación y auditoría?
• Pipelines. ¿Quién puede ejecutar un pipeline de despliegue? ¿Un pipeline tiene alcance para escribir en producción, o solo puede leer?
• Legacy. ¿El sistema heredado que mueve dinero está dentro del perímetro de monitoreo, o es una caja que nadie toca hasta que falla?
• Visibilidad. ¿Tienen alertas sobre llamadas anómalas a APIs de pago, o solo saben que algo pasó cuando el dinero ya salió?

Checklist para el CTO o Director de TI

1. Inventaríe las credenciales que autorizan dinero. Separe las de producción de las de prueba. Exija rotación y dueño nominado para cada una.
2. Separe los pipelines de los secretos. Un pipeline debe poder desplegar sin poder leer las credenciales de pago.
3. Incluya el sistema heredado en el monitoreo. Si mueve dinero y no genera logs consultables, es un punto ciego con historial.
4. Monitoree la capa de integración, no solo el endpoint. Las llamadas legítimas y las fraudulentas se parecen; la diferencia está en el volumen, el horario y el origen.
5. Revise las reglas antifraude como código, con dueño. Los controles que nadie revisa no controlan nada.

La superficie de integración se defiende en el diseño

Ninguno de estos cinco puntos se resuelve comprando una herramienta. Se resuelven decidiendo, antes de construir, cómo se autentica una integración, quién puede ejecutar un despliegue y qué queda registrado. En el lenguaje del atacante, el éxito depende de entender la integración de la víctima. Para el defensor, esa misma frase es una instrucción: la única forma de que nadie entienda su integración mejor que usted es diseñarla con esas reglas.

Ambos casos se suman a otros episodios de riesgo digital en la región, como los ataques con IA en LatAm y la brecha de LATAM Pass.

¿Su empresa integra pagos, ERP o sistemas heredados que mueven dinero? En Byxel diseñamos y auditamos esas integraciones con el rigor de seguridad que el negocio exige. Escríbanos por WhatsApp y revisemos juntos dónde está su punto más débil.