SAFE. Guía para proteger tu vida digital y tu privacidad
Showing posts with label atacantes. Show all posts
Showing posts with label atacantes. Show all posts

Jul 19, 2026

Hugging Face confirma ataque y brecha ejecutado por agentes autónomos

Hugging Face reveló que detectó y contuvo una intrusión en su infraestructura de producción, impulsada de principio a fin por un sistema de agentes de IA autónomos, y se defendió de ella utilizando su propio análisis forense basado en IA.

Los atacantes explotaron dos fallos de ejecución de código en el flujo de procesamiento de conjuntos de datos de Hugging Face: un cargador de conjuntos de datos de código remoto y una vulnerabilidad de inyección de plantillas en la configuración del conjunto de datos.

Una vez dentro de un trabajador de procesamiento, el actor escaló el acceso al nivel de nodo, recolectó credenciales de la nube y del clúster, y se movió lateralmente a través de varios clústeres internos durante un solo fin de semana.

El acceso no autorizado afectó a un conjunto limitado de conjuntos de datos internos y credenciales de servicio, aunque Hugging Face no encontró pruebas de que los modelos públicos, los conjuntos de datos, los Spaces o su cadena de suministro de software fueran manipulados.

Este incidente refleja una tendencia más amplia en la industria. La firma de seguridad Sysdig recientemente reveló lo que llama JADEPUFFER, descrito como la primera operación de ransomware totalmente autónoma impulsada por IA, donde un agente de IA se infiltró independientemente en un servidor expuesto a Internet, se movió lateralmente, cifró archivos y emitió una demanda de rescate sin ninguna intervención humana.

Por separado, el Informe Anual de Seguridad de IA 2026 de Check Point documenta intrusiones en vivo dirigidas cada vez más por IA, reduciendo la ventana entre la divulgación de la vulnerabilidad y su explotación de días a horas.

Lo que hizo que esta campaña fuera distinta fue la escala y la autonomía: la intrusión ejecutó miles de acciones individuales a través de un enjambre de sandboxes de corta duración, utilizando una infraestructura de comando y control automigratoria alojada en servicios públicos, coincidiendo con el escenario de "atacante agente" previsto hace tiempo.

El propio flujo de detección de anomalías de Hugging Face, que utiliza un triaje basado en LLM sobre telemetría de seguridad, señaló primero el compromiso al correlacionar señales que, de otro modo, se habrían perdido en el ruido diario.

Para reconstruir la línea de tiempo completa del ataque a partir de más de 17.000 acciones registradas del atacante, Hugging Face ejecutó agentes de análisis impulsados por LLM sobre todo el registro, comprimiendo lo que normalmente toma días en cuestión de horas.

Un hallazgo crítico de la investigación: las APIs de modelos comerciales de vanguardia se negaron a procesar el análisis forense porque sus barreras de seguridad no podían distinguir a un respondedor de incidentes que enviaba cargas útiles de exploits reales y artefactos de C2 de un atacante real.

Hugging Face cambió a GLM-5.2, un modelo de pesos abiertos ejecutado en su propia infraestructura, lo que también aseguró que ningún dato del atacante ni credenciales referenciadas abandonaran su entorno.

Esto expone una asimetría cruda: los atacantes que utilizan modelos con "jailbreak" o sin restricciones no enfrentan tales límites de política, mientras que los defensores que utilizan modelos comerciales alojados pueden quedar bloqueados a mitad de un incidente.

Hugging Face te aconseja rotar tus tokens de acceso y revisar la actividad reciente de tu cuenta como precaución.

El impulso de la industria refleja que las herramientas ofensivas de IA autónoma han pasado de la teoría a la práctica; el Centro Nacional de Ciberseguridad del Reino Unido ya ha lanzado una iniciativa de "Escudo Cibernético" para desplegar defensa impulsada por IA a escala nacional en respuesta.

La lección fundamental que surge de este incidente: las organizaciones necesitan un modelo de IA capaz y alojado localmente, evaluado y listo antes de que ocurra un incidente, tanto para evitar el bloqueo de las barreras de seguridad durante el trabajo forense como para evitar que los datos sensibles del ataque salgan de su entorno.

Como señaló Hugging Face, la superficie de datos y modelos debe tratarse ahora como un vector de ataque de primera clase, requiriendo una defensa impulsada por IA para hacer frente a la ofensiva impulsada por IA a velocidad de máquina.

Fuentes: CyberSecurityNews

Jul 1, 2026

Ataque de fuerza bruta masivo contra CLI de Azure

Investigadores de ciberseguridad de Huntress han alertado sobre un ataque masivo, continuo y automatizado de fuerza bruta contra contraseñas dirigido a la interfaz de línea de comandos (CLI) de Azure de Microsoft, que ha comprometido decenas de cuentas.

Según Huntress, la actividad se origina en un rango de direcciones IPv6 (2a0a:d683::/32) controlado por el proveedor de infraestructura de internet LSHIY LLC (AS32167).

Entre el 12 y el 26 de junio, el atacante realizó más de 81 millones de intentos de inicio de sesión y logró comprometer al menos 78 cuentas de Microsoft en 64 organizaciones. "La estrategia de estos ataques parece basarse exclusivamente en la frecuencia de las contraseñas en las listas de combinaciones de contraseñas comprometidas, sin estar específica para ningún tipo de empresa o sector".

Lo que hace que este ataque de fuerza bruta sea relevante no es solo su magnitud, sino también el hecho de que muchas de las organizaciones afectadas tenían habilitadas las políticas de acceso condicional. En concreto, se ha descubierto que la campaña aprovecha un flujo de OAuth obsoleto llamado Credenciales de Contraseña del Propietario del Recurso (ROPC) para eludir las protecciones de la Política de Acceso Condicional (CAP).

ROPC es un tipo de concesión de OAuth 2.0 heredado en el que un usuario proporciona directamente su nombre de usuario y contraseña a una aplicación cliente, que luego envía estas credenciales a un servidor de autorización para intercambiarlas por un token de acceso. Se dejó de usar en OAuth 2.1.

En su documentación, Microsoft recomienda a los clientes no usar el flujo ROPC, argumentando que es incompatible con la autenticación multifactor (MFA).

"En la mayoría de los casos, existen alternativas más seguras que se recomiendan. Este flujo requiere un alto grado de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos. Solo debe usarse cuando no sea viable usar flujos más seguros", afirma el gigante tecnológico.

Se dice que los ataques de fuerza bruta contra credenciales y tokens resultaron en un puñado de inicios de sesión exitosos por día entre el 12 y el 21 de junio de 2026, con un promedio de dos a cuatro cuentas comprometidas diariamente, con la excepción del 19 de junio, cuando se vieron comprometidas 12 cuentas de usuario (también conocidas como identidades). El ritmo constante cambió el 22 de junio, cuando 30 identidades de 23 empresas se vieron afectadas.

En total, 78 cuentas de usuario se vieron comprometidas en 64 organizaciones como parte de la campaña. La gran mayoría de los ataques de fuerza bruta contra contraseñas provino de LSHIY LLC. Algunas de las direcciones IP corresponden a Estados Unidos, mientras que otras corresponden a China.

"Estos ataques forman parte de una oleada generalizada de ataques de fuerza bruta contra credenciales en varios sistemas autónomos (ASN)", declaró Huntress, añadiendo que ha observado un aumento de más de 155 veces en el volumen de ataques de este tipo entre sus clientes. "Los ataques surgieron especialmente entre finales de mayo y principios de junio, con un promedio actual de aproximadamente 1964 ataques fallidos al mes por cada cliente protegido por Huntress".

La actividad parece centrarse específicamente en el uso de combinaciones antiguas de nombre de usuario y contraseña que ya habían sido vulneradas, pero que nunca se habían actualizado. El uso del vector ROPC permitió a los atacantes dirigirse a empresas que habían implementado la autenticación multifactor (MFA), pero que no la tenían configurada para gestionar los inicios de sesión ROPC de la CLI de Azure.

