Checkout.com rechaza pagar a ShinyHunters y refuerza su seguridad tras una brecha en un almacenamiento cloud legado

CyberSecureFox 🦊

Checkout.com, proveedor global de pagos que trabaja con eBay, Uber Eats, IKEA y Samsung, notificó un incidente de seguridad con robo de datos atribuido a ShinyHunters. La banda exigió un rescate, pero la compañía anunció que no pagará y que destinará una suma equivalente a iniciativas académicas de ciberseguridad, al tiempo que acelera su programa de endurecimiento defensivo.

Checkout.com confirma la brecha: acceso a un almacenamiento en la nube “legacy”

La investigación interna determinó que los atacantes accedieron a un sistema externo y obsoleto de almacenamiento de archivos en la nube usado antes de 2020 y que no fue desmantelado de forma correcta. Este repositorio seguía albergando materiales confidenciales fuera del inventario y de la supervisión operativa.

Entre la información sustraída hay datos de mercantes (socios comerciales), documentos operativos internos y materiales de onboarding de clientes. La empresa estima que el impacto alcanza a menos del 25% de su base de clientes actual, con posibilidad de que también afecte a exclientes. No hay indicios de compromiso de payment data ni de números de tarjeta.

ShinyHunters/Scattered Lapsus$ Hunters: tácticas y antecedentes

ShinyHunters, también referida como Scattered Lapsus$ Hunters, agrupa actores de Scattered Spider, LAPSUS$ y la propia ShinyHunters. Sus TTPs combinan phishing, abuso de OAuth y social engineering para tomar control de entornos corporativos y extorsionar. Investigadores han relacionado al colectivo con la explotación de un 0‑day en Oracle E‑Business Suite (CVE‑2025‑61884) y con ataques a plataformas como Salesforce y Drift que afectaron a decenas de organizaciones.

Respuesta de la fintech: rechazo al rescate e inversión en ciberseguridad

Checkout.com reiteró que no pagará el rescate a ShinyHunters. En su lugar, destinará una cifra comparable a la exigida a iniciativas de investigación en la Universidad Carnegie Mellon y el Oxford Cyber Security Centre. La compañía comunicó además una modernización amplia de sus controles: fortalecimiento de procesos, nuevas capas de defensa y más recursos dedicados a protección de clientes.

Riesgo de activos legacy en la nube: qué falló y cómo evitarlo

El incidente ilustra un patrón conocido: los activos “legacy” y la decomisión incompleta son vectores de entrada frecuentes. Repositorios olvidados y cuentas antiguas suelen conservar credenciales, archivos sensibles y copias históricas, pero quedan fuera del inventario y del monitoreo.

La evidencia sectorial respalda esta lectura: el Verizon DBIR 2024 atribuye a “el factor humano” alrededor del 68% de las brechas (incluye phishing, errores y uso de credenciales robadas), mientras que informes de ENISA destacan la mala configuración en la nube y la gestión deficiente de activos como causas recurrentes. Los “buckets” expuestos, claves no revocadas y tokens OAuth sin rotación siguen apareciendo en incidentes de alto impacto.

Controles prioritarios para reducir el riesgo

Buenas prácticas de referencia incluyen: inventario completo de activos (incluidos tenants cloud y servicios de terceros), procedimientos formales de desmantelamiento y borrado seguro, retención mínima de datos, rotación periódica de claves y tokens OAuth, least privilege, supervisión continua con SIEM/SOAR y control de fugas con DLP. Complementar con CSPM para evaluar configuraciones y pruebas periódicas de rutas de acceso de emergencia reduce de forma notable la superficie de ataque.

Impacto para clientes y cadena de suministro: más phishing y suplantación

La exposición de materiales de onboarding y documentación operativa puede facilitar phishing creíble y ataques a la supply chain, con adversarios que imitan procesos de verificación o comunicaciones de un proveedor legítimo. Se recomienda a socios y clientes de Checkout.com reforzar la validación de solicitudes entrantes/salientes, revisar excepciones en políticas de correo, rotar tokens de integraciones, vigilar anomalías en APIs y reentrenar a usuarios frente a BEC (compromiso del correo corporativo).

El caso subraya que la ciberresiliencia en fintech no depende solo de blindar sistemas “en producción”, sino de gobernar con rigor el ciclo de vida de datos y servicios en la nube. Realizar una auditoría extraordinaria de archivos históricos, accesos y OAuth, acelerar la decomisión de sistemas heredados y actualizar los planes de respuesta al incidente ayudará a contener el impacto y a fortalecer la cadena de suministro digital. Es momento de inventariar, cerrar lo que no se usa y verificar que lo que permanece esté realmente bajo control.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.