La eliminación del malware GlassWorm interrumpe la infraestructura de ataque a la cadena de suministro de los desarrolladores – CYBERDEFENSA.MX

CrowdStrike, en asociación con Google y Shadowserver Foundation, ha anunciado la interrupción simultánea de todos los canales de comando y control (C2) asociados con GlassWorm, una campaña de cadena de software persistente dirigida a desarrolladores de software a través de paquetes y extensiones maliciosos.

«Desde al menos principios de 2025, los operadores de GlassWorm se han dirigido sistemáticamente a los desarrolladores de software, una población con acceso a repositorios de código fuente, plataformas en la nube, canales de CI/CD y registros de paquetes», CrowdStrike dicho.

El desarrollo se produce cuando los desarrolladores se han convertido en objetivos cada vez más lucrativos para realizar ataques a la cadena de suministro de software, lo que permite a los atacantes aprovechar una única estación de trabajo comprometida para impactar a miles de organizaciones y usuarios a la vez.

GlassWorm, desde su aparición el año pasado, ha llevado a cabo una «campaña multifacética» que utiliza extensiones de VS Code troyanizadas publicadas tanto en Microsoft VS Code Marketplace como en Open VSX, lo que permite dirigirse a usuarios de bifurcaciones de VS Code como Cursor, Positron, Windsurf y VSCodium.

Ciberseguridad

También se sabe que la campaña introdujo código malicioso a través de paquetes npm y Python comprometidos. El objetivo final de los ataques es ofrecer un marco de robo de datos con capacidades de recolección de credenciales, exfiltración de billeteras de criptomonedas y creación de perfiles del sistema.

Se ha descubierto que iteraciones posteriores de GlassWorm implementan una RAT de JavaScript basada en Websocket llamada GlassWormRAT para robar datos del navegador web y ejecutar código arbitrario, incluida la instalación de una extensión de Google Chrome que, a su vez, recopila datos confidenciales, incluidas capturas de pantalla, pulsaciones de teclas y contenido del portapapeles, del sistema infectado.

«Una vez activo, el malware busca en el host credenciales de desarrollador (GitHub, NPM, tokens OpenVSX, billeteras criptográficas), lo que permite comprometer aún más los repositorios y las cargas de paquetes», dijo el investigador de Endor Labs, Kiran Raj. dicho.

«Los hosts infectados se convierten en infraestructura encubierta: proxies SOCKS, servidores VNC (HVNC) ocultos y nodos de ejecución remota (a través de WebRTC o procesos Node.js generados). Eso les da a los atacantes acceso anónimo a redes corporativas y personales y una plataforma para propagarse más».

En conjunto, se dice que la actividad maliciosa ha envenenado más de 300 repositorios de GitHub utilizando credenciales de desarrollador robadas. Lo que hizo que la operación fuera notable fue el uso de cuatro canales C2 distintos para mejorar la resiliencia:

«La combinación de blockchain, peer-to-peer y servicios web legítimos como capas de resolución fue diseñada para ser resistente contra derribos: un frente dinámico que protege los servidores C2 reales detrás de múltiples capas de indirección», dijo CrowdStrike.

Ciberseguridad

Como resultado de la eliminación, los cuatro canales han sido neutralizados simultáneamente en un esfuerzo coordinado para que las máquinas infectadas ya no puedan recibir nuevas instrucciones o cargas útiles.

Al describir a los operadores de GlassWorm como «con buenos recursos y persistentes», la compañía de ciberseguridad atribuyó la actividad a probables ciberdelincuentes con sede en Rusia, dado que el malware finaliza la ejecución en sistemas ubicados en los países de la Comunidad de Estados Independientes (CEI) y contiene comentarios en ruso.

«La cadena de suministro de software sigue siendo una de las superficies de ataque más importantes en la informática moderna», concluyó CrowdStrike. «Los adversarios están convirtiendo la dependencia de una organización de herramientas, actualizaciones y bibliotecas en mecanismos de entrega armados y multiplicadores de fuerza».

«La barrera para envenenar un paquete o extensión es baja; el radio potencial de explosión es enorme. Mientras los entornos de desarrollo, los canales de construcción y los repositorios de código permanezcan desprotegidos, cada organización que consume software hereda el riesgo de todos los que lo producen. GlassWorm demuestra que los atacantes lo saben y están invirtiendo en infraestructura resistente para mantener un acceso persistente a los ecosistemas de desarrolladores».

Microsoft parchea el defecto CVE-2026-45659 de SharePoint RCE en todas las versiones del servidor – CYBERDEFENSA.MX

Microsoft ha implementado actualizaciones para corregir una vulnerabilidad de ejecución remota de código que afecta a SharePoint y que podría ser explotada por delincuentes en ataques sin que sea necesario cumplir ninguna condición especializada.

La vulnerabilidad, rastreada como CVE-2026-45659tiene una puntuación CVSS de 8,8. Se le ha asignado una gravedad importante.

«La deserialización de datos que no son de confianza en Microsoft Office SharePoint permite a un atacante autorizado ejecutar código a través de una red», dijo Microsoft en un aviso publicado la semana pasada.

Microsoft señaló que la vulnerabilidad podría ser activada por cualquier atacante autenticado y que no requiere administrador ni otros privilegios elevados.

«En un ataque basado en red, un atacante autenticado, que tiene un mínimo de permisos de miembro del sitio (PR:L), podría ejecutar código de forma remota en SharePoint Server», añadió el fabricante de Windows.

Ciberseguridad

Microsoft le dio crédito a un investigador llamado MEOW por descubrir e informar la falla. Se han publicado actualizaciones para las siguientes versiones:

El mes pasado, Microsoft publicó correcciones para una vulnerabilidad de suplantación de identidad que afectaba a Microsoft SharePoint Server (CVE-2026-32201, puntuación CVSS: 6,5) y que, según dijo, había sido explotada en estado salvaje.

Aunque el gigante tecnológico señala que es menos probable que CVE-2026-45659 sea explotado, es esencial que los usuarios apliquen las correcciones necesarias para una protección óptima, particularmente si se considera el hecho de que los atacantes han utilizado repetidamente varias fallas en la plataforma colaborativa a lo largo de los años.

El jefe de CISA se preocupa por las vulnerabilidades del código abierto y las mejoras de seguridad retrasadas

Asegurar parte de la tecnología de código abierto que sirve como columna vertebral de toda la infraestructura digital moderna requerirá algunas “decisiones difíciles” en medio de una ola de ataques de malware, dijo el jueves el líder de la Agencia de Seguridad de Infraestructura y Ciberseguridad.

«La comunidad de código abierto es una que me preocupa especialmente cuando empezamos a pensar en una rápida escalada del descubrimiento de vulnerabilidades», dijo el director interino Nick Andersen, haciendo referencia una caricatura sobre cómo las tecnologías clave que sustentan Internet a menudo son mantenidas por una sola persona.