"ROPC se considera problemático por varias razones, pero una de ellas es que no ofrece compatibilidad con flujos de autenticación modernos como MFA o SSO. Esto significa que, como vimos en esta campaña, ROPC envía la contraseña directamente al punto final /token sin solicitar la autenticación multifactor de forma interactiva", explica Huntress.

Esto incluía escenarios en los que no se activaba la autenticación multifactor (MFA):

  • Aplicar la MFA solo para aplicaciones específicas, en lugar de para "Todas las aplicaciones en la nube", lo que impedía cubrir los inicios de sesión de la CLI de Azure utilizados por los ciberdelincuentes.
  • Aplicar la MFA solo para grupos de usuarios específicos, como los administradores.
  • Aplicar la MFA solo cuando las solicitudes se originaban en ubicaciones no confiables.

"Cabe destacar que ocho empresas afectadas por la campaña no contaban con ninguna política de autenticación multifactor (MFA): Si bien los ciberdelincuentes lograron acceder a pesar de tener MFA configurada, la conclusión no debe ser que MFA no funcione en absoluto; en cambio, las organizaciones deben asegurarse de que sus políticas de MFA estén configuradas correctamente para abordar el flujo de autorización utilizado en estos incidentes".

Para contrarrestar este tipo de ataque, se recomienda a las organizaciones que exijan MFA para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente al habilitar CAP, que restrinjan el acceso a la aplicación Azure CLI para usuarios que no sean administradores y que prioricen la respuesta según la validez de las credenciales.

Este ataque revela vulnerabilidades en los CAP que no se han configurado adecuadamente. Todavía existen posibles debilidades en la implementación de los CAP que pueden permitir que los ciberdelincuentes se filtren. Un error evidente es que los protocolos heredados como ROPC pueden eludir por completo algunos CAP mal configurados, ya que no pasan por el punto final de autorización donde se aplican las políticas.

El rango de direcciones IPv6 desde el que se originaron los ataques pertenece a LSHIY, un proveedor de infraestructura de internet registrado en Hong Kong, Wuhan (China) y Nueva York. También existen otros informes que indican que los rangos de IPv6 asociados con AS32167 y AS955, dos sistemas autónomos (ASN) operados por la empresa, se originan en China.

Fuente: THN

Jun 24, 2026

FortiBleed: detalles de la operación de robo de 110 millones de credenciales (y contando)

Se cree que un intermediario de acceso inicial (IAB) de habla rusa, motivado por el lucro, está detrás de una operación de robo de credenciales a gran escala conocida como FortiBleed, que ha afectado a más de 430.000 firewalls FortiGate en todo el mundo.

La campaña, activa desde febrero de 2026, consiste en recopilar listas de credenciales, buscar servicios expuestos, realizar ataques de fuerza bruta contra sistemas accesibles e implementar analizadores de red personalizados en los firewalls comprometidos.

"Una vez implementados, estos analizadores capturan credenciales en texto plano y cifradas del tráfico que pasa por los dispositivos comprometidos", afirma SOCRadar en un informe reciente. "Los atacantes luego descifran, validan y reutilizan las credenciales contra dominios de Active Directory y otros servicios expuestos".

La clave de la operación es una herramienta basada en Go llamada FortigateSniffer, que aprovecha el comando de diagnóstico integrado de FortiOS, `-diagnose sniffer packet`, para capturar pasivamente el tráfico de autenticación de los dispositivos infectados. La herramienta está diseñada para monitorizar el tráfico a través de 24 protocolos, analizar los datos de autenticación y extraer las credenciales.

Se sospecha que los ciberdelincuentes podrían haber recurrido a una plataforma de seguridad ofensiva de código abierto basada en IA, denominada CyberStrike, para optimizar algunas partes del proceso. Curiosamente, otro marco de código abierto, CyberStrikeAI, se utilizó en relación con otra campaña de escaneo masivo automatizado dirigida a dispositivos FortiGate, que Amazon Threat Intelligence reveló a principios de este año.

La campaña muestra un fuerte enfoque en las pequeñas y medianas empresas (pymes) con menos de 200 empleados. El atacante se dirige a múltiples sectores y regiones, con especial énfasis en Estados Unidos e India. El sector de servicios de TI parece ser un objetivo clave. Esta elección de objetivos probablemente ayuda al atacante a maximizar el acceso posterior, ya que los proveedores de servicios comprometidos pueden crear vías de acceso a los entornos de los clientes.

Quizás el hallazgo más interesante sea que FortiBleed parece formar parte de una operación de acceso inicial más amplia y multivendedor, orquestada no solo para atacar dispositivos Fortinet, sino también para vulnerar NAS de Synology, firewalls de Sophos, portales RDWeb, VPN SSL de Citrix y servidores MS-SQL mediante ataques de fuerza bruta automatizados desde el 28 de febrero de 2026.

En total, se estima que los atacantes lanzaron al menos 659 campañas de robo de credenciales entre el 31 de mayo y el 15 de junio de 2026, lo que resultó en la identificación de más de 110 millones de credenciales. Esto incluyó:

  • 14,8 millones de credenciales RADIUS (Servicio de Autenticación Remota de Usuarios por Marcación)
  • 924.000 hashes NTLM
  • 130.000 hashes Kerberos
  • 89 millones de tokens de autenticación MySQL

La campaña FortiBleed se desarrolla en cinco etapas:

  1. Primero, se realiza un reconocimiento exhaustivo utilizando herramientas como Masscan y Shodan para identificar firewalls FortiGate vulnerables con acceso a internet. Posteriormente, se utilizan una utilidad personalizada llamada FortiProbe-fast y GeoSplit para filtrar los sistemas FortiGate y agruparlos por país, respectivamente.
  2. Comprometer los dispositivos con un verificador de credenciales llamado "forticheck" que ataca específicamente el panel administrativo y el portal SSL-VPN de FortiGate, además de utilizar herramientas para obtener acceso administrativo SSH mediante ataques de relleno de credenciales y de diccionario.
  3. Tras establecer el acceso por SSH, FortigateSniffer se implementa para interceptar pasivamente el tráfico de autenticación en 24 protocolos (p. ej., TACACS+, Kerberos, RPC, SMB, LDAP, SMTP, FTP, Telnet, RDP, WinRM, MS-SQL, MySQL, PostgreSQL y RADIUS) mediante comandos de diagnóstico nativos de FortiOS, lo que permite obtener credenciales en texto plano y hashes de contraseñas.
  4. Los hashes de contraseñas se descifran con Hashmat y Hashtopolis, y se procesan mediante un bot de Telegram llamado HASHBOT. Posteriormente, se utilizan para el movimiento lateral y la enumeración de Active Directory.
  5. Se extraen datos confidenciales de los recursos compartidos de red, mientras que las cookies de sesión robadas se utilizan para mantener un acceso persistente y autenticado.

"El grupo no trata a todos los objetivos por igual", dijo SOCRadar. "En cambio, los objetivos se clasifican según su valor económico antes de asignar los recursos para su explotación".

Además, el mecanismo de rastreo incluye un filtro de geolocalización que restringe las operaciones a rangos de IP específicos, limitando la actividad al horario comprendido entre las 7:00 y las 18:00, hora de Moscú. Según datos capturados por SpyCloud, el ciclo de captura relacionado con FortiGate habría comenzado el 19 de mayo de 2026, y la infraestructura de descifrado de hashes se instaló a finales de mes.

"La operación se ejecuta en ciclos de 300 minutos (cinco horas), con actualizaciones de estado cada minuto", declaró Zenox. "En cada ciclo, carga una lista de objetivos regionales [...] y realiza la validación con 1.000 hilos simultáneos, mostrando contadores de éxito, fallo, tiempo de espera agotado y advertencia. En los primeros ciclos, la tasa de validación exitosa rondaba el 90%".

