Una agencia de EE.UU. pagó un millón de dólares tras casi un mes de negociación con un grupo de ransomware – CYBERDEFENSA.MX

Generalmente, las instituciones públicas siempre se niegan a asumir el pago de rescates por ataques de ransomware que exigen los actores de amenazas al comprender que eso no garantiza obtener los datos cifrados o que las copias sean destruidas y a sabiendas de que son una manera de ayudar a financiar a estos grupos.

Sin embargo, hay excepciones. Ciertos organismos, desesperados o preocupados por las consecuencias sobre los ciudadanos, acaban cediendo a los chantajes de los cibermalos. Eso es lo que pasó con una agencia pública estadounidense que fue víctima del grupo de extorsión Kairós. Tras un largo período de 28 días de negociaciones, la institución acabó desembolsando un rescate de un millón de dólares. 

Según el informe de Ransom-ISAC, los delincuentes comenzaron exigiendo 3 millones de dólares, mientras que la organización afectada intentó rebajar esa cifra con varias ofertas, que fueron desde los 100.000 hasta los 430.000 dólares. 

Sin embargo, los atacantes mantuvieron la presión y lanzaron un ultimátum: pagar un millón de dólares antes de una fecha límite o publicar toda la información robada.

Curiosamente, durante ese proceso, Kairos no recurrió al cifrado de los sistemas, como ocurre en muchos ataques de ransomware. En su lugar, basó toda su estrategia en amenazar con difundir los datos que aseguraba haber sustraído. Para aumentar la presión, incluso hizo referencia a carpetas especialmente sensibles, como una relacionada con la fiscalía, advirtiendo de que su publicación podría tener un gran impacto.

Según explica Ransom-ISAC, los tiempos que manejaba el organismo responden a las habituales consultas internas que se requerían para hacer el pago. «Las respuestas de la entidad afectada son coherentes con las de una organización que ganaba tiempo mientras se coordinaban las decisiones legales, de liderazgo, financieras y de comunicación», señala el informe.

Una vez recibido el dinero, Kairos envió un archivo que supuestamente demostraba que había suprimido la información robada. Sin embargo, los investigadores advierten de que esa prueba no permite verificar que los datos fueran eliminados permanentemente. 

«La ‘prueba’ proporcionada no era técnicamente verificable y no debe considerarse como evidencia de que los datos robados fueron destruidos», concluye el informe. De este modo, y como suele suceder, aunque la víctima se aflojó el bolsillo para evitar una posible filtración, nunca pudo tener la certeza de que los ciberdelincuentes hubieran cumplido su palabra.

¿De qué agencia hablamos?

El informe de Ransom-ISAC oculta la identidad de la víctima por motivos de privacidad. Sin embargo, a partir de la transcripción de la negociación y otros indicios, los investigadores consideran que podría tratarse del condado de Union (Ohio), aunque no lo confirman de forma definitiva. Entre las pistas figuran nombres de archivos como Union.xlsx y union.rar, además de que la víctima se describe como «un condado pequeño con recursos limitados».

El autor del artículo añade que hizo su propia investigación y comprobó que el condado de Union reconoció públicamente el año pasado haber sufrido un ciberataque en el que se robaron datos de decenas de miles de residentes. No obstante, ni el condado ni Kairos han reconocido que se trate del mismo incidente.
 

Entidad del gobierno de EE. UU. pagó a Kairos $1 millón en un caso de extorsión por robo de datos – CYBERDEFENSA.MX

Una entidad del gobierno de EE. UU. pagó alrededor de 1 millón de dólares para evitar que se filtraran archivos robados, según un nuevo informe. estudio de caso de Rakesh Krishnan para Ransom-ISACconstruido sobre un chat de negociación filtrado y el rastro de blockchain que dejó el pago.

Lo curioso: el grupo que se llevó el dinero se autodenomina Kairóspero puede que no sea una banda de ransomware en absoluto. Krishnan no encontró señales de que alguna vez hubiera bloqueado una sola máquina: ni cifrador, ni casillero, ni solicitud de clave de descifrado. La amenaza era más sencilla. Roba los archivos y luego cobra a la víctima por no publicarlos.

krishnan no nombra a la víctima, pero el chat apunta al condado de Union, Ohio. Los archivos de prueba de robo llevan nombres como Union.xlsx, 1 union co psi template.doc y un archivo final llamado union.rar. La víctima se autodenomina un condado pequeño con recursos limitados. El atacante se apoya en una carpeta en particular, marcada como «fiscalía», y advierte que filtrarla ayudaría a los delincuentes a evadir cargos.