En un ataque reciente, un pirata informático secuestró la cuenta de un único responsable de un proyecto de código abierto para publicar actualizaciones maliciosas para axios, popular entre los desarrolladores de software, lo que aumentó el potencial de ataques que podrían extenderse más ampliamente. TeamPCP, un presunto grupo de piratería norcoreano, ha estado en una ola de ataques de código abierto.

«Aquí hay una tremenda oportunidad para rediseñar áreas… para hacer inversiones en áreas donde sabemos que nos han faltado, y simplemente forzar que se tomen algunas decisiones de seguridad difíciles… donde la gente pensaba que su perfil de riesgo era diferente de lo que es», dijo Andersen. «Vemos la escalada en términos de velocidad, escala y velocidad del descubrimiento de vulnerabilidades hasta el uso de armas y la explotación».

CISA ha estado trabajando con la industria y otros «para modificar nuestro enfoque de gestión de vulnerabilidades, modificar nuestro enfoque de divulgación coordinada de vulnerabilidades, modificar nuestro enfoque de remediación, con el entendimiento explícito de que simplemente no podremos seguir utilizando los mecanismos tradicionales», dijo Andersen, hablando en el Foro Nacional de Innovación Cibernética en Washington, DC.

El gobierno y el sector privado pueden trabajar juntos para identificar las mayores amenazas y luego brindarles el nivel adecuado de atención, dijo. Por parte del gobierno federal, eso significa trabajar para tener una imagen completa del grado de dependencia de las tecnologías de código abierto.

En general, Estados Unidos ha pospuesto demasiadas mejoras de seguridad necesarias, afirmó Andersen.

“Ya sea que se mire al sector privado o a nuestros gobiernos y las redes y sistemas del sector público que apoyamos, existe una enorme cantidad de deuda técnica”, dijo. No hemos realizado la inversión necesaria para poder asegurarnos fácilmente en el futuro”.

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.

Cuando la identidad es el camino del ataque – CYBERDEFENSA.MX

Considere una clave de acceso almacenada en caché en una sola máquina con Windows. Llegó allí de la misma manera que lo hacen la mayoría de las credenciales almacenadas en caché: un usuario inició sesión y la clave se almacenó automáticamente. Comportamiento estándar de AWS. Nadie configuró mal nada ni violó una política. Sin embargo, esa única clave, a la que podía acceder fácilmente un atacante de ligas menores, podría haber abierto un camino a alrededor del 98% de las entidades en el entorno de nube de la empresa: casi todas las cargas de trabajo críticas de las que dependía el negocio.

Esta exposición del mundo real se detectó antes de que un atacante pudiera utilizarla. Pero la conclusión es clara: La identidad misma, y ​​cada permiso que conlleva, se ha convertido en la ruta de ataque.

Su entorno se basa en la identidad. Active Directory, proveedores de identidades en la nube, cuentas de servicio, identidades de máquinas y agentes de IA: todos ellos cuentan con permisos que abarcan sistemas y límites de confianza. Una única credencial robada le otorga al atacante una identidad legítima, junto con todos los permisos asociados.

A pesar de esto, la mayoría de los programas de seguridad todavía tratan la identidad como un control perimetral, algo que se debe proteger mediante políticas de autenticación y acceso. Sin embargo, el verdadero riesgo comienza dentro de la puerta principal. Una vez que un atacante tiene un punto de apoyo, la identidad es lo que le permite avanzar, cruzar fronteras y llegar a activos críticos. Porque la identidad no es un perímetro – es una autopista que atraviesa cada capa de su entorno.

En este artículo, veremos cómo las credenciales almacenadas en caché, los permisos excesivos y las asignaciones de roles olvidadas pueden convertirse en rutas de ataque en entornos híbridos, y por qué siguen faltando las herramientas diseñadas para detectarlos.

El camino del ataque pasa por la identidad

La clave de acceso almacenada en caché de ese escenario inicial es sólo un ejemplo de un fenómeno mucho mayor. En entornos híbridos, la identidad

Una membresía de grupo de Active Directory que nadie revisó le brinda a un atacante en un punto final minorista una ruta directa al dominio corporativo. Un rol de SSO de desarrollador aprovisionado para una migración a la nube mantiene sus permisos mucho después de que finaliza el proyecto, lo que brinda a cualquiera que comprometa esa identidad una ruta de cuatro pasos desde el acceso de desarrollador hasta el administrador de producción. Lo que hace que estos ejemplos del mundo real sean tan peligrosos es cómo se conectan. Esa credencial almacenada en caché en el punto final minorista generó una función con privilegios excesivos en Active Directory, lo que generó una carga de trabajo en la nube con una política de administración adjunta. Juntos, los eslabones de este tipo de cadena de exposición de la identidad forman una única ruta de ataque, desde un punto de apoyo inicial hasta un activo crítico.

¿Qué tan frecuente es esto? Palo Alto descubrió que las debilidades de identidad desempeñaban un papel importante en casi el 90% de sus investigaciones de respuesta a incidentes de 2025. Y dada la prevalencia de agentes de IA que asumen cargas de trabajo empresariales, es probable que esas cifras aumenten. SpyCloud Informe de exposición de identidad de 2026 señaló el robo de identidad no humana como una de las categorías de más rápido crecimiento en el mundo criminal clandestino, con un tercio de las credenciales no humanas recuperadas vinculadas a herramientas de inteligencia artificial.

¿Qué sucede cuando una de esas identidades no humanas tiene permisos de nivel de administrador? Considere un equipo de desarrollo que configura un servidor MCP con permisos de alto nivel para que sus herramientas de inteligencia artificial puedan operar en todos los sistemas. El agente de IA que utiliza el servidor MCP hereda esos privilegios como su propia identidad. Una vulnerabilidad en las herramientas de código abierto puede entregar fácilmente a un atacante los permisos que posee el agente. A partir de ahí, el camino va directamente a los recursos de la nube, las bases de datos y la infraestructura de producción. Las credenciales que hacen esto posible son exactamente las que se encuentran circulando por millones en los mercados criminales.

Por qué siguen faltando las herramientas

Claramente, la amenaza de la exposición de la identidad no es nueva. Sin embargo, las herramientas de identidad en las que todavía confían la mayoría de las organizaciones se crearon para resolver problemas específicos de forma aislada y en una era de amenazas diferente.

Las plataformas IGA gestionan el ciclo de vida del usuario: aprovisionamiento, desaprovisionamiento, revisiones de acceso y más. Las soluciones PAM almacenan credenciales privilegiadas y monitorean sesiones. Cada una de estas herramientas hace su trabajo de forma aislada. Pero ninguno de ellos puede mapear cómo las exposiciones de identidad se encadenan entre puntos finales, Active Directory y entornos de nube en una única ruta explotable.

Esta es la razón por la que las tasas de incidentes basados ​​en la identidad siguen aumentando incluso cuando crece el gasto en seguridad. La IBM Índice de inteligencia de amenazas X-Force 2026 descubrió que las credenciales robadas o mal utilizadas representaban el 32% de los incidentes, el segundo vector de acceso inicial más común. Los atacantes actuales realmente no necesitan escribir malware o exploits, simplemente pueden iniciar sesión.