La empresa brasileña de ciberseguridad también informó haber encontrado ciertas combinaciones de nombre de usuario y contraseña repetidas en miles de direcciones IP distintas, lo que plantea la posibilidad de que el atacante haya creado estas cuentas como puerta trasera clandestina.

Este hecho se produce después de que una cuenta en ruso llamada "SantaAd" anunciara el acceso a miles de dispositivos Fortinet por un precio inicial de 30.000 dólares, que horas después aumentó a 60.000 dólares. Sin embargo, no está claro si esto tiene alguna relación con la filtración de FortiBleed.

"El grupo de ciberdelincuentes responsable de 'FortiBleed' no solo atacaba las VPN de FortiGate", declaró SpyCloud. "En realidad, atacaban una variedad de dispositivos conectados a internet con una cadena de ataques estándar de tipo 'bombardeo masivo' que se basa principalmente en escaneos masivos y ataques de fuerza bruta para obtener accesos".

Fuente: THN 

Jun 17, 2026

FortiBleed: ~70,000+ Firewall Fortinet comprometidos en una explotación masiva

Una exhaustiva campaña de ciberespionaje, ahora denominada FortiBleed, ha comprometido silenciosamente más de 73.932 URL únicas de firewalls Fortinet en 194 países. Las vulnerabilidades explotadas (ver abajo) ya se encuentra solucionadas pero los administradores deben aplicar los parches.

"La base de datos del atacante contiene credenciales de acceso para más de 30.791 dispositivos pertenecientes a empresas y organizaciones gubernamentales de 194 países", declaró SOCRadar. "No se trata de conjeturas aleatorias. Son nombres de usuario y contraseñas verificados y funcionales, probados y confirmados por los propios atacantes mediante herramientas automatizadas que operan las 24 horas del día".

Descubierta originalmente por el investigador de seguridad Volodymyr "Bob" Diachenko y analizada posteriormente por Hudson Rock, esta información revela una operación altamente automatizada a escala industrial dirigida a dispositivos FortiGate y gateways VPN SSL a nivel mundial, sin precedentes.

Los ciberdelincuentes ejecutaron aproximadamente 1.160 millones de intentos de robo de credenciales contra más de 320.000 objetivos FortiGate, al tiempo que lanzaron otros 2.100 millones de intentos de fuerza bruta contra más de 160.000 servidores MSSQL, lo que resultó en 21.632 dominios comprometidos.

Fortinet declaró que la recopilación de credenciales se obtuvo a través de incidentes anteriores y ataques de fuerza bruta, y que no implica ninguna nueva falla o brecha de seguridad nueva.

Según el experto en ciberseguridad Kevin Beaumont, este conjunto de datos expone una operación masiva y automatizada. Los actores de amenazas atacaron con éxito 73.932 URL de firewall únicas en 194 países, lo que resultó en 21.632 dominios únicos afectados. Sorprendentemente, como destacó Beaumont, esto representa aproximadamente el 50% de todos los dispositivos firewall de Fortinet que actualmente se encuentran en Internet.

Esta campaña se atribuye a un grupo ciberdelincuente ruso-hablante con múltiples operadores, cuya metodología va mucho más allá del simple robo de credenciales. El grupo rastreó sistemáticamente internet en busca de instancias Fortinet expuestas, probándolas con vastos repositorios de filtraciones históricas de credenciales obtenidas mediante malware de robo de información.

Una vez que se establece un punto de acceso inicial, los atacantes se dirigen directamente a entornos internos de Active Directory, lo que permite un acceso profundo y persistente a la red que sobrevive a las comprobaciones de seguridad rutinarias.

Uno de los vectores técnicos más alarmantes de la campaña es la interceptación activa de hashes de autenticación SSL VPN, que posteriormente se descifran sin conexión mediante un clúster dedicado de 45 GPU gestionado a través de Hashtopolis.

Esto significa que incluso las organizaciones que creen que sus credenciales cifradas son seguras están expuestas. Una vez que se vulnera el perímetro, los operadores monitorean el tráfico para obtener accesos adicionales, creando un ciclo de retroalimentación positiva de acceso no autorizado.

El alcance de las víctimas confirmadas abarca prácticamente todos los sectores de la economía global. La investigación de Diachenko confirmó la vulneración total de las redes de organizaciones en Japón, Taiwán, Vietnam, Irak y Turquía, incluyendo, de manera crucial, a un contratista de defensa turco de la OTAN del cual se extrajeron con éxito documentos de defensa clasificados.

La base de datos de credenciales verificadas de los atacantes incluye algunas de las empresas más grandes del planeta:

  • Tecnología y Manufactura: Foxconn, Samsung, Siemens, Lenovo, Oracle
  • Servicios Profesionales: PwC, Accenture
  • Telecomunicaciones: Comcast
  • y miles de entidades gubernamentales y proveedores de infraestructura crítica.

Quizás la conclusión más preocupante de este conjunto de datos es que la complejidad de las contraseñas no ofrecía ninguna protección. Un volumen significativo de contraseñas de 20 caracteres, altamente complejas, se vieron comprometidas no mediante su descifrado desde cero, sino porque ya existían en texto plano en bases de datos de ladrones de información previamente robadas.

Cuando las credenciales se roban en el punto final antes de que se aplique el cifrado, ninguna complejidad las protege. Esto socava fundamentalmente la política de "contraseñas seguras" como estrategia de defensa perimetral.

Las tácticas del grupo van más allá de la obtención y reutilización de credenciales. Se estima que los atacantes interceptan la autenticación SSL-VPN, descifran hashes en un clúster de 45 GPU administrado mediante Hashtopolis y acceden a entornos internos de Active Directory para su posterior explotación y persistencia. 

Hudson Rock lanzó un portal en línea especializado y SOCRadar otro diseñados específicamente para que las organizaciones verifiquen fácilmente si sus dominios están incluidos en la base de datos.

Según datos de SOCRadar, las cuentas de administrador genéricas (35%) y las cuentas integradas del sistema Fortinet (28,3%) constituyen la mayoría de las credenciales comprometidas. Las cuentas específicas de la organización representan el 36,7% del resto de las credenciales vulneradas.

Medidas de mitigación

Las organizaciones que utilizan dispositivos Fortinet deben tratar esto como una amenaza crítica y activa, y actuar de inmediato:

  • Rotación obligatoria de credenciales: Restablecer sin demora todas las contraseñas de la VPN y la interfaz de administración de Fortinet; la complejidad es irrelevante si las credenciales ya se han filtrado.
  • Implementar la autenticación multifactor universal: Aplicar la autenticación multifactor en todas las puertas de enlace externas para neutralizar las credenciales robadas en texto plano.
  • Registros de auditoría de la puerta de enlace: Revise los registros de acceso de Fortinet para detectar ubicaciones de inicio de sesión anómalas, sesiones de administrador inesperadas o volúmenes de tráfico inusuales.
  • Restricción de la exposición de la interfaz de administración: Aplique políticas de acceso local para restringir el acceso al panel de administración únicamente a direcciones IP internas de confianza y desactive el inicio de sesión único (SSO) de FortiCloud si no es esencial.

La campaña FortiBleed nos recuerda que la seguridad del perímetro depende de las credenciales que lo protegen, y en un mundo saturado de datos robados por ciberdelincuentes, el perímetro nunca ha sido tan frágil.

Actualización 18/06

Sólo en Argentina aparecen al menos 50 empresas y sitios gubernamentales afectados y ya hay evidencia de infección de ransomware debido a la explotación de esta vulnerabilidad.

Vulnerabilidades explotadas

En su publicación, Defused Cyber informó haber detectado la explotación de las vulnerabilidades CVE-2026-39813, CVE-2026-39808, y CVE-2026-25089 en las últimas 24 horas.