Las pistas encajan en un caso real. En mayo de 2025, el condado de Union, Ohio, dijo que detectó ransomware en su red y luego notificó a 45,487 residentes y al personal que se habían tomado sus datos, lo que afectó a la mayor parte del condado de aproximadamente 70,000 habitantes. Los registros robados iban desde la Seguridad Social y detalles financieros hasta huellas dactilares y números de pasaporte.

Ciberseguridad

Ni el condado ni Kairos han confirmado la conexión. Pero si se mantiene, el gobierno de un condado pagó alrededor de $1 millón que nunca reveló públicamente. The Hacker News se ha puesto en contacto con la Oficina de los Comisionados del Condado de Union para solicitar comentarios. Esta historia se actualizará con cualquier respuesta.

La negociación duró aproximadamente un mes. Kairos abrió a 3 millones de dólares y afirmó que contenía más de 2 terabytes de datos, unos 1,6 millones de archivos. El condado comenzó con $100,000, subió lentamente hasta $255,000 y luego $430,000. Kairos bajó a 2 millones de dólares, luego fijó una cifra final estricta: 1 millón de dólares, pago antes del viernes o los archivos se harán públicos.

El pago en cadena: alrededor de 9,44 BTC llegan a la billetera vinculada a Kairos.

Utilizó las palancas habituales: un cronómetro de cuenta regresiva, plazos ajustados y amenazas de deshacerse primero de las carpetas más confidenciales. El condado pagó el 13 de junio de 2025, diez veces su primera oferta.

El pago fue de aproximadamente 9,44 bitcoins, con un valor aproximado de 1 millón de dólares en ese momento. Krishnan rastreó el dinero desde allí. En cuestión de horas, se dividió en dos y se empujó a través de una cadena de billeteras hacia direcciones de depósito vinculadas a los intercambios de cifrado Bybit, OKX y un servicio ruso llamado BELQI.

Ese tipo de rastreo de manos lo llevan los investigadores, no los nombres. Y el dinero no compró nada sólido. Kairos envió un archivo de «prueba de eliminación», pero una lista de nombres de archivos muestra sólo que el atacante alguna vez tuvo los archivos, no que los originales fueron eliminados. Pagar para hacer desaparecer los datos robados es un acto de fe y el recibo lo escribe el ladrón.

El condado de Union llamó a lo que le sucedió ransomware, la palabra que todos buscan, pero en el caso Kairos, nada estaba bloqueado. Ese es el verdadero cambio: gran parte de lo que todavía se llama ransomware ahora omite el cifrado y utiliza los datos robados como punto de presión.

Sophos informó en 2025 que solo alrededor de la mitad de los ataques de ransomware todavía implican cifrado, la tasa más baja en seis años. Algunas tripulaciones lo han abandonado por completo. Silent Ransom Group, una filial de Conti, ha pasado años ejecutando extorsión por robo de datos contra firmas legales y financieras estadounidenses sin ningún tipo de cifrado.

Ciberseguridad

El chat Kairos también se ajusta a un patrón de negociación familiar. Cuando los chats internos de Black Basta se filtraron en febrero de 2025, un análisis de los mensajes reveló un acuerdo que iba desde una demanda de 1,5 millones de dólares hasta una contrapartida de 100.000 dólares y un pago de 1 millón de dólares, casi el mismo arco. Esas conversaciones, y las filtraciones de Conti que tuvieron lugar en 2022, son la forma en que los investigadores ahora reconstruyen la forma en que realmente se cierran estos acuerdos.

El propio Kairos se ha quedado en silencio. El sitio de la fuga no funciona y su última víctima conocida apareció en junio de 2026. Pero una billetera vinculada a la operación todavía movía dinero en mayo de 2026, un recordatorio de que un sitio de fuga oscuro no es lo mismo que una tripulación muerta.

Para cualquiera que dirija una pequeña red gubernamental, las lecciones son aburridas y familiares, y ese es el punto. Active la autenticación multifactor, ya que Kairos afirmó que accedió simplemente adivinando una contraseña.

Esté atento a los repetidos inicios de sesión fallidos, grandes transferencias de datos salientes y enlaces para compartir archivos grabadores, como las direcciones temp.sh que Kairos usó para mover los archivos. Mantenga los registros legales, de recursos humanos y de ciudadanos separados del resto de la red. Tenga listo un plan de declaración pública antes de que lo necesite. Y trate cualquier promesa de eliminar datos robados como si no valiera nada.

Los scripts en su página de pago son ahora un problema de PCI DSS – CYBERDEFENSA.MX

Un evaluador independiente de PCI probó Reflectiz según las nuevas reglas PCI DSS. Aquí está el veredicto: Vea la evaluación QSA completa aquí →