La gran mayoría de estas exposiciones basadas en la identidad se pueden prevenir por completo. De hecho, Palo Alto descubrió que más de El 90% de las infracciones. sus equipos investigados en 2025 se vieron favorecidos por exposiciones que las herramientas existentes deberían haber detectado. Las organizaciones tenían las herramientas y el personal. Sin embargo, las brechas persistieron porque ninguna herramienta tenía visibilidad de cómo las exposiciones de identidad se encadenaban en todos los entornos en rutas de ataque.

Cerrando la brecha

Hasta que los programas de seguridad puedan conectar la identidad, los permisos y los controles de acceso en una visión unificada de cómo se mueve realmente un atacante, la identidad seguirá siendo una de las formas más fáciles de comprometer activos críticos.

Todos los escenarios de este artículo siguen la misma estructura: una credencial, un permiso o una asignación de roles que ninguna herramienta señala como peligrosa crea un camino transitable desde un punto de apoyo de bajo nivel hasta un activo crítico. El camino sólo se vuelve visible cuando la identidad, las políticas de acceso y el contexto del entorno se mapean juntos.

Los programas de seguridad que asignan esas conexiones a través de entornos híbridos pueden cerrar rutas de ataque basadas en identidad antes de que un atacante los encadene. Los programas que siguen tratando la identidad como un problema perimetral seguirán perdiendo terreno frente a los atacantes que ya saben que se trata de una autopista.

Nota: Este artículo fue cuidadosamente escrito y contribuido para nuestra audiencia por Alex GardnerDirector de marketing de productos en XM Cyber

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

Una falla del kernel de Linux de hace 9 años permite la ejecución de comandos raíz en las principales distribuciones – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una vulnerabilidad en el kernel de Linux que no fue detectada durante nueve años.

La vulnerabilidad, identificada como CVE-2026-46333 (puntuación CVSS: 5,5), es un caso de gestión inadecuada de privilegios que podría permitir a un usuario local sin privilegios revelar archivos confidenciales y ejecutar comandos arbitrarios como root en instalaciones predeterminadas de varias distribuciones importantes como Debian, Fedora y Ubuntu. También tiene el nombre en código ssh-keysign-pwn.

Según Qualys, que descubrió la falla, el problema tiene su origen en la función __ptrace_may_access() del kernel y se introdujo en noviembre de 2016.

«La primitiva es confiable y convierte cualquier shell local en un camino hacia la raíz o hacia material de credenciales sensible», dijo Saeed Abbasi, gerente senior de la Unidad de Investigación de Amenazas de Qualys. dicho.

Ciberseguridad