CVE-2026-39813 (CVSS: 9.1) se refiere a una vulnerabilidad de recorrido de ruta en la API JRPC de FortiSandbox que podría permitir a un atacante no autenticado eludir la autenticación mediante solicitudes HTTP especialmente diseñadas.

La segunda vulnerabilidad, CVE-2026-39808 (CVSS: 9.1), es un caso de inyección de comandos del sistema operativo que podría permitir a un atacante no autenticado ejecutar código o comandos no autorizados mediante solicitudes HTTP especialmente diseñadas. Fortinet corrigió ambas vulnerabilidades en abril de 2026.

Por otro lado, la vulnerabilidad CVE-2026-25089 (CVSS: 9.1) se solucionó la semana pasada. Fortinet la describió como una inyección de comandos del sistema operativo que afectaba a FortiSandbox, FortiSandbox Cloud y la interfaz web de FortiSandbox PaaS, y que podía permitir a un atacante no autenticado ejecutar comandos no autorizados mediante solicitudes HTTP especialmente diseñadas.

Defused Cyber ​​señaló que el exploit para CVE-2026-25089 no solo muestra indicios de haber sido desarrollado mediante un modelo de inteligencia artificial (IA), sino que además es defectuoso. Aún no se ha divulgado públicamente un exploit funcional para esta vulnerabilidad.

En los últimos años, las vulnerabilidades en los dispositivos Fortinet se han convertido en un objetivo prioritario para los atacantes. En abril de 2026, Fortinet publicó parches fuera de ciclo para una falla de seguridad crítica que afectaba a FortiClient EMS (CVE-2026-35616, CVSS: 9.1) y que, según la compañía, había sido explotada en la práctica.

Fuente: CyberSecurityNews

May 25, 2026

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

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

May 22, 2026

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

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

May 20, 2026

Phishing avanzando, EvilTokens y combinación tóxica de OAuth, MFA e IA para robar credenciales

En febrero de 2026, se lanzó EvilTokens, una plataforma de phishing como servicio (PhaaS). En tan solo cinco semanas, había comprometido a más de 340 organizaciones de Microsoft 365 en cinco países.

Las víctimas de la plataforma recibían un mensaje solicitándoles que introdujeran un código corto en microsoft.com/devicelogin y completaran su verificación MFA habitual. A continuación, creían haber iniciado sesión correctamente. En realidad, habían proporcionado al operador un token de actualización válido con acceso a su buzón, unidad, calendario y contactos, con una duración equivalente a la de una política de inquilino, no a la de una sesión.

El operador nunca necesitó introducir una contraseña, nunca se activó la solicitud de MFA y nunca se produjo ningún evento de inicio de sesión que pareciera una intrusión. El ataque tuvo éxito porque la pantalla de consentimiento de OAuth se ha convertido en un clic instintivo, y los controles diseñados para detener el phishing de credenciales no tienen en cuenta la capa de consentimiento.

Los investigadores de seguridad denominan a esta situación phishing de consentimiento o abuso de la concesión de OAuth. El clic de phishing que importaba la década pasada entregaba una contraseña. El clic de phishing que importa ahora entrega un token de actualización, y se sitúa estructuralmente por debajo de los controles de identidad que la mayoría de las organizaciones aún consideran el perímetro de seguridad.

¿Por qué la autenticación multifactor no puede ver una concesión de OAuth?

Un ataque de phishing de credenciales proporciona un nombre de usuario y una contraseña que deben ser reutilizados en algún lugar, y la mayoría de las plataformas de identidad ahora exigen un segundo factor de autenticación durante la reutilización. Incluso los kits de ataque de intermediario (AiTM) generan una cookie de sesión vinculada a un evento de inicio de sesión que el SIEM correlaciona con la geografía, el dispositivo y los patrones de viaje.

Una concesión OAuth no genera credenciales repetidas. El usuario se autentica en el proveedor de identidad legítimo, completa el desafío de MFA en el dominio legítimo y hace clic en Aceptar. El token que obtiene el atacante es el resultado del funcionamiento previsto del sistema. Está firmado por el proveedor de identidad, tiene el alcance acordado por el usuario y es actualizable. La MFA no puede bloquearlo porque ya se ha realizado.

El otro problema es que los tokens de actualización extienden la ventana de validez. Los tokens emitidos por EvilTokens sobrevivieron a los restablecimientos de contraseña y permanecieron válidos durante semanas o meses, según la configuración del inquilino. Cambiar la contraseña no invalidaba la concesión. Solo la revocación explícita o una política de acceso condicional que exigiera un nuevo consentimiento la cerraban.

Cómo se normalizó el consentimiento

Este vector de ataque existe desde que OAuth se convirtió en estándar. Lo que cambió es el entorno en el que opera. Los usuarios se han acostumbrado a aceptar las pantallas de consentimiento con la misma frecuencia con la que antes aceptaban las cookies. Todas las integraciones de productividad lo muestran. Todas las extensiones de navegador que interactúan con una cuenta SaaS lo muestran. El volumen de consentimientos legítimos que un trabajador del conocimiento ve en un mes supera con creces cualquier cosa que existiera cuando se redactaron los modelos de amenazas originales de OAuth.

Los ámbitos en sí mismos utilizan un lenguaje que no se corresponde claramente con el riesgo. Un ámbito llamado "Leer tu correo" suena limitado, pero en la práctica abarca todos los mensajes, archivos adjuntos e hilos compartidos a los que el usuario puede acceder. Un permiso denominado "Acceder a archivos sin estar presente" implica un token de larga duración emitido sin que el usuario esté frente a una pantalla para revocarlo. La brecha entre el lenguaje de consentimiento y el alcance operativo es precisamente donde operan los atacantes.

Combinaciones tóxicas se forman bajo el control del propietario de la aplicación.

Un único consentimiento de OAuth proporciona a un atacante un punto de acceso limitado dentro de una aplicación. El riesgo aumenta cuando esos puntos de acceso se conectan.

Un usuario del departamento de finanzas otorga a un resumidor de reuniones con IA acceso a su calendario y buzón de correo. Posteriormente, el mismo usuario otorga a un asistente de productividad acceso a la unidad compartida de la empresa. Un tercer permiso conecta una herramienta de enriquecimiento de CRM con la base de datos de clientes. Cada uno se aprobó individualmente. Ningún propietario de la aplicación autorizó la combinación. La superficie de riesgo ahora son tres ámbitos que se cruzan a través de una misma identidad humana, donde la vulnerabilidad del resumidor de reuniones puede acceder a borradores de contratos y registros de clientes a través de la misma persona.

Esto se denomina combinación tóxica. Consiste en una distribución de permisos entre aplicaciones, mediada por una concesión OAuth, una integración o un agente de IA, que ningún propietario de aplicación autorizó como su propia superficie de riesgo. No se puede observar en el registro de auditoría de ninguna aplicación, ya que la conexión existe fuera de todas ellas.

La instalación de MCP, el clic de consentimiento de OAuth y la concesión de la extensión del navegador: cada uno de estos pasos se realiza con un solo clic. Los servidores del Protocolo de Contexto de Modelo (MCP) se están convirtiendo en la próxima superficie de ataque al estilo OAuth, permitiendo a los agentes obtener acceso restringido mediante el mismo mecanismo de confianza única que ya utilizan las pantallas de consentimiento.

El incidente Salesloft-Drift de 2025 demostró cómo se manifiesta esto a gran escala. Un conector descendente comprometido se propagó a más de 700 clientes de Salesforce mediante tokens de OAuth que los clientes habían aprobado legítimamente. Todos los clientes autorizaron la integración, pero ninguno autorizó la propagación.

Fuente: THN

May 12, 2026

Nuevo ataque Shai Hulud firman paquetes NPM maliciosos

Cientos de paquetes de npm y PyPI se han visto comprometidos en una nueva campaña de la cadena de suministro de Shai-Hulud que entrega malware de robo de credenciales dirigido a desarrolladores.