Cuando un cliente ingresa su número de tarjeta en su proceso de pago, su navegador ejecuta mucho más que su código. Etiquetas de análisis, un administrador de etiquetas, un widget de soporte, un iframe de pago: un proceso de pago moderno carga docenas de scripts de terceros y cualquiera de ellos puede convertirse en un skimmer.

Así funciona Magecart. Sansec ha contado más de 100.000 sitios afectados por el robo de información web y los ataques a la cadena de suministro. El Incumplimiento de British Airways en 2018 Solo expuso 380.000 transacciones y una multa que comenzó en £183 millones.

La parte peligrosa: el código malicioso suele llegar a través de un script que ya has aprobado. Los atacantes comprometen a un proveedor externo y la carga útil se aloja en un script que usted ha ejecutado durante meses. Nada parece nuevo. Lo que cambió es el comportamiento del script, no su presencia en la página.

PCI DSS v4.0.1 cierra esa brecha con dos requisitos, ahora plenamente vigentes. 6.4.3 dice inventariar cada script de página de pago, autorizarlo y demostrar su integridad. 11.6.1 dice detectar la manipulación del contenido de la página y los encabezados HTTP a medida que el navegador los recibe. Hecho a mano, a través de cientos de guiones que cambian constantemente, esto no escala. Los datos de Reflectiz muestran que aproximadamente el 30% de los guiones de las páginas de pago cambian en cualquier período de dos semanas.

Lo que encontró el QSA

Integrity360 Europe, un asesor de seguridad calificado de PCI y miembro de la mesa redonda de asesores ejecutivos globales de PCI SSC, revisó la plataforma Reflectiz PCI DSS con respecto a ambos requisitos y descubrió que puede respaldar eficazmente el cumplimiento. Destacaron tres cosas:

  • Observa el comportamiento, no solo los hash de los archivos. Una verificación de hash omite un intercambio silencioso del lado del proveedor. Reflectiz capta el guión en el momento en que comienza a buscar datos de la tarjeta.
  • Se implementa sin agentes. Sin cambios de código, sin fragmentos, dura días y sigue funcionando a través de refactorizaciones y migraciones de CMS.
  • Produce evidencia lista para QSA con un solo clic. Registro de auditoría completo por página, listo para su evaluación.

El SAQ una captura

Desde enero de 2025, los comerciantes pueden eliminar 6.4.3 y 11.6.1 del SAQ A solo si confirman que su sitio no es susceptible a ataques de script. ¿Redireccionamiento completo a tu procesador? Probablemente estés bien. ¿Incrustar un iframe de pago? Un script en la página principal aún puede secuestrar el pago antes de que los datos lleguen al marco seguro, y usted debe demostrar que no puede hacerlo. La pregunta frecuente número 1588 de PCI SSC apunta directamente a estos mismos controles.

Obtenga la evaluación completa

El documento técnico completo de Integrity360 Europe desglosa ambos requisitos línea por línea, el flujo de trabajo de monitoreo y exactamente lo que SAQ A exige ahora a los comerciantes de iframe.

Descargue el documento técnico →

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

La falla del generador de embudo bajo explotación activa permite el skimming del proceso de pago de WooCommerce – CYBERDEFENSA.MX

Una vulnerabilidad de seguridad crítica que afecta a la
Constructor de embudos
El complemento para WordPress ha sido objeto de explotación activa en la naturaleza para inyectar código JavaScript malicioso en las páginas de pago de WooCommerce con el objetivo de robar datos de pago.

Los detalles de la actividad fueron
publicado
por Sansec esta semana. La vulnerabilidad actualmente no tiene un identificador CVE oficial. Afecta a todas las versiones del complemento anteriores a la 3.15.0.3. Se utiliza en más de 40.000 tiendas WooCommerce.

La falla permite a atacantes no autenticados inyectar JavaScript arbitrario en cada página de pago de la tienda, dijo la empresa holandesa de seguridad de comercio electrónico. FunnelKit, que mantiene Funnel Builder, ha lanzado un parche para la vulnerabilidad en la versión 3.15.0.3.

«Los atacantes están colocando scripts falsos de Google Tag Manager en la configuración ‘Scripts externos’ del complemento», señaló. «El código inyectado parece un análisis ordinario al lado de las etiquetas reales de la tienda, pero carga un skimmer de pagos que roba números de tarjetas de crédito, CVV y direcciones de facturación del proceso de pago».

Ciberseguridad

Según Sansec, Funnel Builder incluye un punto final de pago expuesto públicamente que permite que una solicitud entrante elija el tipo de método interno a ejecutar. Sin embargo, las versiones anteriores se diseñaron de manera que nunca verificaran los permisos de la persona que llama ni limitaran los métodos que se podían invocar.