La explotación exitosa de la falla podría permitir a un atacante local revelar /etc/shadow y alojar claves privadas en /etc/ssh/*_key, así como ejecutar comandos arbitrarios como root a través de cuatro exploits diferentes dirigidos a chage, ssh-keysign, pkexec y account-daemon.

La divulgación se produce como un exploit de prueba de concepto (PoC) para la vulnerabilidad. liberado la semana pasada, poco después de que surgiera una confirmación pública del kernel. CVE-2026-46333 es la última vulnerabilidad de seguridad revelada en el kernel de Linux después de Copy Fail. Fragmento sucioy Fragnesia durante el último mes.

Se recomienda aplicar la última actualización del kernel publicada por las distribuciones de Linux. Si las actualizaciones no se pueden realizar inmediatamente, las soluciones temporales incluyen elevar «kernel.yama.ptrace_scope» a 2.

«En los hosts que han permitido usuarios locales que no son de confianza durante el período de exposición, trate las claves de host SSH y las credenciales almacenadas en caché local como potencialmente reveladas», dijo Qualys. «Rote las claves del host y revise cualquier material administrativo que viva en la memoria de los procesos set-uid».

El desarrollo sigue al lanzamiento de una PoC para una falla de escalada de privilegios local llamada Robo de pines que permite a los atacantes locales obtener privilegios de root en los sistemas Arch Linux. El exploit requiere que el módulo Reliable Datagram Sockets (RDS) esté cargado en el sistema de destino, que io_ring esté habilitado, un binario SUID-root legible y soporte x86_64 para la carga útil incluida.

Ciberseguridad

«PinTheft es un exploit de escalada de privilegios locales de Linux para una copia cero de RDS de doble liberación que se puede convertir en una sobrescritura de caché de página a través de buffers fijos io_uring», Zellic y el equipo de seguridad de V12 dicho.

«El error se encontraba en la ruta de envío de copia cero de RDS. rds_message_zcopy_from_user() fija las páginas de usuario una a la vez. Si una página posterior falla, la ruta de error descarta las páginas que ya fijó, y la limpieza posterior de mensajes RDS las descarta nuevamente porque las entradas de la lista de dispersión y el recuento de entradas permanecen activas después de que se borra el notificador de zcopy. Cada envío fallido de copia cero puede robar una referencia de la primera página».

Conozca a Rampart y Clarity, los nuevos agentes combinados de IA del equipo rojo de Microsoft

El miércoles, Microsoft lanzó dos nuevas herramientas de equipos rojos:Muralla y Claridad—, destinado a ayudar a los desarrolladores a diseñar software agente más seguro y ayudar a los equipos de respuesta a incidentes frente a infracciones continuas.

Se construye la muralla además de PyRIT, un existente marco de automatización abierto Microsoft desarrolló sistemas de IA generativa para equipos rojos. Pero mientras PyRIT escanea los sistemas ya construidos en busca de fallas de seguridad, Rampart está diseñado para probar continuamente el código en busca de vulnerabilidades durante el proceso de desarrollo, codificando escenarios de prueba tanto adversos como benignos en el proceso de desarrollo de software para señalar errores y dependencias explotables.

Microsoft dijo que Rampart fue creado para centrarse en ataques de inyección cruzada, donde «un agente recupera o procesa contenido potencialmente envenenado de documentos, correos electrónicos, tickets y otras fuentes de datos que manipulan el comportamiento indirectamente». También confirma que las correcciones o exploits funcionan según lo previsto a través de múltiples rondas de pruebas, a diferencia de las herramientas que realizan una «validación de un solo disparo».

La segunda herramienta, Claridadpuede ejecutarse como una aplicación de escritorio, una interfaz web o integrarse directamente en un agente de codificación para proporcionar orientación de ingeniería de seguridad en tiempo real a los desarrolladores desde el inicio de un proyecto. Puede categorizar y rastrear diferentes objetivos comerciales relacionados con el código y resaltar las implicaciones de seguridad posteriores junto con alternativas de diseño más seguras.

Ram Shankar Siva Kumar, quien fundó el equipo rojo de IA de Microsoft en 2019, dijo a CyberScoop que la compañía ha visto beneficios de seguridad interna al usar las herramientas, pero cree que el crecimiento de Rampart y Clarity depende de las contribuciones de otros desarrolladores fuera del ecosistema de Microsoft.

En el vertiginoso mundo de la IA, donde la codificación ambiental, los agentes de IA no autorizados y una constante rotación de lanzamientos de nuevos modelos crean nuevas implicaciones de seguridad casi todas las semanas, Siva Kumar dijo que era importante comenzar a construir procesos de seguridad fundamentales centrados en la IA en el proceso de desarrollo de software.

«Cuando escuchas hablar mucho sobre la seguridad de la IA, parece que hay muchos debates filosóficos», dijo. «Verán marcos, verán documentos técnicos, y creo que ya hemos superado ese momento. Realmente necesitamos empezar a pensar en la seguridad de la IA como una disciplina de ingeniería y tratar de llevar la seguridad donde están los desarrolladores».

La utilidad potencial de Rampart para los defensores va más allá de simplemente asegurar los procesos de desarrollo de software. También se puede utilizar durante una respuesta activa a un incidente para acelerar o automatizar el equipo rojo para realizar correcciones urgentes, parches y remediación.

Microsoft ha utilizado Rampart al investigar vulnerabilidades reportadas en sus propios productos. Siva Kumar dijo que la herramienta fue capaz de ayudar a condensar en horas el trabajo manual de una semana (replicar la vulnerabilidad, identificar diferentes variantes del mismo error, luego parchear y volver a probar esas variantes para garantizar que ya no sean explotables) en horas. Mientras tanto, Clarity actúa como un asesor de seguridad para proyectos de software, incitando a los desarrolladores a considerar los riesgos potenciales en sus decisiones de diseño y sus consecuencias de seguridad posteriores. . Con el aumento del código y los agentes generados por IA y el abaratamiento de la ejecución, este tipo de orientación proactiva es cada vez más importante.

«Podrás crear aplicaciones, crear servidores MCP para extraer cosas de Internet», dijo Siva Kumar. «La pregunta es ¿debería hacerlo? y Clarity es un paso en esa dirección. Es preguntar 'oye, ¿deberías hacer esto en primer lugar?'»

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

Los errores tipográficos ya no son un problema del usuario. Es un problema de la cadena de suministro – CYBERDEFENSA.MX

Los dominios similares generados por IA ahora están integrados dentro de scripts de terceros que se ejecutan en sus propiedades web. He aquí por qué su pila actual no puede verlos y qué requiere realmente la detección.

Descargue la Guía de expertos de CISO sobre Typosquatting en la era de la IA →

TL;DR

  • Typosquatting ya no es un problema de usuario. Los atacantes ahora incorporan dominios similares dentro de scripts legítimos de terceros. No se requiere una URL mal escrita ni una vulneración del servidor.
  • La IA rompió la economía de la defensa. Los LLM generan miles de variantes de dominio convincentes en minutos; el despliegue completo de la campaña lleva menos de diez años. Las cargas de paquetes maliciosos aumentaron 156% el año pasado. La investigación manual está muerta.
  • Tu pila de seguridad no puede ver esto. Los firewalls, WAF, EDR y CSP no tienen visibilidad de lo que hacen los scripts aprobados una vez que se ejecutan en el navegador.
  • El Ataque a Trust Wallet lo demostró. 8,5 millones de dólares robados en 48 horas a través de una extensión de Chrome troyanizada. No se disparó ninguna alerta, no porque algo fallara, sino porque no había nada mirando.

Esta no es una historia criptográfica

El 24 de diciembre de 2025, los usuarios de Trust Wallet comenzaron a perder dinero. No porque hayan hecho clic en un enlace de phishing. No porque reutilizaron una contraseña débil. No porque hayan hecho nada malo en absoluto.

Un gusano npm autorreplicante llamado Shai-Hulud había pasado meses recopilando credenciales de desarrollador: tokens de GitHub, claves de publicación de npm y credenciales de la API de Chrome Web Store. Esas claves permitieron a los atacantes enviar una versión troyanizada de la extensión Trust Wallet Chrome a través de canales oficiales. La verificación de Chrome pasó.

La extensión maliciosa se ejecutó completamente dentro de los navegadores de los usuarios, capturando silenciosamente frases iniciales y transmitiéndolas a la infraestructura del atacante en un dominio disfrazado de punto final de análisis del propio Trust Wallet. En 48 horas, se habían vaciado 2.500 carteras. Pérdida total: 8,5 millones de dólares. Ningún servidor fue vulnerado. Nunca se disparó ninguna alerta.

Elimine las frases iniciales y lo que queda es esto: un activo confiable entregado por el navegador se modificó silenciosamente para interceptar datos confidenciales del usuario antes de que la aplicación legítima pudiera procesarlos, invisible para los registros del servidor, firewalls, WAF y EDR. No porque esos controles estuvieran mal configurados, sino porque nunca fueron diseñados para observar lo que sucede dentro de una sesión del navegador, ni siquiera una sesión envenenada.

Cambie frases iniciales por datos de tarjetas de pago. Cambie la extensión de Chrome por un píxel de marketing, un widget de soporte o un marco de pruebas A/B. El ataque es idéntico. Una página de pago típica de comercio electrónico ejecuta entre 40 y 60 scripts de terceros. Cada uno es una conexión confiable. Allí podría pasar lo mismo.

Cómo llegó aquí la typosquatting: tres fases

Lo que hace que la Fase 3 sea una evolución genuina no es sólo la sofisticación, sino también la economía. Los LLM pueden generar miles de variaciones de dominio convincentes en minutos. Los ataques homógrafos combinan caracteres latinos, cirílicos y griegos para producir dominios que parecen visualmente idénticos en las barras de direcciones del navegador mientras evaden la detección de distancia de cadena. El registro de dominio, la emisión de SSL y la implementación completa de la campaña ahora demoran menos de diez minutos. Los datos de Sonatype muestran que las cargas de paquetes maliciosos a repositorios de código abierto aumentaron un 156% año tras año, por lo que el volumen por sí solo ha hecho que la investigación manual sea estructuralmente imposible.

Tres ataques que muestran el patrón

La typosquatting apunta a la capa de dominio, el compromiso de paquetes apunta a la cadena de suministro y el abuso del tiempo de ejecución del navegador apunta a lo que hace el código confiable después de ejecutarse.

1. Extensión Trust Wallet para Chrome (diciembre de 2025)

Shai-Hulud recopiló credenciales de desarrollador durante meses antes de lanzar una extensión troyanizada a través de los canales oficiales de Chrome Web Store. La extensión maliciosa capturó frases iniciales y las transmitió a un dominio de análisis similar. 2.500 carteras vaciadas. Se perdieron 8,5 millones de dólares. Tiempo de detección: cero. No existe visibilidad del lado del servidor para la ejecución en tiempo de ejecución del navegador.

2. ataque npm con tiza/depuración (septiembre de 2025)

Un correo electrónico de phishing dirigido a un único responsable del paquete dio a los atacantes acceso a 18 bibliotecas de JavaScript confiablesincluidos chalk y debug, con más de dos mil millones de descargas semanales combinadas. En 16 minutos, se inyectó código malicioso en todos ellos, conectando las API del navegador para interceptar silenciosamente el tráfico de red y las interacciones de billetera. La rápida contención limitó las pérdidas directas a alrededor de 500 dólares. La ventana de exposición no fue la historia. Fueron dos mil millones de descargas.

3. Ataque a la biblioteca Solana Web3.js (diciembre de 2024)

Los atacantes comprometieron una cuenta de acceso de publicación para la biblioteca npm @solana/web3.js a través de una campaña de phishing, luego publicaron versiones maliciosas que contenían una función oculta que interceptaba claves privadas a mitad de la transacción y las exfiltraba a un dominio controlado por el atacante registrado apenas unos días antes del ataque. Cualquier aplicación que se actualizara automáticamente dentro del período de cinco horas enviaba la puerta trasera directamente a sus usuarios. Casi 200.000 dólares se gastaron antes del descubrimiento.

Cómo ocurre el compromiso: la confianza reemplaza al engaño

La ingeniería social clásica necesitaba un ser humano al tanto, alguien que escribiera mal una URL, hiciera clic en un enlace, aprobara un mensaje y confiara en un remitente. El trabajo del atacante era generar confianza en el momento.

La generación actual de ataques se salta ese paso por completo. La confianza ya no se fabrica, se hereda. Su canal de compilación ya confía en npm. Su proveedor ya confía en su CDN. Su navegador ya confía en el proveedor. El atacante no necesita engañar a nadie; sólo necesitan insertarse en cualquier lugar de una cadena de confianza que ya les ha sido otorgada.

Llámelo subversión de la cadena de suministro: el engaño no está dirigido a una persona; está dirigido al gráfico de dependencia.

El punto ciego en su pila de seguridad

Un proveedor de marketing integrado en sus propiedades web hace referencia a una CDN de JavaScript registrada hace seis semanas. SSL válido. Dominio reconocible. Luego, el guión se actualiza silenciosamente.

En su página de pago, el navegador carga silenciosamente el script modificado. Una superposición invisible intercepta las pulsaciones de teclas antes de que lleguen a su aplicación. Los registros de su servidor registran una sesión normal. No hay incendios de alerta.

CSP es el control más citado como defensa. Pero CSP es una lista de invitados, no un monitor de comportamiento. Un script incluido en la lista de permitidos que lee los campos de su formulario de pago y filtra los datos todavía está totalmente permitido, porque el origen es confiable. CSP maneja la conexión. No puede manejar la ejecución.

El comportamiento malicioso en 2026 se difiere al tiempo de ejecución por diseño. Los paquetes de Shai-Hulud permanecieron inactivos durante el escaneo automatizado y solo se activaron bajo condiciones de tiempo de ejecución específicas. El análisis estático no puede detectar cargas útiles cargadas dinámicamente después de que comienza la ejecución.

Lo que realmente requiere la detección

El informe sobre el costo de una vulneración de datos de 2025 de IBM encontró que la vulneración promedio tarda 241 días para identificar. En los ataques a la cadena de suministro en los que el comportamiento malicioso se ejecuta silenciosamente en la memoria del navegador, esa ventana puede ser significativamente más larga, a menos que esté observando el tiempo de ejecución.

La detección requiere observar qué hacen realmente los scripts después de ejecutarse: con qué dominios se comunican, a qué elementos de la página acceden y cómo su comportamiento se desvía de las líneas base establecidas. Se trata de monitoreo del comportamiento en tiempo de ejecución, la única capa de la que carecen actualmente la mayoría de las pilas de seguridad empresarial.

Las características a monitorear para:

  • Exfiltración de datos inesperada: Scripts que leen campos de formulario y transmiten valores a dominios fuera de su lista aprobada
  • Resolución de dominio dinámico: Scripts que llaman a dominios registrados recientemente o que se resuelven de manera diferente a su línea base
  • Deriva conductual: Un script que se comportó normalmente la semana pasada ahora accede a diferentes elementos de la página esta semana.

Detectar un dominio sospechoso en su árbol de dependencia es necesario, pero no suficiente. El problema más difícil es comprender qué hace realmente el script cargado desde ese dominio. La ofuscación generada por IA ahora está diseñada específicamente para derrotar el análisis estático: el código pasa el linting, imita bibliotecas minificadas legítimas y no produce coincidencias de firmas.

Cerrar esa brecha requiere desofuscar el comportamiento en tiempo de ejecución, ejecutar el script en un entorno instrumentado y rastrear su comportamiento real, sin intentar leer su fuente. Eso significa sacar a la luz a qué accede realmente un script: campos de formulario, cookies, puntos finales de la red, independientemente de cuán confusa esté la fuente. Es el enfoque que Reflectiz construyó Desofuscador de IA alrededor, y se detalla en la guía a continuación.

Tu plan de acción

Si no está seguro de por dónde empezar, priorice por exposición: las páginas de pago primero, las páginas de autenticación en segundo lugar y todo lo demás después. He aquí una secuencia práctica:

Esta semana:

  • Audite scripts de terceros para dominios CDN registrados recientemente en su cadena de dependencia
  • Revise los informes de CSP, no solo las infracciones, sino también lo que realmente están haciendo sus orígenes aprobados.
  • Identifique qué páginas manejan datos confidenciales (pago, inicio de sesión, formularios PII) y priorice el monitoreo allí primero.

Este mes:

  • Implementar monitoreo del comportamiento en tiempo de ejecución para páginas de pago y autenticación
  • Establecer líneas de base de comportamiento para todos los scripts de terceros aprobados.
  • Implementar comprobaciones de integridad de subrecursos (SRI) cuando los scripts se autohospedan o se pueden almacenar en caché

Son necesarios un registro de dominio proactivo, un CSP estricto y DMARC aplicado. Cubren el registro de dominio, la entrega de scripts y la suplantación de correo electrónico. Ninguno de ellos cubre lo que sucede después de que un script de proveedor aprobado se modifica silenciosamente. Esa es la brecha que la mayoría de los equipos no ven hasta que es demasiado tarde.

Los controles anteriores le indican qué hacer. Asignarlos a su entorno real, inventario de proveedores y obligaciones de cumplimiento es donde la ejecución se detiene. Reflectiz ha publicado un Guía de expertos CISO con el marco completo: gobernanza de dominio, controles fundamentales, monitoreo del comportamiento en tiempo de ejecución y una hoja de ruta de implementación por fases construida en torno a esa brecha.

Descarga la guía aquí →

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

La infracción de Grafana GitHub expone el código fuente a través del ataque TanStack npm – CYBERDEFENSA.MX

Grafana Labs, el 19 de mayo de 2026, dijo que una investigación sobre su reciente violación no encontró evidencia de que los sistemas de producción u operaciones del cliente estuvieran comprometidos.

Dijo que el alcance del incidente se limita al entorno GitHub de Grafana Labs, que incluye código fuente público y privado junto con repositorios internos de GitHub.

«Después de la evaluación inicial, descubrimos que, además del código fuente, el contenido descargado incluía repositorios de GitHub que algunos equipos de Grafana Labs utilizan para colaborar y almacenar información operativa interna y otros detalles sobre nuestro negocio», dicho.

«Esto incluye nombres de contactos comerciales y direcciones de correo electrónico que se intercambiarían en un contexto de relación profesional, no información extraída o procesada mediante el uso de sistemas de producción o la plataforma Grafana Cloud».

Ciberseguridad

El fabricante de software de visualización de código abierto también señaló que la violación se originó en el ataque a la cadena de suministro de npm de TanStack orquestado por TeamPCP, que también afectó a OpenAI y Mistral AI, y que detectó la actividad el 11 de mayo de 2026.

«Realizamos análisis y rotamos rápidamente una cantidad significativa de tokens de flujo de trabajo de GitHub, pero un token perdido llevó a los atacantes a obtener acceso a nuestros repositorios de GitHub», dijo. «Una revisión posterior confirmó que un flujo de trabajo específico de GitHub que originalmente consideramos que no estaba afectado, de hecho, se había visto comprometido».

La compañía dijo que posteriormente recibió una demanda de extorsión por parte de un actor de amenazas anónimo el 16 de mayo, pero optó por no pagar el rescate porque no hay garantía de que los datos robados realmente se eliminen y podrían actuar como catalizador para futuras campañas.

Desde entonces, Grafana ha tomado medidas para rotar tokens de automatización, implementar un monitoreo mejorado, auditar todas las confirmaciones en busca de signos de actividad maliciosa y reforzar su postura general de seguridad en GitHub.

Vale la pena mencionar aquí que un equipo de extorsión de datos llamado CoinbaseCartel incluyó a Grafana Labs en su sitio web oscuro el 15 de mayo de 2026. The Hacker News se comunicó con Grafana para solicitar comentarios y actualizaremos la historia si recibimos una respuesta.

El desarrollo se produce cuando GitHub dijo que está investigando el acceso no autorizado a sus repositorios internos después de que el notorio actor de amenazas conocido como TeamPCP pusiera a la venta el código fuente de la plataforma y las organizaciones internas en un foro de cibercrimen.

PoC de DirtyDecrypt lanzado para la vulnerabilidad LPE CVE-2026-31635 del kernel de Linux – CYBERDEFENSA.MX

Se ha publicado un código de explotación de prueba de concepto (PoC) para una falla de seguridad recientemente reparada en el kernel de Linux que podría permitir la escalada de privilegios locales (LPE).

Apodado suciodescifrar (también conocido como DirtyCBC), la vulnerabilidad fue descubierta e informada por el equipo de seguridad de Zellic y V12 el 9 de mayo de 2026, solo para que los mantenedores les informaran que era un duplicado de una vulnerabilidad que ya había sido parcheada en la línea principal.

«Es una escritura de caché de página rxgk debido a que falta VACA [copy-on-write] guardia en rxgk_decrypt_skb», cofundador de Zellic, Luna Tong (también conocido como cts y gf_256) dicho en una descripción compartida en GitHub.

Aunque el identificador CVE no fue revelado, la vulnerabilidad en cuestión es CVE-2026-31635 (Puntuación CVSS: 7,5) basado en el hecho de que la Base de datos nacional de vulnerabilidades (NVD) del NIST incluye un enlace al PoC de DirtyDecrypt en su registro CVE.

«La falla específica se encuentra en rxgk_decrypt_skb(), la función que descifra un sk_buff (búfer de socket) entrante en el lado de recepción», Moselwal dicho.

«En esta ruta de código, el kernel maneja páginas de memoria que se comparten parcialmente con el caché de páginas de otros procesos – una optimización normal de Linux protegida por copia en escritura: tan pronto como ocurre una escritura en una página compartida, se hace una copia privada de antemano para que la escritura no se filtre en los datos de otro proceso».

Ciberseguridad

La ausencia de esta protección COW en rxgk_decrypt_skb significa que los datos se escriben en la memoria de procesos privilegiados o, dependiendo de la ruta del exploit, en la página caché de archivos privilegiados, como etc/shadow, /etc/sudoers o un binario SUID, lo que lleva a una escalada de privilegios local.

DirtyDecrypt afecta solo a las distribuciones con CONFIG_RXGK habilitados, como Fedora, Arch Linux y openSUSE Tumbleweed. En entornos en contenedores, los nodos trabajadores que ejecutan una versión vulnerable de Linux podrían proporcionar una vía para escapar del pod.

Se considera que la vulnerabilidad, según Zellic, es una variante de Copy Fail (CVE-2026-31431), Dirty Frag también conocido como Copy Fail 2 (CVE-2026-43284 y CVE-2026-43500) y Fragnesia (CVE-2026-46300), todos los cuales otorgan acceso de root en sistemas vulnerables.

Copia fallidauna falla de escalada de privilegios local en la interfaz de socket criptográfico AF_ALG, fue revelada por investigadores de Theori el 29 de abril de 2026. Fue seguida por Fragmento sucio una semana después. Dirty Frag amplía Copy Fail con dos primitivas de escritura de caché de página.

Sin embargo, el investigador de seguridad Hyunwoo Kim se vio obligado a seguir adelante con la divulgación pública después de que la ventana de embargo acordada terminara prematuramente cuando un parche fusionado para CVE-2026-43284 el 5 de mayo llevó a otro investigador, que desconocía el embargo, a analizar y publicar detalles de forma independiente del defecto.

«Leí la confirmación, reconocí la ruta xfrm ESP-in-UDP MSG_SPLICE_PAGES sin COW contra páginas de canalización compartidas como una primitiva LPE y construí una PoC», el investigador, que utiliza los alias en línea 0xdeadbeefnetwork y afflicted.sh, anotado. «El trabajo es un armamento de n días a partir de un compromiso público ascendente, que es una práctica estándar una vez que una solución relevante para la seguridad llega a un árbol público».

Fragnesia es otra variante de Dirty Frag e impacta el subsistema XFRM ESP-in-TCP. Pero el resultado es el mismo: permite a atacantes locales sin privilegios modificar el contenido de archivos de sólo lectura en la caché de la página del núcleo y obtener privilegios de root.

El desarrollo coincide con el descubrimiento de una falla LPE en Linux PaqueteKit demonio (CVE-2026-41651 también conocido como Pack2TheRoot, puntuación CVSS: 8.8) y una falla de administración de privilegios inadecuada en el kernel (CVE-2026-46333 alias ssh-keysign-pwnpuntuación CVSS: 5,5), que permite a un usuario local sin privilegios leer secretos de propiedad raíz, como claves privadas SSH.

Varias distribuciones de Linux han publicado avisos para CVE-2026-46333 –

¿Killswitch del núcleo?

La avalancha de nuevas revelaciones en un lapso de unas pocas semanas ha llevado a los desarrolladores del kernel de Linux a revisar una propuesta para un «interruptor de emergencia» que permitiría a los administradores desactivar funciones vulnerables del kernel en tiempo de ejecución hasta que esté disponible un parche para una vulnerabilidad de día cero.

«Killswitch permite a un operador privilegiado hacer que una función del núcleo elegida devuelva un valor fijo sin ejecutar su cuerpo, como una mitigación temporal de un error de seguridad mientras se prepara una solución real», según un propuesta presentado por el desarrollador y mantenedor del kernel de Linux Sasha Levin.

«La función devuelve el valor proporcionado por el operador y no se ejecuta nada más en su lugar. No hay una lista de permitidos, ni una verificación de tipo de retorno; si la capa kprobe acepta el símbolo, killswitch lo activa. Una vez activado, el cambio tiene efecto en cada CPU hasta que se escribe «disengage« o el sistema se reinicia».

Ciberseguridad

Rocky Linux estrena repositorio de seguridad

Rocky Linux, por su parte, ha introducido una opción opcional. repositorio de seguridad eso permite que la distribución envíe correcciones de seguridad urgentes rápidamente, particularmente en escenarios donde las vulnerabilidades graves se vuelven de conocimiento público antes de que lleguen las correcciones coordinadas.

«El repositorio está deshabilitado de forma predeterminada. Eso es intencional», dijeron los mantenedores. dicho. «La experiencia predeterminada de Rocky Linux sigue siendo exactamente la que siempre ha sido: predecible, estable y totalmente compatible con las versiones anteriores. Los administradores que deseen acceder a correcciones aceleradas pueden optar por participar cuando lo necesiten».

El repositorio de seguridad atiende específicamente a casos «específicos y limitados» en los que una vulnerabilidad significativa es pública, existe un código de explotación y los parches ascendentes aún no están disponibles. Rocky Linux ha enfatizado que no reemplaza el proceso de lanzamiento regular.

«Si implementamos una solución y el desarrollador decide no solucionarlo, la próxima versión del kernel reemplazará nuestra versión parcheada», agregaron los mantenedores. «Los usuarios que no hayan bloqueado la versión de su kernel, en ese momento, ya no tendrán nuestra solución. Ésa es la compensación que aceptamos al construir esto».

Cómo reducir la exposición al phishing antes de que se convierta en una interrupción del negocio – CYBERDEFENSA.MX

¿Qué sucede cuando un correo electrónico de phishing parece lo suficientemente limpio como para pasar el control de seguridad, pero lo suficientemente peligroso como para exponer la empresa después de un clic? Ésa es la brecha con la que muchos SOC todavía luchan: los ataques que dejan a los equipos sin saber qué estuvo expuesto, quién más fue el objetivo y hasta qué punto se ha extendido el riesgo.

La detección temprana del phishing cierra esa brecha. Ayuda a los equipos a pasar de la incertidumbre a la evidencia más rápidamente, reducir los retrasos en la respuesta y evitar que un enlace perdido se convierta en exposición de la cuenta, acceso remoto o interrupción operativa.

Por qué el phishing crea ahora un mayor riesgo para los líderes de seguridad

El phishing se ha vuelto más difícil de gestionar porque ya no crea un evento claro y fácil de contener. Un solo clic puede convertirse en exposición de identidad, acceso remoto, acceso a datos o una investigación más amplia antes de que el equipo tenga una idea clara.

Lo que lo convierte en una preocupación mayor ahora:

  • Pone la identidad en el centro del ataque: Las credenciales robadas pueden exponer el correo electrónico, las aplicaciones SaaS, las plataformas en la nube y los sistemas internos.
  • Debilita la confianza en la AMF: Algunas campañas capturan códigos OTP, por lo que «MFA está habilitado» no siempre es suficiente.
  • Se esconde detrás del comportamiento normal del usuario: Las comprobaciones de CAPTCHA, las páginas de inicio de sesión, las invitaciones y las herramientas confiables pueden hacer que las señales tempranas parezcan rutinarias.
  • Ralentiza las decisiones a nivel empresarial: Es posible que los equipos necesiten tiempo para confirmar a qué se accedió, quién se vio afectado y si es necesaria la contención.
  • Aumenta la exposición operativa: Cuanto más tiempo permanezca sin aclararse la actividad de phishing, mayores serán las posibilidades de abuso de la cuenta, acceso remoto o interrupción del negocio.

La forma más rápida de convertir las señales de phishing en acción

Cuando llega un correo electrónico de phishing, la velocidad depende de lo que haga el SOC a continuación. Los equipos más fuertes no investigan un vínculo sospechoso de forma aislada. Lo utilizan como el inicio de un proceso conectado: validan el comportamiento, amplían la inteligencia y verifican el entorno para detectar exposiciones relacionadas antes de que se extienda el riesgo.

Paso 1: Confirme el riesgo real detrás de los enlaces y correos electrónicos de phishing

Lo primero que necesitan los equipos de SOC es un lugar seguro para comprobar qué hace realmente un correo electrónico o un enlace sospechoso más allá de la bandeja de entrada. Aquí es donde los entornos sandbox interactivos se vuelven críticos: permiten a los equipos abrir archivos adjuntos, seguir URL, observar redireccionamientos, pasar por flujos de phishing y exponer comportamientos que pueden no ser visibles únicamente en el mensaje original.

Compruebe el reciente ataque de phishing con invitación falsa

Ataque de phishing expuesto dentro del sandbox de ANY.RUN

Una investigación reciente de ANY.RUN muestra por qué esto es importante. Los investigadores encontraron una peligrosa campaña de phishing dirigida a organizaciones estadounidenses, especialmente en industrias de alta exposición como Educación, banca, gobierno, tecnología y atención médica. Al principio, el ataque parecía rutinario: una invitación falsa, una verificación CAPTCHA y una página con el tema de un evento. Pero detrás de ese flujo, la campaña podría conducir al robo de credenciales, captura de OTP o entrega de herramientas RMM legítimas.

Amplíe la capacidad de análisis de phishing de su equipo antes de que la próxima amenaza se convierta en un incidente grave.

Reclame asientos adicionales y precios especiales mientras la oferta esté disponible hasta el 31 de mayo.

Obtenga una oferta especial ahora

Dentro del sandbox interactivo de ANY.RUN, la cadena de ataque completa quedó expuesta en solo 40 segundos: redirecciones, páginas falsas, solicitudes de credenciales, descargas y señales de posible acceso remoto. Esa es la velocidad que necesitan los equipos de seguridad cuando cada minuto de incertidumbre puede aumentar la exposición.

Se necesitan 38 segundos para analizar la cadena completa de ataques de phishing complicados dentro del entorno limitado de ANY.RUN

Una vez que el sandbox expone la ruta completa del ataque, los líderes obtienen lo que a menudo les falta a las investigaciones de phishing: pruebas tempranas de la exposición empresarial. En lugar de esperar señales de abuso de cuenta o compromiso de endpoints, el SOC puede comprender el riesgo mientras todavía hay tiempo para contenerlo.

Con esa prueba, los equipos pueden:

  • confirmar si el enlace crea una exposición real
  • actuar antes de que las cuentas o los puntos finales comprometidos se conviertan en un problema mayor
  • Dar a los líderes la evidencia necesaria para aprobar una contención rápida.

Paso 2: Contextualizar un ataque en un panorama de amenazas completo

Una vez que el entorno de pruebas expone el comportamiento de phishing, el siguiente paso es comprender si la amenaza es aislada o forma parte de una campaña más amplia. Aquí es donde Las soluciones de inteligencia de amenazas de ANY.RUN Ayude a los equipos a pasar de un vínculo sospechoso a una visión más amplia de la amenaza.

En la campaña de invitación falsa, la zona de pruebas reveló patrones repetibles en las páginas de phishing, incluidas solicitudes de /favicon.ico, /bloqueado.htmly recursos almacenados en /Imagen/*.png. Estos detalles son valiosos porque ayudan a conectar dominios, páginas e infraestructura relacionados que pueden pertenecer a la misma campaña.

Sesiones de análisis relevantes mostradas con Threat Intelligence de ANY.RUN para un contexto más amplio y una visibilidad total del comportamiento.

Una vez que se amplía el contexto de la amenaza, los equipos ya no reaccionan a una alerta de forma aislada. Pueden comprender hasta dónde puede llegar la campaña, qué áreas del negocio están más expuestas y si la respuesta debe ser limitada o ampliarse entre usuarios, departamentos o clientes.

Esa visión más amplia ayuda a los CISO a:

  • priorizar la respuesta según la escala de la campaña, no un solo enlace de phishing
  • reducir los puntos ciegos entre usuarios, regiones y unidades de negocio
  • tomar decisiones más rápidas sobre bloqueo, búsqueda y escalada antes de que se acumule más exposición

Paso 3: Mantenga las defensas actualizadas para una concientización temprana sobre los riesgos

Una vez que la amenaza se valida y se enriquece, el siguiente paso es hacer que esa inteligencia se pueda utilizar en todas las herramientas de las que ya depende el SOC. El objetivo no es mantener los hallazgos dentro de una investigación, sino convertirlos en detección, bloqueo, enriquecimiento y respuesta en todo el entorno.

Con las soluciones de inteligencia de amenazas de ANY.RUN, los equipos pueden utilizar IOC basados ​​en el comportamiento y contexto de campaña en SIEM, TIP, SOAR, NDR, firewalls y otras herramientas de seguridad. Construido a partir de análisis de ataques reales en 15.000 organizaciones y 600.000 profesionales de la seguridadesta inteligencia brinda a los equipos un contexto nuevo que pueden aplicar directamente dentro de los flujos de trabajo existentes.

TI Feeds de ANY.RUN proporciona IOC nuevos basados ​​en el comportamiento en toda la pila de seguridad

Esto ayuda a los equipos a pasar de «analizamos un enlace de phishing» a «ahora podemos buscar exposición relacionada en toda la empresa». La inteligencia recopilada puede revelar dominios relacionados, rutas URL repetidas, solicitudes sospechosas, archivos descargados o signos de actividad RMM conectados a la misma campaña.

Para los CISO, aquí es donde la inteligencia de phishing se convierte en control operativo. Ayuda a los equipos:

  • utilizar las inversiones en seguridad existentes para detectar la actividad relacionada más rápidamente
  • reduzca los puntos ciegos en el correo electrónico, la red, los terminales, la identidad y los datos de la nube
  • actuar antes de que un caso de phishing se convierta en una exposición empresarial más amplia

Este proceso cierra el círculo: la zona de pruebas prueba el comportamiento, la inteligencia sobre amenazas amplía el contexto y la pila de seguridad ayuda a los equipos a encontrar y detener amenazas relacionadas antes de que se propaguen.

Obtenga ofertas especiales de ANY.RUN antes del 31 de mayo

para celebrar su 10mo aniversarioANY.RUN ofrece condiciones especiales para equipos que desean fortalecer el análisis de phishing, la inteligencia sobre amenazas y los flujos de trabajo de respuesta SOC.

Ofertas especiales de ANY.RUN para un SOC más sólido y una visibilidad más temprana de las amenazas

Hasta 31 de mayolos equipos pueden acceder a ofertas de aniversario en las soluciones clave de ANY.RUN:

  • Zona de pruebas interactiva: Asientos de bonificación y precios exclusivos para equipos que necesitan un análisis profundo de malware y phishing.
  • Soluciones de inteligencia de amenazas: Meses adicionales para aportar inteligencia más actualizada a la detección, la investigación y la respuesta.

Para los SOC, este es un buen momento para ampliar la visibilidad del phishing, incorporar nueva inteligencia sobre amenazas a los flujos de trabajo existentes y mejorar la preparación de la respuesta sin ralentizar las operaciones.

Obtenga una oferta especial ahora para fortalecer la detección de phishing y ayudar a su SOC a actuar antes de que se extienda la exposición.

Convierta la detección temprana de phishing en un impacto SOC medible

La detección temprana del phishing es importante porque el retraso es lo que aumenta el riesgo. Cuando llega un enlace sospechoso, cada minuto extra puede significar más incertidumbre, más trabajo manual y más tiempo antes de que el equipo sepa si las cuentas, los puntos finales o los sistemas empresariales están expuestos.

Los equipos informan una eficiencia SOC 3 veces mayor con las soluciones de ANY.RUN

ANY.RUN ayuda a cerrar la brecha entre la primera señal de phishing y una respuesta segura. Los equipos pueden analizar el enlace de forma segura, confirmar lo que hace, enriquecer los hallazgos con el contexto de amenaza relacionado e insertar esa inteligencia en su pila de seguridad para encontrar y detener la actividad conectada en todo el entorno.

Equipos que utilizan el informe ANY.RUN:

  • MTTR 21 minutos más rápido por caso para reducir la ventana entre la detección y la contención del phishing
  • Clasificación 94 % más rápida según lo informado por los usuarios para reducir la incertidumbre en torno a enlaces sospechosos
  • 30% menos escalamientos de Nivel 1 a Nivel 2 para proteger la capacidad del equipo senior
  • Hasta un 20% menos de carga de trabajo de Nivel 1 para reducir la fatiga de alerta y el esfuerzo de investigación manual
  • Eficiencia SOC hasta 3 veces mayor en flujos de trabajo de validación, enriquecimiento y respuesta

Cierre los puntos ciegos del phishing antes de que se conviertan en exposición empresarial. Obtenga asientos adicionales y precios especiales para ampliar la visibilidad de SOC mientras la oferta esté disponible.

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