El atacante secuestró tokens válidos de OpenID Connect (OIDC) para publicar versiones de paquetes maliciosos con certificación de procedencia verificable (SLSA Build Level 3). Atribuido al grupo de amenazas TeamPCP, el ataque comenzó comprometiendo docenas de paquetes de IA TanStack y Mistral, pero rápidamente se extendió a otros proyectos populares, como Guardrails AI, UiPath y OpenSearch.

La campaña Shai-Hulud surgió en septiembre pasado y tuvo múltiples iteraciones [1, 2, 3], algunas de las cuales expusieron cientos de miles de secretos de desarrolladores en repositorios de GitHub generados automáticamente. Entre los proyectos comprometidos más recientemente se encuentran el paquete CLI de Bitwarden y los paquetes oficiales de SAP.

La última ola de ataques ocurrió ayer cuando el actor de amenazas publicó múltiples paquetes maliciosos en los espacios de nombres de TanStack en Node Package Manager (npm) y luego se propagó a otros proyectos utilizando credenciales de CI/CD robadas.

La empresa de seguridad de aplicaciones StepSecurity señala que el actor de amenazas publicó los paquetes infectados a través de la canalización CI/CD legítima, con certificaciones de procedencia SLSA válidas emitidas por la infraestructura de firma de npm y "vinculadas al flujo de trabajo de lanzamiento legítimo de TanStack/router".

Endor Labs informa más de 160 paquetes comprometidos en npm, Aikido registró 373 entradas de versiones de paquetes maliciosos y Socket rastreó 416 artefactos de paquetes comprometidos en npm y el índice de paquetes de Python (PyPI).

Según el informe post-mortem de TanStack, los atacantes encadenaron tres vulnerabilidades: un flujo de trabajo riesgoso 'pull_request-target', envenenamiento de la caché de GitHub Actions y robo de tokens OIDC de la memoria del corredor.

Los atacantes publicaron 84 versiones maliciosas en 42 paquetes TanStack que tenían procedencia válida, certificaciones Sigstore válidas y firmas legítimas de GitHub Actions. Desde la perspectiva del desarrollador, los paquetes parecían ser criptográficamente auténticos y no había indicios de compromiso.

Endor Labs destaca un ingenioso truco de confirmación de Git en el que los atacantes abusaron de una confirmación huérfana enviada a una bifurcación del repositorio TanStack/router, haciéndola accesible a través del almacenamiento de objetos bifurcado compartido de GitHub aunque no perteneciera a ninguna rama.

Se hizo referencia a la confirmación a través de una dependencia opcional maliciosa, lo que provocó que npm buscara y ejecutara automáticamente código controlado por el atacante durante la instalación del paquete.

El malware apunta a secretos de los desarrolladores, que incluyen:

  • Tokens OIDC y PAT de GitHub Actions
  • Credenciales de git
  • Tokens de publicación npm
  • Credenciales de tareas de AWS Secrets Manager, IAM y ESC
  • Tokens de cuenta de servicio de Kubernetes y credenciales de clúster
  • Token de bóveda de HashiCorp
  • Claves SSH
  • Configuraciones del Código Claude
  • Tareas de código VS
  • archivos .env

StepSecurity dice que la carga útil lee la memoria del proceso de GitHub Actions para recopilar credenciales de más de 100 rutas de archivos asociadas con proveedores de nube, tokens de criptomonedas y aplicaciones de mensajería.

Para filtrar la información confidencial, el malware utilizó la red Session P2P, haciéndola aparecer como tráfico de mensajería cifrado y complicando los esfuerzos de detección, bloqueo y eliminación.

Una vez que se produce una infección, el malware se escribe en los hooks de Claude Code y en las tareas de ejecución automática de VS Code, por lo que la desinstalación de los paquetes maliciosos no lo elimina.

El mecanismo de autopropagación permanece prácticamente sin cambios con respecto a oleadas anteriores: utiliza credenciales de GitHub/npm robadas, enumera los paquetes vinculados al mantenedor comprometido, modifica archivos tar para inyectar la carga útil y luego vuelve a publicar versiones maliciosas.

Según la plataforma de seguridad de la cadena de suministro SafeDep, aunque el mecanismo de activación es diferente en los paquetes Mistral AI y TanStack comprometidos, arrojan la misma carga útil de robo de credenciales.

Microsoft Threat Intelligence analizó la carga útil entregada a través de un paquete malicioso de IA Mistral en PyPI. El actor lo llamó 'transformers.pyz', que puede ser para hacerse pasar por la biblioteca Python de código abierto de Hugging Face que Transformers utiliza para acceder a modelos previamente entrenados para el procesamiento del lenguaje natural.

Los investigadores dicen que la carga útil lanza un malware que roba información en los sistemas Linux. El ladrón incluye una lógica básica de geofencing, evitando específicamente la ejecución en hosts donde se detecta la configuración del idioma ruso.

También está presente una rutina secundaria destructiva. En entornos que parecen originarse en Israel o Irán, el malware introduce un mecanismo de sabotaje probabilístico con una probabilidad de 1 entre 6 de ejecutar un comando de borrado recursivo (rm -rf/).

El comportamiento se asemeja a la campaña CanisterWorm que TeamPCP implementó en marzo y se centró en las plataformas Kubernetes. Si CanisterWorm aterrizara en máquinas que coincidieran con la zona horaria y la configuración regional de Irán, las borraría.

Las listas de paquetes comprometidos están disponibles en los informes de varios proveedores de seguridad [1, 2, 3, 4, 5],, y se recomienda verificar todos los recursos para obtener una vista completa del impacto.

Los desarrolladores que descargaron una versión de paquete afectada deben asumir que las credenciales estuvieron expuestas. Los investigadores recomiendan que los equipos de seguridad tomen las siguientes medidas:

  • comprobar las versiones de paquetes afectadas
  • comprobar la persistencia en las máquinas de desarrollador
  • rotar todas las credenciales (tokens de GitHub, tokens de npm, credenciales de AWS, tokens de Vault, cuentas de servicio de Kubernetes y secretos de CI/CD)
  • auditar los directorios IDE en busca de archivos maliciosos que sobrevivan a la instalación de npm (por ejemplo, router_runtime.js o setup.mjs)
  • bloquear la infraestructura de comando y control del actor de amenazas (api.masscan.cloud, git-tanstack.com y *.getsession.org) a nivel de DNS o proxy

Los investigadores de Snyk dicen que dado que "el ataque produce certificaciones SLSA Build Nivel 3 válidas para paquetes maliciosos", es necesario verificar la procedencia y agregar una capa de análisis de comportamiento en el momento de la instalación, junto con una verificación basada en firmas para paquetes maliciosos.

A largo plazo, para mitigar el riesgo de ataques similares, considere imponer instalaciones de solo archivos de bloqueo, lo que debería evitar las actualizaciones automáticas/silenciosas de paquetes.

Fuente: BC

May 10, 2026

Portales de acceso a Canvas hackeados en una campaña masiva de extorsión de ShinyHunters

La banda de extorsionadores ShinyHunters ha vuelto a vulnerar la seguridad de Instructure, gigante de la tecnología educativa, esta vez explotando una vulnerabilidad para alterar los portales de acceso a Canvas de cientos de universidades.

Los ataques, que estuvieron visibles durante aproximadamente 30 minutos antes de ser desactivados, mostraban un mensaje de ShinyHunters reivindicando la autoría del anterior ataque a Instructure y amenazando con filtrar los datos robados si no se pagaba un rescate.

El mensaje advierte que Instructure y las instituciones educativas tienen hasta el 12 de mayo para contactarlos y negociar un rescate, o los datos de los estudiantes serán filtrados. "ShinyHunters ha vuelto a vulnerar Instructure. En lugar de contactarnos para resolverlo, nos ignoraron e hicieron algunos 'parches de seguridad'", se lee en el mensaje.