Un mal actor podría aprovechar esta laguna mediante la emisión de una solicitud no autenticada que puede llegar a un método interno no especificado que escribe datos controlados por el atacante directamente en la configuración global del complemento. Luego, el fragmento de código agregado se inyecta en cada página de pago de Funnel Builder.

Como resultado, un atacante podría colocar un malware

En al menos un caso, Sansec dijo que observó una carga útil que se hacía pasar por un cargador de Google Tag Manager (GTM) para iniciar JavaScript alojado en un dominio remoto. Posteriormente abre una conexión WebSocket al servidor de comando y control (C2) del atacante («wss://protect-wss[.]com/ws») para recuperar un skimmer adaptado al escaparate de la víctima.

El objetivo final del ataque es desviar números de tarjetas de crédito, CVV, direcciones de facturación y otra información personal que los visitantes del sitio podrían ingresar al finalizar la compra. Se recomienda a los propietarios del sitio que actualicen el complemento Funnel Builder a la última versión y revisen Configuración > Pagar > Scripts externos para detectar cualquier cosa que no les resulte familiar y eliminarla.

«Vestir a los skimmers como código de Google Analytics o Tag Manager es una
patrón recurrente de Magecart, ya que los revisores tienden a pasar por alto cualquier cosa que parezca una etiqueta de seguimiento familiar», dijo Sansec.

Ciberseguridad

La divulgación se produce semanas después de que Sucuri detallara una campaña en la que los sitios web Joomla están siendo bloqueados con código PHP muy ofuscado para contactar servidores C2 controlados por atacantes, recibir y procesar instrucciones enviadas por los operadores y servir contenido spam a visitantes y motores de búsqueda sin el conocimiento del propietario del sitio. El objetivo final es aprovechar la reputación de los sitios a la hora de inyectar spam.

«El script actúa como un cargador remoto», afirma el investigador de seguridad Puja Srivastava
dicho
. «Se pone en contacto con un servidor externo, envía información sobre el sitio web infectado y espera instrucciones. La respuesta del servidor remoto determina qué contenido debe ofrecer el sitio infectado».

«Este enfoque permite a los atacantes cambiar el comportamiento del sitio web comprometido en cualquier momento sin modificar los archivos locales nuevamente. El atacante puede inyectar enlaces de productos spam, redirigir a los visitantes o mostrar páginas maliciosas dinámicamente».

WebRTC Skimmer omite el CSP para robar datos de pago de sitios de comercio electrónico – CYBERDEFENSA.MX

Investigadores de ciberseguridad han descubierto un nuevo skimmer de pagos que utiliza Canales de datos WebRTC como medio para recibir cargas útiles y exfiltrar datos, evitando efectivamente los controles de seguridad.

«En lugar de las habituales solicitudes HTTP o balizas de imágenes, este malware utiliza canales de datos WebRTC para cargar su carga útil y filtrar datos de pago robados», Sansec dicho en un informe publicado esta semana.

Se dice que el ataque, que tuvo como objetivo el sitio web de comercio electrónico de un fabricante de automóviles, fue facilitado por PolyShell, una nueva vulnerabilidad que afecta a Magento Open Source y Adobe Commerce y que permite a atacantes no autenticados cargar ejecutables arbitrarios a través de la API REST y lograr la ejecución de código.

Ciberseguridad

En particular, desde entonces la vulnerabilidad ha sido objeto de explotación masiva desde el 19 de marzo de 2026, con más de 50 direcciones IP participando en la actividad de escaneo. La empresa de seguridad holandesa dijo que encontró ataques PolyShell en el 56,7% de todas las tiendas vulnerables.

El skimmer está diseñado como un script autoejecutable que establece una conexión entre pares WebRTC a una dirección IP codificada («202.181.177[.]177») a través del puerto UDP 3479 y recupera código JavaScript que posteriormente se inyecta en la página web para robar información de pago.

El uso de WebRTC marca una evolución significativa en los ataques skimmer, ya que elude la Política de seguridad de contenidos (CSP) directivas.

«Una tienda con un CSP estricto que bloquea todas las conexiones HTTP no autorizadas todavía está abierta a la exfiltración basada en WebRTC», señaló Sansec. «El tráfico en sí también es más difícil de detectar. Los WebRTC DataChannels se ejecutan sobre UDP cifrado con DTLS, no sobre HTTP. Las herramientas de seguridad de red que inspeccionan el tráfico HTTP nunca verán salir los datos robados».

Adobe lanzó una solución para PolyShell en versión 2.4.9-beta1 lanzado el 10 de marzo de 2026. Pero el parche aún no ha llegado a las versiones de producción.

Como mitigación, se recomienda a los propietarios de sitios bloquear el acceso al directorio «pub/media/custom_options/» y escanear las tiendas en busca de shells web, puertas traseras y otro malware.