Los ciberdelincuentes alteraron los portales de inicio de sesión de Canvas de aproximadamente 330 instituciones educativas, reemplazando las páginas de inicio de sesión estándar con un mensaje de extorsión. Este mensaje también apareció en la aplicación Canvas.

Supuestamente, la alteración se debió a una vulnerabilidad en los sistemas de Instructure que permitió al atacante modificar los portales de inicio de sesión. Instructure ha suspendido el servicio de Canvas mientras responde al último ciberataque.

La semana pasada, Instructure reveló que estaba investigando un ciberataque después de que ciberdelincuentes afirmaran haber robado 280 millones de registros de estudiantes y personal de 8.809 escuelas, universidades y plataformas educativas que utilizan su sistema de gestión del aprendizaje Canvas.

Posteriormente, el grupo ShinyHunters informó a BleepingComputer que los datos robados incluían registros de usuarios, mensajes privados, datos de matrícula y otra información supuestamente recopilada a través de las funciones de exportación de datos y las API de Canvas. Instructure confirmó que se robaron datos durante el ataque, pero que continúa investigando el incidente.

Canvas es uno de los sistemas de gestión del aprendizaje más utilizados en la educación superior y primaria/secundaria, y ayuda a los centros educativos a gestionar cursos, tareas, calificaciones y la comunicación entre estudiantes y profesores.

El nombre ShinyHunters se ha asociado durante mucho tiempo con numerosos ciberdelincuentes que han perpetrado filtraciones de datos desde 2018. Este año, los ciberdelincuentes que utilizan el nombre ShinyHunters se han convertido en uno de los grupos más prolíficos que llevan a cabo ataques de robo de datos y extorsión contra empresas en todo el mundo.

Fuente: BC

May 7, 2026

"Tu mayor riesgo de seguridad no es el malware, sino aquello en lo que ya confías"

Durante años, la ciberseguridad se ha basado en una premisa simple: detectar malware y detener el ataque. Este modelo está empezando a fallar.

Los atacantes ya no dependen principalmente de archivos maliciosos o cargas útiles obvias. En cambio, recurren cada vez más a lo que ya existe en su entorno: herramientas de confianza, binarios nativos y utilidades administrativas legítimas. Estas se utilizan para moverse lateralmente, escalar privilegios y mantener la persistencia, a menudo sin activar las alertas de seguridad tradicionales.

¿El problema? La mayoría de las organizaciones no reconocen esta vulnerabilidad hasta que el daño ya está hecho. Esto es lo que realmente sucede en los entornos modernos y por qué los atacantes prefieren usar sus propias herramientas en su contra.

¿La herramienta más mal utilizada? Netsh.exe

Si bien las herramientas de bajo costo son un tema ampliamente tratado, la mayoría de los análisis previos se han basado en la experiencia, no en datos concretos. Estos datos se basan en el análisis de la frecuencia de uso de las herramientas, en lugar del daño que podrían causar. 

Lo que resultó evidente de inmediato es que las herramientas más utilizadas por los atacantes también lo son por los administradores. Los sospechosos habituales, como powershell.exe, wscript.exe y cscript.exe, estaban presentes. Sin embargo, uno de los hallazgos más sorprendentes fue que netsh.exe era la herramienta más utilizada indebidamente, apareciendo en un tercio de los ataques importantes. Si bien revisar la configuración del firewall es un paso inicial lógico para los atacantes, esto demuestra claramente cómo el análisis de datos puede revelar tendencias que los operadores humanos podrían pasar por alto instintivamente. Estas son las cinco herramientas más utilizadas indebidamente:

  • Netsh.exe: Los administradores utilizan esta utilidad de línea de comandos para la gestión de la configuración de red, incluyendo firewalls, interfaces y enrutamiento.
  • PowerShell.exe: Conocido como la "navaja suiza" de la administración de Windows, PowerShell es un intérprete de comandos y lenguaje de scripting versátil.
  • Reg.exe: Esta herramienta de línea de comandos permite a los administradores consultar, modificar, agregar o eliminar entradas del registro, y los ciberdelincuentes la utilizan con frecuencia para establecer persistencia. C
  • sc.exe: El compilador de C# de Microsoft es una herramienta de línea de comandos para compilar código fuente de C# en ensamblados ejecutables (archivos .exe) o bibliotecas de vínculos dinámicos (archivos .dll).
  • Rundll32.exe: Esta utilidad del sistema carga y ejecuta funciones exportadas desde archivos DLL. Se usa frecuentemente para ataques de carga lateral de DLL.

La popularidad de las herramientas entre los atacantes suele reflejar su popularidad entre los administradores legítimos. Esta tendencia general se mantuvo en la mayoría de los casos, pero surgieron algunas excepciones notables. En concreto, los ciberdelincuentes utilizan herramientas como mshta.exe, pwsh.exe y bitsadmin.exe, pero los administradores rara vez las usan.

Los ataques están diseñados para no parecer ataques.

Los ciberdelincuentes modernos no quieren destacar, sino pasar desapercibidos.

Los datos de más de 700.000 incidentes de alta gravedad muestran un patrón claro: el 84% de los ataques implican el uso indebido de herramientas legítimas para evitar ser detectados. Este enfoque, conocido como "aprovecharse de las herramientas existentes" (LOTL, por sus siglas en inglés), se ha convertido en la norma.

En lugar de introducir ejecutables maliciosos, los atacantes recurren a utilidades integradas como PowerShell, WMIC o Certutil, herramientas que ya son de confianza y ampliamente utilizadas por los equipos de TI. Su actividad imita fielmente las operaciones normales, lo que dificulta enormemente distinguir entre la administración legítima y el comportamiento malicioso.

Esto crea un punto ciego importante. Los equipos de seguridad ya no se limitan a buscar indicadores conocidos de compromiso, sino que intentan interpretar la intención basándose en el comportamiento, a menudo en tiempo real y sin el contexto completo.

Para cuando algo parece claramente sospechoso, el atacante suele estar ya bien posicionado dentro del entorno.

Tu superficie de ataque es mayor —y menos controlada— de lo que crees.

La mayoría de las organizaciones subestiman la exposición de su entorno.

Tomemos como ejemplo un equipo estándar con Windows 11. De fábrica, incluye cientos de binarios nativos, muchos de los cuales pueden utilizarse en ataques tipo LOTL (Load to Live). Estas herramientas gozan de confianza inherente, están profundamente integradas en el sistema operativo y, a menudo, son necesarias para un uso legítimo.

Esto plantea un dilema complejo:

  • Bloquearlas por completo puede interrumpir flujos de trabajo críticos para el negocio.
  • Supervisarlas de cerca puede generar un ruido abrumador.

Además, en muchos casos, las organizaciones carecen de visibilidad clara sobre dónde y cómo se puede acceder a estas herramientas.

Las investigaciones demuestran que hasta el 95% del acceso a herramientas potencialmente riesgosas es innecesario. En muchos entornos, los usuarios —y a veces las aplicaciones— tienen mucho más acceso del que realmente necesitan. A esto se suma que a menudo se permite a las herramientas realizar todas las funciones disponibles, incluidas aquellas que rara vez se utilizan en las operaciones diarias, pero que los atacantes explotan con frecuencia.

Cada permiso innecesario amplía la superficie de ataque. Cuando los atacantes pueden operar completamente dentro de los recursos ya disponibles, las defensas tradicionales se encuentran inmediatamente en desventaja.

La detección por sí sola ya no es suficiente.

Las tecnologías de detección no han fallado; han obligado a los atacantes a adaptarse.

Soluciones como EDR y XDR siguen siendo muy eficaces para identificar malware y comportamientos claramente anómalos. Pero cuando los atacantes operan con herramientas legítimas, la detección se vuelve mucho más ambigua. Los equipos de seguridad se preguntan: ¿Es este comando de PowerShell el esperado? ¿Es normal la ejecución de este proceso?

Al mismo tiempo, la velocidad de los ataques está aumentando.

Las campañas modernas, a menudo aceleradas por la automatización y la IA, pueden avanzar más rápido de lo que los equipos pueden investigar. Para cuando se valida una alerta, los atacantes ya pueden haber logrado moverse lateralmente y establecido persistencia.

Por eso, confiar únicamente en la detección ya no es suficiente. El reto no consiste solo en detectar las amenazas, sino en reducir las oportunidades que tienen los atacantes desde un principio.

La brecha de visibilidad: Lo que la mayoría de los equipos no ven

Comprender la superficie de ataque interna parece sencillo en teoría. En la práctica, rara vez se hace bien.

La mayoría de las organizaciones tienen dificultades para responder preguntas fundamentales:

  • ¿Qué herramientas son realmente accesibles en todo el entorno?
  • ¿Dónde el acceso es excesivo o innecesario?
  • ¿Cómo se traducen estos patrones de acceso en rutas de ataque reales y explotables?

Incluso cuando los equipos son conscientes del riesgo conceptualmente, cuantificarlo —y priorizar las acciones— es difícil. Esa falta de claridad es precisamente lo que permite que estas vulnerabilidades persistan.

De reactivo a proactivo

Cerrar esta brecha no comienza con la implementación de otra herramienta de seguridad. Comienza con la visibilidad.

La evaluación de la superficie de ataque interna proporciona una visión clara y basada en datos de cómo las herramientas de confianza pueden estar aumentando la exposición. Ayuda a identificar el acceso innecesario, resaltar el riesgo real y priorizar la remediación, sin interrumpir a los usuarios ni generar costos operativos adicionales.

Vea su entorno como lo ven los atacantes.

Las técnicas LOTL se están convirtiendo rápidamente en la norma, en lugar de la excepción. Esto cambia el enfoque de la seguridad.

Los riesgos más importantes ya no son externos ni desconocidos: ya están dentro de su entorno.

Comprender cómo los atacantes pueden moverse utilizando herramientas de confianza es el primer paso para limitar esas vías y detener un ataque antes de que se desarrolle por completo.

Para comprender mejor cómo se manifiesta este riesgo en entornos reales, Bitdefender ofrece una Evaluación Interna de la Superficie de Ataque gratuita: una forma práctica y sencilla de descubrir dónde las herramientas de confianza pueden estar trabajando en su contra.

Fuente: THN

May 1, 2026

Ubuntu interrumpido por ataque DDoS

Un grupo de hacktivistas se atribuyó la responsabilidad de la caída de la infraestructura pública de Ubuntu, la popular distribución del sistema operativo Linux, así como de Canonical, la empresa que desarrolla y mantiene el software. El ataque comenzó el jueves y continúa afectando a servicios esenciales para los usuarios de Ubuntu.

"La infraestructura web de Canonical está sufriendo un ataque transfronterizo sostenido y estamos trabajando para solucionarlo. Proporcionaremos más información a través de nuestros canales oficiales tan pronto como sea posible", declaró la empresa en su sitio web.

Los servicios impactados son los siguientes:

Se cree que los hacktivistas lanzaron un ataque de denegación de servicio distribuido (DDoS), un ataque rudimentario pero a menudo efectivo que consiste en saturar un objetivo con tráfico basura hasta sobrecargarlo o colapsarlo.

Los desarrolladores de Ubuntu han estado debatiendo el ataque en un foro no oficial de la comunidad, afirmando que afecta a la API de seguridad de Ubuntu y a varios sitios web de Ubuntu y Canonical. Según una publicación en un foro de inteligencia sobre amenazas, el ataque DDoS también ha impedido a los usuarios actualizar e instalar Ubuntu. TechCrunch verificó que las actualizaciones no se instalaron en un dispositivo de prueba con Ubuntu.

Los hacktivistas que se hacen llamar The Islamic Cyber Resistance in Iraq 313 Team afirmaron en su canal de Telegram ser los responsables del ataque DDoS. El grupo afirmó estar utilizando Beamed, un servicio de DDoS por encargo.

Este tipo de servicios, también conocidos como booters o stressers, permiten a cualquier persona pagar para lanzar ataques DDoS, incluso sin conocimientos técnicos ni la infraestructura necesaria para saturar los objetivos con tráfico falso. En este caso, el servicio de ataques DDoS por encargo afirma tener capacidad para realizar ataques de más de 3,5 Tbps, lo que representa aproximadamente la mitad del ancho de banda de un ciberataque que Cloudflare calificó el año pasado como el "mayor ataque DDoS jamás registrado".

Fuente: TechCrunch

Apr 29, 2026

Paquetes oficiales de SAP npm comprometidos para robar credenciales

Varios paquetes oficiales de SAP npm se vieron comprometidos en lo que se cree que fue un ataque a la cadena de suministro de TeamPCP para robar credenciales y tokens de autenticación de los sistemas de los desarrolladores.

Los investigadores informan que la vulneración afectó a cuatro paquetes, cuyas versiones ahora están descontinuadas en NPM:

  • @cap-js/sqlite – v2.2.2
  • @cap-js/postgres – v2.2.2
  • @cap-js/db-service – v2.10.1
  • mbt – v1.2.48

Estos paquetes son compatibles con el Modelo de Programación de Aplicaciones en la Nube (CAP) y Cloud MTA de SAP, que se utilizan comúnmente en el desarrollo empresarial.

Según nuevos informes de Aikido y Socket, los paquetes comprometidos fueron modificados para incluir un script malicioso de "preinstalación" que se ejecuta automáticamente al instalar el paquete npm. Este script inicia un cargador llamado setup.mjs que descarga el entorno de ejecución Bun JavaScript de GitHub y lo utiliza para ejecutar un payload execution.js altamente ofuscada.

El payload es un programa de robo de información utilizado para sustraer una amplia variedad de credenciales tanto de máquinas de desarrolladores como de entornos de CI/CD, incluyendo:

  • Tokens de autenticación de npm y GitHub
  • Claves SSH y credenciales de desarrollador
  • Credenciales en la nube para AWS, Azure y Google Cloud
  • Configuración y secretos de Kubernetes
  • Secretos y variables de entorno de la canalización de CI/CD

El malware también intenta extraer secretos directamente de la memoria del ejecutor de CI, de forma similar a como TeamPCP extrajo credenciales en ataques anteriores a la cadena de suministro.

Un payload de Python extrae cada secreto que coincida con "key": { "value": "...", "isSecret": true}. Este escáner de memoria para secretos es estructuralmente idéntico al documentado en los incidentes de Bitwarden y Checkmarx.

Una vez recopilados los datos, se cifran y se suben a repositorios públicos de GitHub bajo la cuenta de la víctima. Estos repositorios incluyen la descripción "A Mini Shai-Hulud has Appeared", similar a la cadena "Shai-Hulud: The Third Coming" vista en el ataque a la cadena de suministro de Bitwarden.

El malware también utiliza búsquedas de commits de GitHub como mecanismo de punto de entrega para recuperar tokens y obtener acceso adicional. "El malware busca esta cadena en los commits de GitHub y utiliza los mensajes de commit coincidentes como punto de entrega de tokens", explica Aikido.

Al igual que en ataques anteriores, la carga útil desplegada también incluye código para autopropagarse a otros paquetes. Utilizando credenciales robadas de npm o GitHub, intenta modificar otros paquetes y repositorios a los que accede e inyecta el mismo código malicioso para propagarse aún más.

Los investigadores han vinculado este ataque con un grado de confianza medio al grupo de ciberdelincuentes TeamPCP, que utilizó código y tácticas similares en ataques anteriores a la cadena de suministro contra Trivy, Checkmarx y Bitwarden.

Si bien no está claro cómo los ciberdelincuentes comprometieron el proceso de publicación de npm de SAP, el ingeniero de seguridad Adnan Khan informa que un token de NPM podría haber quedado expuesto a través de una configuración incorrecta de un trabajo de CircleCI.

Fuente: BC

Apr 25, 2026

"Copitos de nieve": Empleo de Ingeniería Social para engañar directivos y desplegar malware personalizado.

Se ha detectado un grupo de amenazas previamente no documentado, conocido como UNC6692, que utiliza tácticas de ingeniería social a través de Microsoft Teams para desplegar un conjunto de malware personalizado en equipos comprometidos.

"Al igual que muchas otras intrusiones en los últimos años, UNC6692 se basó en gran medida en la suplantación de identidad de empleados del servicio de asistencia técnica de TI, convenciendo a la víctima de aceptar una invitación de chat de Microsoft Teams desde una cuenta ajena a su organización", afirmó Mandiant, propiedad de Google, en un informe publicado hoy.

Se ha atribuido a UNC6692 una campaña masiva de correo electrónico diseñada para saturar la bandeja de entrada de la víctima con un aluvión de correos no deseados, creando una falsa sensación de urgencia. El atacante se pone en contacto con la víctima a través de Microsoft Teams enviando un mensaje en el que afirma ser del equipo de soporte técnico de TI para ofrecer ayuda con el problema del bombardeo de correo electrónico.

Cabe destacar que esta combinación de bombardeo de la bandeja de entrada de correo electrónico de la víctima, seguido de la suplantación de identidad del servicio de asistencia técnica a través de Microsoft Teams, es una táctica utilizada desde hace tiempo por antiguos afiliados de Black Basta. A pesar de que el grupo cesó sus operaciones de ransomware a principios del año pasado, esta táctica no muestra signos de desaceleración.

En un informe publicado la semana pasada, ReliaQuest reveló que se está utilizando para atacar a ejecutivos y empleados de alto nivel con el fin de obtener acceso inicial a las redes corporativas para el posible robo de datos, el movimiento lateral, el despliegue de ransomware y la extorsión. En algunos casos, las conversaciones se iniciaron con tan solo 29 segundos de diferencia.

El objetivo de la conversación es engañar a las víctimas para que instalen herramientas legítimas de monitoreo y administración remota (RMM), como Quick Assist o Supremo Remote Desktop, para permitir el acceso directo, y luego utilizarlas como arma para instalar cargas maliciosas adicionales.


"Del 1 de marzo al 1 de abril de 2026, el 77% de los incidentes observados tuvieron como objetivo a empleados de alto nivel, un aumento con respecto al 59% registrado en los dos primeros meses de 2026", afirmaron los investigadores de ReliaQuest, John Dilgen y Alexa Feminella. "Esta actividad demuestra que las tácticas más efectivas de un grupo de ciberdelincuentes pueden perdurar mucho más allá de la propia desaparición del grupo".

La cadena de ataque detallada por Mandiant, por otro lado, se desvía de este enfoque, ya que se instruye a la víctima a hacer clic en un enlace de phishing compartido a través del chat de Teams para instalar un parche local que solucione el problema del spam. Al hacer clic, se descarga un script de AutoHotkey desde un bucket de AWS S3 controlado por el atacante. La página de phishing se llama "Mailbox Repair and Sync Utility v2.1.5".

El script está diseñado para realizar un reconocimiento inicial y luego instalar SNOWBELT, una extensión de navegador maliciosa basada en Chromium, en el navegador Edge, ejecutándola en modo sin interfaz gráfica junto con el parámetro de línea de comandos "--load-extension".

"El atacante utilizó un script de control diseñado para garantizar que la carga útil se entregue solo a los objetivos previstos, evadiendo así los entornos de pruebas de seguridad automatizados", afirmaron los investigadores de Mandiant JP Glab, Tufail Ahmed, Josh Kelley y Muhammad Umair.

El script también verifica el navegador de la víctima. Si el usuario no utiliza Microsoft Edge, la página muestra una advertencia superpuesta persistente. Mediante la extensión SNOWBELT, UNC6692 descargó archivos adicionales, incluyendo SNOWGLAZE, SNOWBASIN, scripts de AutoHotkey y un archivo ZIP que contiene un ejecutable de Python portátil y las bibliotecas necesarias.

La página de phishing también está diseñada para mostrar un Panel de administración de configuración con un botón destacado de "Verificación de estado" que, al hacer clic, solicita a los usuarios que ingresen sus credenciales de correo electrónico con un supuesto fin de autenticación, pero que, en realidad, se utiliza para recopilar y extraer los datos a otro bucket de Amazon S3.

El ecosistema de malware SNOW es un conjunto de herramientas modulares que funcionan en conjunto para facilitar los objetivos del atacante. Mientras que SNOWBELT es una puerta trasera basada en JavaScript que recibe comandos y los reenvía a SNOWBASIN para su ejecución, SNOWGLAZE es un tunelizador basado en Python que crea un túnel WebSocket seguro y autenticado entre la red interna de la víctima y el servidor de comando y control (C2) del atacante.

El tercer componente es SNOWBASIN, que funciona como una puerta trasera persistente para permitir la ejecución remota de comandos mediante "cmd.exe" o "powershell.exe", la captura de pantallas, la carga y descarga de archivos y la autodestrucción. Se ejecuta como un servidor HTTP local en los puertos 8000, 8001 o 8002.

Algunas de las acciones posteriores a la explotación que realiza UNC6692 tras obtener acceso inicial son las siguientes:

  • Utiliza un script de Python para escanear la red local en busca de movimientos laterales en los puertos 135, 445 y 3389, establece una sesión PsExec con el sistema de la víctima mediante la utilidad de tunelización SNOWGLAZE e inicia una sesión RDP a través del túnel SNOWGLAZE desde el sistema de la víctima a un servidor de respaldo.
  • Utiliza una cuenta de administrador local para extraer la memoria del proceso LSASS del sistema con el Administrador de tareas de Windows para escalar privilegios.
  • Utiliza la técnica Pass-The-Hash para acceder lateralmente a los controladores de dominio de la red mediante los hashes de contraseñas de usuarios con privilegios elevados, descargue y ejecute FTK Imager para capturar datos confidenciales (por ejemplo, archivos de la base de datos de Active Directory) y escríbalos en la carpeta \Downloads, y exfiltre dichos datos mediante la herramienta de carga de archivos LimeWire.

"La campaña UNC6692 demuestra una interesante evolución en las tácticas, en particular el uso de ingeniería social, malware personalizado y una extensión de navegador maliciosa, que se aprovecha de la confianza inherente de la víctima en varios proveedores de software empresarial", declaró el gigante tecnológico.

Un elemento crucial de esta estrategia es el abuso sistemático de servicios legítimos en la nube para la distribución y exfiltración de malware, así como para la infraestructura de comando y control (C2). Al alojar componentes maliciosos en plataformas en la nube de confianza, los atacantes suelen eludir los filtros de reputación de red tradicionales y mimetizarse con el elevado volumen de tráfico legítimo en la nube.

Esta revelación surge a raíz de que Cato Networks detallara una campaña de phishing por voz que utiliza una suplantación de identidad similar a la de un servicio de asistencia técnica en Microsoft Teams para guiar a las víctimas a ejecutar un troyano basado en WebSocket, denominado PhantomBackdoor, mediante un script de PowerShell ofuscado obtenido de un servidor externo.

"Este incidente demuestra cómo la suplantación de identidad del servicio de asistencia técnica, realizada a través de una reunión de Microsoft Teams, puede reemplazar el phishing tradicional y tener el mismo resultado: la ejecución simulada de PowerShell seguida de una puerta trasera WebSocket", afirmó la empresa de ciberseguridad. "Los responsables de la seguridad deben considerar las herramientas de colaboración como superficies de ataque prioritarias, reforzando los flujos de trabajo de verificación del servicio de asistencia técnica, reforzando los controles externos de Teams y de uso compartido de pantalla, y protegiendo PowerShell".

Fuente: THN