Qué buscar en una plataforma de gestión de exposición (y en qué se equivoca la mayoría) – CYBERDEFENSA.MX

Cada equipo de seguridad tiene una versión de la misma historia. El trimestre finaliza con cientos de vulnerabilidades cerradas. Los salpicaderos están llenos de verde. Entonces alguien en una reunión de liderazgo pregunta: «Entonces, ¿estamos realmente más seguros ahora?»

Grillos.

La sala se queda en silencio porque una respuesta honesta requiere contexto, algo que los recuentos de parches y las puntuaciones CVSS nunca fueron diseñados para proporcionar. La gestión de la exposición se creó para proporcionar este contexto: cerrar la brecha entre los esfuerzos de remediación y la reducción real del riesgo. El mercado ha respondido con una inundación de plataformas afirmando entregarlo. Sin embargo, la pregunta que se hacen los líderes de seguridad es: ¿Qué plataforma de gestión de exposición realmente lo proporciona?

En este artículo, desglosaré los cuatro enfoques dominantes para la gestión de la exposición, explicaré lo que cada uno puede ofrecer y lo que no, y expondré cinco criterios de evaluación que le ayudarán a separar las plataformas creadas para reducir el riesgo de tu negocio único y el medio ambiente desde plataformas creadas para informar sobre los riesgos en la naturaleza.

Cuatro enfoques, cuatro arquitecturas

La mayoría de las plataformas de gestión de exposición se clasifican en una de cuatro categorías, cada una de las cuales está determinada por cómo el proveedor construyó (o armó) la plataforma y cómo procesa los datos.

  1. Plataformas de cartera cosidas son producto de adquisición(es). Un proveedor compra soluciones puntuales (seguridad en la nube, escaneo de vulnerabilidades, análisis de identidad, etc.) y las agrupa bajo su propia marca. En estas plataformas, cada producto conserva su propio modelo de datos y descubre su propio subconjunto de exposiciones. Luego, el proveedor puede unificar las exposiciones en una consola compartida, y eso puede parecer una integración. Pero en la práctica, cada módulo todavía opera con sus propios datos y produce sus propios hallazgos, con poca correlación o interconexión entre ellos.
  2. Plataformas de agregación de datos ingiera los resultados de sus escáneres existentes y herramientas de terceros. Luego normalizan los datos y los presentan en una interfaz unificada. Estas plataformas sólo pueden funcionar con lo que reciben. Eso significa que si los hallazgos ingeridos están desconectados, no hay forma de correlacionar cómo una exposición podría permitir la siguiente.
  3. Plataformas especializadas de dominio único Profundice en un área: configuraciones erróneas de la nube, vulnerabilidades de red, exposiciones de identidad y superficie de ataque externo. Ofrecen resultados sólidos, pero sólo en su ámbito específico de especialización. Se topan con desafíos cuando las exposiciones en un dominio se encadenan con exposiciones en otro dominio, y la plataforma no tiene forma de modelar esa relación.
  4. Plataformas integradas se crean desde cero para descubrir y correlacionar múltiples tipos de exposición (credenciales, configuraciones incorrectas, CVE, problemas de identidad, configuraciones de nube) en el mismo motor. La plataforma crea un gemelo digital del entorno y mapea cómo los atacantes pueden moverse lateralmente de una exposición a la siguiente, a través de límites locales, de nube e híbridos.

Cinco preguntas que revelan lo que realmente puede hacer una plataforma

La arquitectura detrás de cada uno de los cuatro enfoques tiene consecuencias reales sobre lo que su equipo puede ver, validar y actuar. ¿Cómo se nota la diferencia cuando se evalúa? Comience por hacer estas cinco preguntas:

1. ¿Cuántos tipos de exposición puede descubrir y con qué profundidad analiza cada uno de ellos?

Los CVE representan aproximadamente el 25% de las exposiciones que explotan los atacantes. Las configuraciones erróneas, las credenciales almacenadas en caché, los permisos excesivos y las debilidades de identidad constituyen el resto. Las carteras unidas se limitan a aquello para lo que se creó cada producto adquirido. Los agregadores sólo pueden normalizar lo que ofrecen sus feeds. Las plataformas de dominio único cubren sólo una porción del pastel. Una plataforma integrada debería cubrir tanto los existentes como (especialmente) emergente tipos de exposición, como cargas de trabajo de IA e identidades de máquinas, de forma nativa.

Y la cobertura por sí sola no le dice lo suficiente. Lo que realmente sabe la plataforma cada exposición importa tanto. Una plataforma que ingiere hallazgos de herramientas de terceros se limita a los metadatos que esas herramientas recopilan: sus condiciones de explotabilidad, su orientación de remediación, su investigación. Una plataforma que descubre exposiciones controla de forma nativa cada capa de información para cada hallazgo, desde la explotabilidad hasta la reparación. Si su plataforma no puede ver ciertos tipos de exposición, tiene puntos ciegos. Si los ve pero le falta profundidad, estás trabajando con ruido.

2. ¿Puede mapear rutas de ataque entre entornos?

Algunos productos cosidos muestran rutas de ataque. Esas rutas se derivan de la topología de la red y se basan únicamente en la conectividad. La plataforma nunca modela cómo un atacante se movería lateralmente de una exposición a la siguiente. Los agregadores no producen ninguna ruta, solo listas normalizadas de hallazgos desconectados.

La verdadera prueba es si la plataforma puede trazar caminos a través de los límites del entorno. Un atacante que captura las credenciales de la nube localmente puede eludir todas las defensas nativas de la nube, porque el camino comenzó fuera de la visibilidad de la plataforma de la nube. Una vulnerabilidad externa puede parecer de baja prioridad de forma aislada, pero si se asigna a una entidad interna con un camino hacia un activo crítico, es una emergencia. La mayoría de las plataformas no pueden establecer esas conexiones. Exploran cada entorno por sí solo y dejan inexplorados los espacios entre ellos.

3. ¿Valida la explotabilidad?

La mayoría de las plataformas verifican una o dos condiciones por exposición, limitadas por los metadatos que almacenan para cada hallazgo y la información que recopilan de cada entidad en su entorno. Pero la verdadera validación significa probar múltiples condiciones: ¿la biblioteca vulnerable está cargada por un proceso en ejecución? ¿El puerto está abierto y accesible? La plataforma debe ofrecer respuestas binarias (explotables o no, alcanzables o no, camino a activos críticos o no), todas ellas basadas en su entorno real, no en suposiciones generales.

4. ¿Tiene en cuenta los controles de seguridad?

Una vulnerabilidad CVSS 9.8 bloqueada por un firewall no se puede utilizar para movimiento lateral… porque está bloqueada. Una exposición de identidad 5.5 con una ruta directa a un controlador de dominio es una emergencia. Las plataformas que ignoran los firewalls, MFA, EDR y la segmentación pueden hacer que su equipo persiga hallazgos que no conllevan ningún riesgo real y pierda aquellos que realmente amenazan sus activos críticos. Si los controles de seguridad no forman parte del análisis de la ruta de ataque, su priorización le indicará la dirección equivocada y seguirá estando expuesto.

5. ¿Cómo prioriza?

La priorización debería responder a una pregunta: ¿Esta exposición pone en riesgo un activo crítico? La clasificación basada en puntuaciones ignora su entorno único. La clasificación basada en etiquetas de activos ignora los activos en el radio de explosión de una exposición. La clasificación de la ruta supuesta nunca valida la explotabilidad. Los tres pueden abrumar a los equipos de TI porque ninguno de ellos conecta los hallazgos con lo que la empresa realmente necesita proteger.

La priorización efectiva comienza con sus activos críticos y avanza hacia atrás. La plataforma debe demostrar que la exposición es explotable, que un atacante puede alcanzarla y que el camino conduce a algo que la empresa no puede permitirse perder. Cuando una plataforma mapea todo eso en un gráfico, surgen puntos de estrangulamiento: lugares donde una solución elimina múltiples rutas de ataque. En entornos de grandes empresas, eso reduce la lista de prioridades a aproximadamente el 2% de todas las exposiciones.

Lo que esto significa para su equipo

La elección de la arquitectura de la plataforma determina qué tan seguro será su entorno y cómo su equipo dedica su tiempo a llegar allí. Las plataformas unidas y agregadas pueden hacer que los equipos tengan que luchar para conciliar sus hallazgos entre herramientas, pelear con TI por soluciones que pueden no reducir el riesgo y perseguir exposiciones que conducen a callejones sin salida. Las plataformas de dominio único brindan profundidad en un área pero dejan puntos ciegos en el resto de la superficie de ataque.

Un enfoque integrado elimina esos gastos generales. Correlaciona las exposiciones con rutas de ataque validadas, tiene en cuenta los controles que tiene implementados e identifica las soluciones que eliminan el mayor riesgo con la menor cantidad de acciones. Cuando una remediación cierra un cuello de botella, las plataformas de gestión de exposición continua actualizan el gráfico en tiempo real. De esa manera, sabrá que las exposiciones que antes parecían urgentes ahora no conducen a ninguna parte y su cola de prioridades siempre refleja el riesgo actual.

Cuando su plataforma de gestión de exposición pueda validar la explotabilidad, modelar controles de seguridad y mapear cada ruta viable hacia sus activos críticos, podrá responder la pregunta que aparece al principio de este artículo (¿Estamos realmente más seguros?) con un honesto ¡Sí!.

Nota: Este artículo fue escrito cuidadosamente y contribuido para nuestra audiencia por Maya Malevich, directora de marketing de productos de 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.

actualice su servidor inmediatamente – CYBERDEFENSA.MX

cPanel tiene liberado actualizaciones de seguridad para abordar un problema de seguridad que afecta varias rutas de autenticación que podrían permitir a un atacante obtener acceso al software del panel de control.

El problema afecta a todas las versiones actualmente compatibles, según una alerta publicada por cPanel el martes. El problema se ha solucionado en las siguientes versiones:

  • 11.110.0.97
  • 11.118.0.63
  • 11.126.0.54
  • 11.132.0.29
  • 11.136.0.5
  • 11.134.0.20
Ciberseguridad

«Si su servidor no ejecuta una versión compatible de cPanel que sea elegible para esta actualización, se recomienda encarecidamente que trabaje para actualizar su servidor lo antes posible, ya que también puede verse afectado», señaló cPanel.

Si bien cPanel no compartió ningún detalle sobre la vulnerabilidad, la empresa de alojamiento web y registro de dominio Namecheap revelado que «se relaciona con un exploit de autenticación de inicio de sesión que podría permitir el acceso no autorizado al panel de control».

Como medida de precaución, la compañía ha aplicado una regla de firewall para bloquear el acceso a los puertos TCP 2083 y 2087, una medida que, según dijo, restringirá temporalmente el acceso de los clientes a sus interfaces cPanel y WHM hasta que se aplique un parche completo.

«Nuestro equipo está monitoreando activamente la situación y aplicará el parche oficial en todos los servidores compatibles tan pronto como esté disponible», señaló Namecheap. «El acceso a sus paneles de control se restaurará inmediatamente una vez que el parche se haya implementado con éxito».

A partir del 29 de abril de 2026 a las 02:42 am UTC, la solución se aplicó al revendedor, a los servidores de Stellar Business y al resto, según el equipo de soporte de Namecheap.

CISA agrega fallas activas de ConnectWise y Windows a KEV – CYBERDEFENSA.MX

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) el martes agregado dos fallas de seguridad que afectan a ConnectWise ScreenConnect y Microsoft Windows a sus vulnerabilidades explotadas conocidas (KEV) catálogo, basado en evidencia de explotación activa.

Las vulnerabilidades se enumeran a continuación:

  • CVE-2024-1708 (Puntuación CVSS: 8,4): una vulnerabilidad de recorrido de ruta en ConnectWise ScreenConnect que podría permitir a un atacante ejecutar código remoto o afectar directamente a datos confidenciales y sistemas críticos. (Corregido en febrero de 2024)
  • CVE-2026-32202 (Puntuación CVSS: 4,3): una vulnerabilidad de falla del mecanismo de protección en Microsoft Windows Shell que podría permitir que un atacante no autorizado realice suplantación de identidad en una red. (Corregido en abril de 2026)
Ciberseguridad

La incorporación de CVE-2026-32202 al catálogo KEV se produce un día después de que Microsoft actualizara su aviso sobre la falla para reconocer que había sido objeto de explotación activa.

Aunque Microsoft no ha revelado la naturaleza de los ataques que armaron la falla, Akamai dijo que la vulnerabilidad surgió de un parche incompleto para CVE-2026-21510, que fue explotado como día cero junto con CVE-2026-21513 por el grupo de piratería ruso APT28 en ataques dirigidos a Ucrania y países de la UE desde diciembre de 2025.

Los ataques que explotan CVE-2024-1708, por otro lado, se han encadenado con CVE-2024-1709 (puntuación CVSS: 10,0), un omisión de autenticación crítica vulnerabilidad, por múltiples actores de amenazas a lo largo de los años. A principios de este mes, Microsoft vinculó la explotación de las fallas con un actor de amenazas con sede en China al que rastrea como Storm-1175 en ataques que implementan el ransomware Medusa.

Vale la pena señalar que CISA agregó CVE-2024-1709 al catálogo KEV el 22 de febrero de 2024. Las agencias del Poder Ejecutivo Civil Federal (FCEB) deben aplicar las correcciones necesarias antes del 12 de mayo de 2026 para proteger sus redes.

LiteLLM CVE-2026-42208 Inyección SQL explotada dentro de las 36 horas posteriores a la divulgación – CYBERDEFENSA.MX

En otro caso más de actores de amenazas que se suben rápidamente al carro de la explotación, una falla de seguridad crítica recientemente revelada en BerriAI LiteLLM El paquete Python ha sido objeto de explotación activa en la naturaleza dentro de las 36 horas posteriores a que el error se hiciera público.

La vulnerabilidad, identificada como CVE-2026-42208 (puntuación CVSS: 9,3), es una inyección SQL que podría explotarse para modificar la base de datos proxy LiteLLM subyacente.

«Una consulta de base de datos utilizada durante las comprobaciones de claves de API de proxy mezcló el valor de clave proporcionado por la persona que llama en el texto de la consulta en lugar de pasarlo como un parámetro separado», mantenedores de LiteLLM dicho en una alerta la semana pasada.

Ciberseguridad

«Un atacante no autenticado podría enviar un encabezado de Autorización especialmente diseñado a cualquier ruta API de LLM (por ejemplo, POST /chat/completions) y acceder a esta consulta a través de la ruta de manejo de errores del proxy. Un atacante podría leer datos de la base de datos del proxy y puede modificarlos, lo que conduciría a un acceso no autorizado al proxy y a las credenciales que administra».

La deficiencia afecta a las siguientes versiones:

Si bien la vulnerabilidad se abordó en la versión 1.83.7-estable Lanzado el 19 de abril de 2026, el primer intento de explotación se registró el 26 de abril a las 16:17 UTC, aproximadamente 26 horas y siete minutos después de que el aviso de GitHub fuera indexado en la base de datos global de avisos de GitHub. La actividad de inyección de SQL, según Sysdig, se originó en la dirección IP 65.111.27[.]132.

«La actividad maliciosa se dividió en dos fases impulsadas por el mismo operador a través de dos IP de salida adyacentes, seguidas de una breve investigación no autenticada de los puntos finales de administración de claves», dijo el investigador de seguridad Michael Clark. dicho.

Específicamente, se dice que el actor de amenaza desconocido apuntó a tablas de bases de datos como «litellm_credentials.credential_values» y «litellm_config» que contienen información relacionada con las claves del proveedor del modelo de lenguaje grande (LLM) ascendente y el entorno de ejecución del proxy. No se observaron sondas en tablas como «litellm_users» o «litellm_team».

Esto sugiere que el atacante no sólo estaba al tanto de estas tablas, sino que también persiguió aquellas que contienen secretos confidenciales. En la segunda fase del ataque, observada después de 20 minutos, el actor de la amenaza utilizó una dirección IP diferente («65.111.25[.]67»), esta vez abusando del acceso para ejecutar una investigación similar.

LiteLLM es un popular software AI Gateway de código abierto con más de 45.000 estrellas y 7.600 bifurcaciones en GitHub. El mes pasado, el proyecto fue objeto de un ataque a la cadena de suministro orquestado por el grupo de hackers TeamPCP para robar credenciales y secretos de los usuarios intermedios.

«Una sola fila litellm_credentials a menudo contiene una clave de organización OpenAI con límites de gasto mensual de cinco cifras, una clave de consola Anthropic con derechos de administrador del espacio de trabajo y una credencial AWS Bedrock IAM», dijo Sysdig. «El radio de explosión de una extracción exitosa de una base de datos está más cerca de comprometer una cuenta en la nube que de una inyección SQL típica de una aplicación web».

Ciberseguridad

Se recomienda a los usuarios que actualicen sus instancias a la última versión. Si esta no es una opción inmediata, los mantenedores recomiendan configurar «disable_error_logs: true» en «general_settings» para eliminar la ruta a través de la cual las entradas que no son de confianza llegan a la consulta vulnerable.

«La vulnerabilidad LiteLLM (GHSA-r75f-5x8p-qvmc) continúa el patrón modal para los avisos de infraestructura de IA: crítico, previo a la autenticación y en software con recuentos de estrellas de cinco cifras en los que los operadores confían para centralizar las credenciales de nivel de nube», agregó Sysdig.

«La ventana de explotación de 36 horas es consistente con el colapso más amplio documentado por el Reloj de Día Cero, y el comportamiento del operador que registramos (nombres de tablas Prisma palabra por palabra, orientación de tres tablas, enumeración deliberada de recuento de columnas) muestra que la explotación ya no espera a una prueba de concepto pública. El aviso y el esquema de código abierto fueron finalmente suficientes».

La LofyGang brasileña resurge después de tres años con la campaña Minecraft LofyStealer – CYBERDEFENSA.MX

Un grupo de cibercrimen de origen brasileño ha resurgido después de más de tres años para orquestar una campaña que apunta a los jugadores de Minecraft con un nuevo ladrón llamado LofyStealer (también conocido como GrabBot).

«El malware se disfraza como un hack de Minecraft llamado ‘Slinky’», afirma la empresa de ciberseguridad ZenoX, con sede en Brasil. dicho en un informe técnico. «Utiliza el ícono oficial del juego para inducir la ejecución voluntaria, explotando la confianza de los usuarios jóvenes en la escena de los juegos».

La actividad se ha atribuido con gran confianza a un actor de amenazas conocido como LofyGang, al que se observó aprovechando paquetes con errores tipográficos en el registro npm para impulsar malware ladrón en 2022, específicamente con la intención de desviar datos de tarjetas de crédito y cuentas de usuario asociadas con Discord Nitro, juegos y servicios de transmisión.

El grupo, que se cree que está activo desde finales de 2021, anuncia sus herramientas y servicios en plataformas como GitHub y YouTube, al tiempo que contribuye a una comunidad de hackers clandestina bajo el alias DyPolarLofy para filtrar miles de cuentas de Disney+ y Minecraft.

«Minecraft ha sido un objetivo de LofyGang desde 2022», dijo a The Hacker News Acassio Silva, cofundador y jefe de inteligencia de amenazas de ZenoX. «Filtraron miles de cuentas de Minecraft bajo el alias DyPolarLofy en Cracked.io. La campaña actual persigue a los jugadores de Minecraft directamente a través de un hack falso ‘Slinky’».

Ciberseguridad

El ataque comienza con un hack de Minecraft que, cuando se inicia, activa la ejecución de un cargador de JavaScript que es en última instancia responsable de la implementación de LofyStealer («chromelevator.exe») en hosts comprometidos y lo ejecuta directamente en la memoria con el objetivo de recopilar una amplia gama de datos confidenciales que abarcan múltiples navegadores web, incluidos Google Chrome, Chrome Beta, Microsoft Edge, Brave, Opera, Opera GX, Mozilla Firefox y Avast Browser.

Los datos capturados, que incluyen cookies, contraseñas, tokens, tarjetas y números de cuentas bancarias internacionales (IBAN), se extraen a un servidor de comando y control (C2) ubicado en 24.152.36.[.]241.

«Históricamente, el vector principal del grupo fue la cadena de suministro de JavaScript: typosquatting de paquetes NPM, starjacking (referencias fraudulentas a repositorios legítimos de GitHub para inflar la credibilidad) y cargas útiles integradas en subdependencias para evadir la detección», dijo ZenoX.

«La atención se centró en el robo de tokens de Discord, la modificación del cliente de Discord para la interceptación de tarjetas de crédito y la exfiltración a través de webhooks que abusan de servicios legítimos (Discord, Repl.it, Glitch, GitHub y Heroku) como C2».

El último desarrollo marca un alejamiento del oficio observado anteriormente y un cambio hacia un modelo de malware como servicio (MaaS) con niveles gratuitos y premium, junto con un constructor personalizado llamado Slinky Cracked que se utiliza como vehículo de entrega para el malware ladrón.

La divulgación se produce cuando los actores de amenazas abusan cada vez más de la confianza asociada con una plataforma como GitHub para alojar repositorios falsos que actúan como señuelos para familias de malware como SmartLoader, StealC Stealer y Vidar Stealer. Los usuarios desprevenidos son dirigidos a estos repositorios mediante técnicas como el envenenamiento de SEO.

En algunos casos, se ha descubierto que los atacantes propagan Vidar 2.0 a través de publicaciones de Reddit que anuncian trucos falsos del juego Counter-Strike 2, redirigiendo a las víctimas a un sitio web malicioso que entrega un archivo ZIP que contiene el malware.

«Esta campaña de robo de información destaca un desafío de seguridad continuo en el que se abusa de plataformas ampliamente confiables para distribuir cargas útiles maliciosas», Acronis dicho en un análisis publicado el mes pasado. «Al aprovechar la confianza social y los canales de descarga comunes, los actores de amenazas a menudo pueden eludir las soluciones de seguridad tradicionales».

Ciberseguridad

Los hallazgos se suman a una lista cada vez mayor de campañas que han aprovechado GitHub en los últimos meses:

  • Dirigirse a los desarrolladores directamente dentro de GitHub, utilizando alertas de seguridad falsas de Microsoft Visual Studio Code (VS Code) publicadas a través de Discusiones para engañar a los usuarios para que instalen malware haciendo clic en un enlace. «Debido a que las Discusiones de GitHub activan notificaciones por correo electrónico para los participantes y observadores, estas publicaciones también se envían directamente a las bandejas de entrada de los desarrolladores», Socket dicho. «Esto extiende el alcance de la campaña más allá del propio GitHub y hace que las alertas parezcan más legítimas».
  • Apuntando a los sistemas judiciales de Argentina usar correos electrónicos de phishing para distribuir un archivo ZIP comprimido que utiliza un script por lotes intermedio para recuperar un troyano de acceso remoto (RAT) alojado en GitHub.
  • Creando Cuentas GitHub y aplicaciones OAuthseguido de abrir un problema que menciona a un desarrollador objetivo, lo que activa una notificación por correo electrónico que, a su vez, lo engaña para que autorice la aplicación OAuth, lo que permite efectivamente al atacante obtener sus tokens de acceso. Los problemas tienen como objetivo inducir una falsa sensación de urgencia, advirtiendo a los usuarios sobre intentos de acceso inusuales.
  • Usar repositorios fraudulentos de GitHub para distribuir instaladores de scripts por lotes maliciosos que se hacen pasar por software de seguridad y TI legítimo, lo que lleva a la implementación del descargador TookPS, que luego inicia una cadena de infección de varias etapas para establecer un acceso remoto persistente utilizando túneles inversos SSH y RAT como MineBridge RAT (también conocido como TeviRAT). La actividad ha sido atribuida a Bergantín de la grieta (también conocido como FIN11, Graceful Spider y TA505).
  • Usar repositorios de GitHub falsificados que se hacen pasar por herramientas de inteligencia artificial, trucos de juegos, scripts de Roblox, rastreadores de ubicación de números de teléfono y crackers de VPN para distribuir Cargas útiles de LuaJIT que funciona como un troyano genérico como parte de una campaña denominada TroyDen’s Lure Factory.

«La amplitud de la fábrica de señuelos (trucos de juegos, herramientas de desarrollo, rastreadores de teléfonos, scripts de Roblox, crackers de VPN) sugiere un actor que optimiza el volumen entre audiencias en lugar de apuntar con precisión», dijo Netskope.

«Los defensores deben tratar cualquier descarga alojada en GitHub que combine un intérprete renombrado con un archivo de datos opaco como un candidato de clasificación de alta prioridad, independientemente de cuán legítimo parezca el repositorio circundante».

Los investigadores descubren un fallo crítico en GitHub CVE-2026-3854 RCE que se puede explotar mediante un solo Git Push – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una vulnerabilidad de seguridad crítica que afecta a GitHub.com y GitHub Enterprise Server y que podría permitir a un usuario autenticado obtener la ejecución remota de código con un solo comando «git push».

El defecto, rastreado como CVE-2026-3854 (Puntuación CVSS: 8,7), es un caso de inyección de comandos que podría permitir a un atacante con acceso push a un repositorio lograr la ejecución remota de código en la instancia.

«Durante una operación de git push, los valores de las opciones de inserción proporcionados por el usuario no se desinfectaron adecuadamente antes de incluirlos en los encabezados de servicio internos», según un Aviso de GitHub por la vulnerabilidad. «Debido a que el formato del encabezado interno utiliza un carácter delimitador que también podría aparecer en la entrada del usuario, un atacante podría inyectar campos de metadatos adicionales a través de valores de opciones de inserción diseñados».

A la empresa de seguridad en la nube Wiz, propiedad de Google, se le atribuye el mérito de descubrir e informar el problema el 4 de marzo de 2026, y GitHub validó e implementó una solución en GitHub.com en dos horas.

La vulnerabilidad también se solucionó en las versiones 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 o posteriores de GitHub Enterprise Server. No hay evidencia de que el problema haya sido explotado alguna vez en un contexto malicioso.

Ciberseguridad

Según GitHub, el problema afecta a GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud con residencia de datos, GitHub Enterprise Cloud con usuarios administrados empresariales y GitHub Enterprise Server.

En esencia, el problema surge del hecho de que los usuarios opciones de inserción de git no se desinfectan adecuadamente antes de que los valores se incorporaran al encabezado interno X-Stat. Debido a que el formato de metadatos internos se basa en un punto y coma como carácter delimitador que también podría aparecer en la entrada del usuario, un mal actor podría aprovechar este descuido para inyectar comandos arbitrarios y ejecutarlos.

«Al encadenar varios valores inyectados, los investigadores demostraron que un atacante podría anular el entorno en el que se procesó el envío, evitar las protecciones de espacio aislado que normalmente limitan la ejecución del enlace y, en última instancia, ejecutar comandos arbitrarios en el servidor», dijo el director de seguridad de la información de GitHub, Alexis Wales. dicho.

Wiz, en un anuncio coordinado, señaló que el problema es «notablemente fácil» de explotar y agregó que permite la ejecución remota de código en nodos de almacenamiento compartido. Alrededor del 88% de los casos son actualmente vulnerables al problema en el momento de su divulgación pública. La cadena de ejecución remota de código encadena tres inyecciones:

  • Inyectar una no producción rieles_env valor para omitir la zona de pruebas
  • Inyectar dir_ganchos_personalizados para controlar para redirigir el directorio de gancho
  • Inyectar repo_pre_receive_hooks con una entrada de gancho diseñada que activa el recorrido de la ruta para ejecutar comandos arbitrarios como usuario de git

«Con la ejecución de código sin espacio aislado como usuario de git, teníamos control total sobre la instancia de GHES, incluido el acceso de lectura/escritura al sistema de archivos y la visibilidad de la configuración del servicio interno», dijo el investigador de seguridad de Wiz, Sagi Tzadik. dicho.

Ciberseguridad

En cuanto a GitHub.com, un indicador de modo empresarial, que está configurado en «verdadero» para GitHub Enterprise Server, tiene por defecto «falso», lo que deja inactiva la ruta de los enlaces personalizados. Pero dado que este indicador también se pasa en el encabezado X-Stat, es igualmente inyectable usando el mismo mecanismo, lo que resulta en la ejecución de código también en GitHub.com.

Para empeorar las cosas, dada la arquitectura multiinquilino de GitHub y su infraestructura backend compartida, la compañía señaló que obtener la ejecución de código en GitHub.com permitía la exposición entre inquilinos, lo que permitía efectivamente a un atacante leer millones de repositorios en el nodo de almacenamiento compartido, independientemente de la organización o el usuario.

A la luz de la gravedad de CVE-2026-3854, se recomienda a los usuarios que apliquen la actualización inmediatamente para una protección óptima.

«Un solo comando git push fue suficiente para explotar una falla en el protocolo interno de GitHub y lograr la ejecución del código en la infraestructura backend», dijo Wiz. «Cuando varios servicios escritos en diferentes idiomas pasan datos a través de un protocolo interno compartido, las suposiciones que cada servicio hace sobre esos datos se convierten en una superficie de ataque crítica».

«Alentamos a los equipos que crean arquitecturas multiservicio a auditar cómo fluye la entrada controlada por el usuario a través de protocolos internos, especialmente cuando la configuración crítica para la seguridad se deriva de formatos de datos compartidos».

VECT 2.0 Ransomware destruye irreversiblemente archivos de más de 131 KB en Windows, Linux y ESXi – CYBERDEFENSA.MX

Los cazadores de amenazas advierten que la operación cibercriminal conocida como VECT 2.0 actúa más como un limpiador que como un ransomware debido a una falla crítica en su implementación de cifrado en las variantes de Windows, Linux y ESXi que hace que la recuperación sea imposible incluso para los actores de amenazas.

El hecho de que el casillero de VECT destruye permanentemente archivos grandes en lugar de cifrarlos, incluso las víctimas que optan por pagar el rescate no pueden recuperar sus datos, ya que el malware descarta las claves de descifrado durante el tiempo que se produce el cifrado.

«VECT se comercializa como ransomware, pero para cualquier archivo de más de 131 KB, que es lo que más les importa a las empresas, funciona como una herramienta de destrucción de datos», dijo Eli Smadja, gerente de grupo de Check Point Research, en un comunicado compartido con The Hacker News.

«Los CISO deben comprender que en un incidente de VECT, pagar no es una estrategia de recuperación. No hay ningún descifrador que se pueda entregar, no porque los atacantes no estén dispuestos, sino porque la información necesaria para crear uno fue destruida en el momento en que se ejecutó su software. La atención debe centrarse en la resiliencia: copias de seguridad fuera de línea, procedimientos de recuperación probados y contención rápida, no en la negociación».

VECT (ahora rebautizado como VECT 2.0) es un esquema de ransomware como servicio (RaaS) que primero lanzado su programa de afiliados en diciembre de 2025. En su sitio web oscuro, el grupo muestra el mensaje «Exfiltración/Cifrado/Extorsión», destacando su modelo de negocio de triple amenaza.

Según un análisis publicado según el Consejo de Seguridad de Datos de la India (DSCI) el mes pasado, se requiere una tarifa de entrada de $250, pagadera en Monero (XMR), para los nuevos afiliados. La tarifa no se aplica a los solicitantes de los países de la Comunidad de Estados Independientes (CEI), lo que indica un intento de reclutar personas de la región.

Ciberseguridad

En las últimas semanas, el grupo ha establecido una asociación formal con el mercado de cibercrimen BreachForums y el grupo de hackers TeamPCP, en una medida destinada a reducir aún más la barrera de entrada para los operadores de ransomware e incentivar a los afiliados a lanzar ataques utilizando como arma datos previamente robados.

«La convergencia del robo de credenciales de la cadena de suministro a gran escala, una operación RaaS madura y la movilización masiva de foros de la web oscura representa un modelo sin precedentes de implementación de ransomware industrializado», señaló Dataminr a principios de este mes.

Si bien la colaboración puede ser una señal de lo que está por venir, su sitio de filtración de datos actualmente enumera solo dos víctimas, y se dice que ambas fueron comprometidas a través de los ataques a la cadena de suministro de TeamPCP. Es más, contrariamente a las afirmaciones iniciales del grupo sobre el uso de ChaCha20-Poly1305 AEAD Para el cifrado, el análisis de Check Point ha descubierto que utiliza un cifrado más débil y no autenticado sin protección de integridad.

Pero la cosa no termina ahí, ya que los casilleros basados ​​en C++ para las tres plataformas sufren de un defecto de diseño fundamental que hace que cualquier archivo de más de 131.072 bytes se destruya de forma permanente e irrecuperable, en lugar de estar cifrado.

«El malware cifra cuatro fragmentos independientes de cada ‘archivo grande’ utilizando cuatro nonces aleatorios de 12 bytes recién generados, pero añade sólo el nonce final al archivo cifrado específico en el disco», explicó Check Point. «Los primeros tres nonces, cada uno de los cuales es necesario para descifrar su respectivo fragmento, se generan, utilizan y descartan silenciosamente. Nunca se almacenan en el disco, en el registro ni se transmiten al operador».

«Debido a que ChaCha20-IETF requiere tanto la clave de 32 bytes como el nonce exacto de 12 bytes para revertir cada fragmento, las primeras tres cuartas partes de cada archivo grande son irrecuperables para cualquiera, incluido el operador de ransomware, que no puede proporcionar una herramienta de descifrado que funcione incluso después del pago del rescate. Dado que la gran mayoría de los archivos operativamente críticos exceden este umbral de ‘gran tamaño’, VECT 2.0 funciona en la práctica como un limpiador de datos con una fachada de ransomware».

La versión para Windows del ransomware, además de cifrar archivos en almacenamiento local, extraíble y accesible en red, presenta un conjunto completo de antianálisis dirigido a 44 herramientas específicas de seguridad y depuración, junto con un mecanismo de persistencia en modo seguro y múltiples plantillas de script de ejecución remota para propagación lateral.

Cuando «–force-safemode» está activo, el casillero configura el siguiente inicio en Modo seguro de Windows y escribe su propia ruta ejecutable en el Registro de Windows para que se ejecute automáticamente en el siguiente inicio en Modo seguro, donde el sistema operativo se inicia en un estado básico utilizando un conjunto limitado de archivos y controladores.

Además de eso, aunque la variante de Windows implementa mecanismos de detección del entorno para pasar desapercibidos, nunca se invocan, lo que permite a los equipos de seguridad que ejecutan los artefactos evitar desencadenar cualquier respuesta evasiva. La variante ESXi, por otro lado, aplica controles geográficos y antidepuración antes de comenzar el paso de cifrado. También intenta moverse lateralmente usando SSH. La versión de Linux utiliza la misma base de código que la versión ESXi e implementa un subconjunto de su funcionalidad.

Ciberseguridad

El paso de geofencing verifica si se está ejecutando en un país de la CEI y, de ser así, sale sin cifrar los archivos. Este comportamiento, según Check Point, es bastante inusual ya que la mayoría de los programas RaaS eliminaron a Ucrania de la lista de países de la CEI tras la invasión militar del país por parte de Rusia a principios de 2022.

«Durante los últimos años, estos controles se han eliminado en gran medida del ransomware», añadió. «Es bastante poco común que VECT incluya tales controles e incluso agregue a Ucrania a la lista de exclusiones. Check Point Research tiene dos teorías con respecto a esta observación: o este código fue generado por IA, donde los LLM fueron capacitados con Ucrania como parte de la CEI o VECT utilizó una base de código antigua para su ransomware».

Se considera que los operadores de VECT son actores novatos en lugar de actores de amenazas experimentados, sin mencionar la posibilidad de que algunos fragmentos de código se hayan generado con la ayuda de una herramienta de inteligencia artificial (IA).

«VECT 2.0 presenta un perfil de amenaza ambicioso con cobertura multiplataforma, un programa de afiliados activo, distribución en la cadena de suministro a través de la asociación TeamPCP y un panel de operador pulido», concluyó Check Point. «En la práctica, la implementación técnica está muy por debajo de su presentación.»

Por qué el movimiento seguro de datos es el cuello de botella de Zero Trust del que nadie habla – CYBERDEFENSA.MX

Todo programa de seguridad apuesta por el mismo supuesto: una vez conectado un sistema, el problema está resuelto. Abra un ticket, instale una puerta de enlace, envíe los datos. Hecho.

Esa suposición es errónea. También es una de las principales razones por las que los programas Zero Trust se estancan.

Una nueva investigación que mi equipo acaba de publicar pone cifras al respecto. El Cyber360: defendiendo el espacio de batalla digital El informe, basado en una encuesta a 500 líderes de seguridad en el gobierno, defensa y servicios críticos en los EE. UU. y el Reino Unido, encontró que el 84% de los líderes de seguridad de TI del gobierno están de acuerdo en que compartir datos confidenciales a través de redes aumenta su riesgo cibernético. Más de la mitad (53%) todavía depende de procesos manuales para mover esos datos entre sistemas. En 2026. Con la IA acelerando el ritmo de las operaciones en ambos lados.

Ésa es la brecha de Confianza Cero de la que nadie habla. No identidad. No puntos finales. El movimiento de datos en sí.

El volumen de amenazas aumenta más rápido que los controles

Cyber360 registró un promedio de 137 intentos o ataques cibernéticos exitosos por semana contra organizaciones de seguridad nacional en 2025, frente a 127 el año anterior. Las agencias estadounidenses vieron cómo la tasa semanal aumentaba un 25%. El Informe de investigaciones de violaciones de datos de 2025 de Verizon sigue una trayectoria similar en el lado empresarial: la participación de terceros en violaciones se duplicó año tras año, alcanzando el 30% de todos los incidentes. El informe de IBM sobre el costo de una vulneración de datos para 2025 sitúa el costo promedio de una vulneración que abarca múltiples entornos en 5,05 millones de dólares, aproximadamente 1 millón de dólares más que los incidentes que se producen únicamente en las instalaciones.

Los límites entre TI y OT, entre inquilinos, entre socios y entornos internos son donde se encuentran el dinero y el tiempo de permanencia en este momento.

La conectividad no es lo mismo que el movimiento seguro de datos

En el momento en que los datos cruzan un límite, ya sea entre una red OT y el SOC empresarial, entre un inquilino asociado y su nube, o entre clasificados y no clasificados, deja de ser un problema de enrutamiento y se convierte en un problema de confianza. Tiene que validarse, filtrarse y controlarse mediante políticas antes de que algo posterior pueda actuar en consecuencia. Ahí es donde las arquitecturas modernas se ralentizan.

Los datos de Cyber360 son contundentes sobre dónde se concentra el dolor:

  • El 78% de los encuestados citó la infraestructura obsoleta como una fuente principal de vulnerabilidad cibernética, señalando específicamente los sistemas analógicos y los procesos manuales como eslabones débiles.
  • El 49% mencionó garantizar la integridad de los datos y evitar la manipulación en tránsito como su mayor desafío al transferir información a través de redes clasificadas o de coalición.
  • El 45% señaló que la gestión de la identidad y la autenticación en múltiples dominios era su mayor desafío de acceso.

La integridad en tránsito, la identidad entre dominios y los procesos manuales aún están vigentes. Ésta es una descripción práctica de la superficie de ataque que los adversarios han estado explotando durante tres años.

Los datos empresariales cuentan la misma historia en un idioma diferente. El Informe de ciberseguridad OT de 2025 de Dragos encontró que el 75% de los ataques OT ahora se originan como violaciones de TI, y se espera que aproximadamente el 70% de los sistemas OT se conecten a redes de TI durante el próximo año. La brecha de aire tradicional de TI/OT efectivamente ha desaparecido. Las infracciones en la transferencia de archivos gestionados nos llevan a la conclusión. La explotación de MOVEit por parte de Cl0p comprometió a más de 2.700 organizaciones y expuso los datos personales de aproximadamente 93 millones de personas. El mismo manual funcionó contra GoAnywhere y Cleo. Cada uno de esos incidentes fue, en esencia, un ataque a las tuberías que mueven datos entre límites de confianza.

La compensación entre velocidad y seguridad es un mito

Existe una creencia persistente de que se pueden mover datos rápidamente o de forma segura. Elige uno.

En la práctica, la mayoría de los equipos eligen la seguridad y aceptan el retraso. Eso funciona cuando los ciclos de decisión se miden en minutos. No funciona cuando se miden en segundos y colapsa por completo cuando se miden en milisegundos.

La IA se está acelerando en ambos lados. Los procesos de detección y respuesta están avanzando hacia una acción autónoma. No esperan a que una puerta de enlace termine de inspeccionar un archivo. Cuando el 53% de las organizaciones de seguridad nacional todavía mueven datos manualmente, el delta entre la demanda de velocidad de IA y el suministro de velocidad analógica se convierte en la superficie de ataque. Un modelo de IA, ya sea que ejecute detección de fraude, clasificación de amenazas o análisis de objetivos, es tan bueno como los datos que le llegan. Cuando esos datos no pueden moverse libremente o no se puede confiar en ellos cuando llegan, el modelo se ejecuta en un contexto obsoleto o parcial. El cuello de botella no es la capa de inteligencia. Son las tuberías de debajo.

El papel de las tecnologías entre dominios

Aquí es donde las tecnologías entre dominios ganan su lugar, y no como una casilla de verificación de cumplimiento.

Si se hacen correctamente, eliminan la elección forzada entre velocidad y seguridad. Impulsan la confianza en el límite en lugar de después de él. Permiten que los sistemas funcionen como un todo coordinado, en lugar de como un conjunto de islas aisladas unidas con integraciones punto a punto que los atacantes ahora han demostrado que pueden desmantelar a escala.

La investigación de Cyber360 apunta hacia una respuesta arquitectónica específica: un modelo en capas que combina confianza cero, seguridad centrada en datos y soluciones entre dominios. Ningún marco cierra la brecha por sí solo. Zero Trust gobierna quién y qué. La seguridad centrada en los datos gobierna los datos en sí, dondequiera que vayan. Las soluciones entre dominios gobiernan el movimiento entre entornos. Juntos, permiten que el intercambio seguro de datos se realice a una velocidad casi en tiempo real a través de fronteras clasificadas, de coalición y operativas.

El principio se aplica mucho más allá de la defensa: programas empresariales en los que los datos SOC cruzan los límites de OT, TI y la nube; infraestructura crítica donde los datos operativos deben llegar a los tomadores de decisiones sin perder integridad; investigaciones multipartitas en las que los datos de los socios deben fluir en ambas direcciones según la política.

La conclusión

La suposición de que los datos llegan de manera confiable en el momento en que cruzan un límite es la suposición que los atacantes están explotando de manera más confiable en este momento. El límite es la superficie de ataque. El movimiento es donde la política colapsa. Y cuando más de la mitad de las organizaciones de seguridad nacional todavía mueven datos confidenciales a través de procesos manuales, la brecha entre la velocidad de la misión y la velocidad del control no es solo un cuello de botella. Es la vulnerabilidad.

Ese es el espacio en el que trabaja Everfox: asegurar el acceso, la transferencia y el movimiento de datos entre entornos a la velocidad de la misión.

Para conocer los patrones de arquitectura, la ubicación de los controles y los problemas operativos, consulte nuestra Una guía para la colaboración y el movimiento de datos seguros.

Nota: Este artículo está escrito y contribuido por Petko Stoyanov, director de tecnología de Everfox.

¿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.

Un fallo crítico sin parchear deja al LeRobot con cara abrazada expuesto a RCE no autenticado – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una falla de seguridad crítica que afecta lerobotla plataforma robótica de código abierto de Hugging Face con casi 24.000 estrellas de GitHubque podría explotarse para lograr la ejecución remota de código.

La vulnerabilidad en cuestión es CVE-2026-25874 (Puntuación CVSS: 9,3), que se ha descrito como un caso de deserialización de datos no confiables derivada del uso del formato pickle inseguro.

«LeRobot contiene una vulnerabilidad de deserialización insegura en el proceso de inferencia asíncrona, donde pickle.loads() se utiliza para deserializar datos recibidos a través de canales gRPC no autenticados sin TLS en el servidor de políticas y los componentes del cliente del robot», según un Aviso de GitHub por el defecto.

«Un atacante no autenticado accesible en la red puede lograr la ejecución de código arbitrario en el servidor o cliente enviando una carga útil de pickle diseñada a través de las llamadas gRPC SendPolicyInstructions, SendObservations o GetActions».

Ciberseguridad

Según Resecurity, el problema es arraigado en el componente PolicyServer de inferencia asíncrona, lo que permite a un atacante no autenticado que pueda alcanzar el puerto de red de PolicyServer enviar una carga útil serializada maliciosa y ejecutar comandos arbitrarios del sistema operativo en la máquina host que ejecuta el servicio.

La empresa de ciberseguridad dijo que la vulnerabilidad es «peligrosa», ya que el servicio está diseñado para sistemas de inferencia de inteligencia artificial, que tienden a ejecutarse con privilegios elevados para acceder a redes internas, conjuntos de datos y costosos recursos informáticos. Si un atacante explotara la falla, podría permitir una amplia gama de acciones, que incluyen:

  • Ejecución remota de código no autenticado
  • Compromiso total del host PolicyServer
  • Robots conectados a impacto
  • Robo de datos confidenciales, como claves API, credenciales SSH y archivos de modelo.
  • Moverse lateralmente a través de la red
  • Servicios fallidos, modelos corruptos u operaciones de sabotaje que generan riesgos para la seguridad física

El investigador de seguridad de VulnCheck Valentin Lobstein, quien descubierto y publicó detalles adicionales de la deficiencia la semana pasada, dijo que había sido validado con éxito contra la versión 0.4.3 de LeRobot. El problema actualmente sigue sin parchear, con una solución. planificado en versión 0.6.0.

Curiosamente, el mismo defecto se detectó de forma independiente. reportado por otro investigador que utiliza el alias en línea «chenpinji» en algún momento de diciembre de 2025. El equipo de LeRobot respondió a principios de enero, reconociendo el riesgo de seguridad y señalando «que parte del código base debe refactorizarse casi por completo ya que su implementación original era más experimental».

Ciberseguridad

«Dicho esto, LeRobot ha sido hasta ahora principalmente una herramienta de investigación y creación de prototipos, por lo que la seguridad de la implementación no ha sido un foco importante hasta ahora», dijo Steven Palma, líder tecnológico del proyecto. «A medida que LeRobot siga siendo adoptado e implementado en producción, comenzaremos a prestar mucha más atención a este tipo de problemas. Afortunadamente, al ser un proyecto de código abierto, la comunidad también puede ayudar informando y solucionando vulnerabilidades».

Los hallazgos exponen una vez más los peligros del uso del formato pickle, ya que allana el camino para ataques de ejecución de código arbitrario simplemente cargando un archivo especialmente diseñado.

«Es difícil exagerar la ironía aquí», señaló Lobstein. «Hugging Face creó Safetensors, un formato de serialización diseñado específicamente porque pickle es peligroso para los datos de ML. Y, sin embargo, su propio marco robótico deserializa la entrada de red controlada por el atacante con pickle.loads(), con # comentarios de nosec para silenciar la herramienta que intentaba advertirles».

Nuevos manuales para una era de ventanas cero – CYBERDEFENSA.MX

Cuando la aplicación de parches no es lo suficientemente rápida, NDR ayuda a contener la próxima era de amenazas.

Si ha estado siguiendo los avances en IA, sabrá que la ventana de explotación, el breve buffer en el que las organizaciones confiaban para parchear y proteger después de la divulgación de una vulnerabilidad, se está cerrando rápidamente.

El nuevo modelo de Anthropic, Claude Mitosy su Proyecto Ala de Vidriodemostró que encontrar vulnerabilidades explotables y grietas sutiles en las defensas de los sistemas operativos y navegadores (trabajo que antes requería semanas a los expertos) ahora se puede realizar en minutos con IA. Como resultado, el La ventana de oportunidad del parche ahora es casi nula.. La situación es tan crítica que el Secretario del Tesoro, Scott Bessent, y el Presidente de la Reserva Federal, Jerome Powell, Recientemente convocó una reunión urgente. con los directores ejecutivos de las principales instituciones financieras estadounidenses para discutir los riesgos implicados. La conclusión fue sencilla: las crecientes capacidades de IA han alterado los perfiles de riesgo, con profundas implicaciones para la estabilidad e integridad institucional en todas las industrias.

Mythos también destaca la brecha entre el descubrimiento y la remediación. Superó fácilmente la experiencia humana y resolvió una compleja simulación de red corporativa que habría requerido más de 10 horas de experiencia en programación experta. Sus descubrimientos también encontraron problemas en software con décadas de antigüedad que habían pasado desapercibidos en miles de revisiones de seguridad.

De los Mitos a la era de la suposición-incumplimiento

Mythos no es el único modelo de IA capaz de encontrar vulnerabilidades tan rápidamente. Otros partidos los han encontrado utilizando LLM más básicos.

Si su empresa utiliza algún tipo de software, debe asumir que el software probablemente contenga miles de estas vulnerabilidades desconocidas, esperando ser explotadas por el descubrimiento asistido por IA. Esto no es un fallo de su equipo de seguridad; más bien, es la consecuencia estructural de 30 años de complejidad de software acumulada que se topan con un salto en la capacidad ofensiva de la IA.

Ahora que las ventanas de explotación casi nulas son la norma, “parchear más rápido” o “parchear mejor” ya no son suficientes. Los equipos de seguridad necesitarán nuevos manuales de estrategiabasado en un modelo de supuesto incumplimiento: Se producirán infracciones y será fundamental detectarlas a medida que se produzcan y contenerlas a gran escala. Estos resultados se deciden en tiempo real, en la red.

Cómo incorporar un modelo de supuesto incumplimiento a las operaciones cotidianas

El modelo de supuesto incumplimiento tiene tres requisitos operativos, cada uno de los cuales utiliza métodos automatizados diseñados para tiempo de colapso hasta la contención:

  1. Detecte el comportamiento posterior a una infracción antes de que la amenaza se extienda en toda su empresa
  2. Reconstruya la cadena de ataque completa lo antes posible.
  3. Contener las amenazas rápidamente para limitar su radio de explosión.

En la práctica, este método de contención requiere:

Visualizando la contención como marcador

Priorice la reducción del tiempo medio de contención (MTTC) para limitar los daños mientras mantiene la vigilancia sobre las métricas de detección y respuesta (MTTD y MTTR). A medida que la IA acelera la explotación y remodela los métodos de ataque, aumenta la importancia de la velocidad para identificar, contener y resolver amenazas. La compresión de MTTC comienza con una visibilidad de red integral y en tiempo real. Con él, los SOC pueden detectar el comportamiento posterior a una infracción, determinar el radio de la explosión e interrumpir los eventos antes de que se propaguen más.

Monitoreo de técnicas favorecidas por la IA

Los ataques de IA autónoma utilizan cada vez más técnicas sofisticadas para evadir la detección, incluidos métodos de vida de la tierra (LOTL) que ocultan actividad maliciosa dentro de herramientas y procesos legítimos. Detección y respuesta de red (NDR) las plataformas desempeñan un papel crucial en la identificación de estos sutiles indicadores de compromiso. Lo hacen monitoreando continuamente el tráfico de la red en busca de comportamientos inusuales. Los signos de dicha actividad pueden aparecer como recursos compartidos de administrador de SMB inusuales, NTLM donde se espera Kerberos o nuevos pivotes RDP/WMI/DCOM, todo lo cual puede significar un movimiento lateral en su red.

Las plataformas NDR avanzadas también pueden detectar atacantes que aprovechan técnicas LOTL para mantener comunicaciones de comando y control y exfiltrar datos mientras intentan evitar generar alarmas. Los indicadores de comando y control pueden manifestarse como patrones de conexión tipo baliza, raros pares JA3/JA4 y SNI, DNS de alta entropía o DoH o DoT no autorizados. Anomalías como cargas fuera de horario, asimetría de carga/descarga, destinos por primera vez (por ejemplo, S3, Blob, GCS o nuevas CDN), compresión antes de la salida o la presencia de túneles y VPN hacia nuevos destinos pueden indicar exfiltración.

Automatizar y mantener su inventario de software

Muchas organizaciones todavía carecen de un inventario preciso y en tiempo real de su software, lo que les dificulta comprender cómo se conectan y comunican los activos. Esta brecha crea oportunidades para los adversarios. La automatización del inventario y el mapeo de activos ayuda a las organizaciones a comprender su exposición, reaccionar más rápidamente a las amenazas emergentes y reducir las ventanas disponibles para explotar las vulnerabilidades.

Correlacionar y reconstruir cadenas de ataque.

Una vez que se detecta una infracción, es vital comprender rápidamente su alcance, especialmente porque las amenazas impulsadas por la IA se mueven demasiado rápido para el análisis manual. El proceso de reconstrucción de eventos, que alguna vez fue minucioso, debe automatizarse y entregarse en tiempo real.

Investigador de luz centralparte de la empresa Plataforma NDR abiertacorrelaciona automáticamente las alertas y la actividad de la red para ayudar a reconstruir cronogramas detallados de los ataques. Esto facilita que sus propios sistemas automaticen el flujo de trabajo de respuesta y mejoren su resiliencia contra estos ataques.

Automatización de la contención

Los avances en la detección y reconstrucción de ataques deberían impulsar una contención decisiva y confiable. Limitar la propagación de amenazas, el tercer pilar del modelo de supuesto incumplimiento, es lo que convierte los datos y el conocimiento en una protección tangible. Incorporar la contención automatizada en los flujos de trabajo de defensa de la red puede reducir el riesgo de que las amenazas de rápida evolución se conviertan en incidentes generalizados.

Hacia un futuro de seguridad preparado para los Mitos

Claude Mythos y otros modelos de IA están cambiando rápidamente prácticas de larga data en materia de ciberseguridad. Prepararse para este panorama dinámico significa, en parte, construir capas defensivas adaptativas que puedan ayudarlo a acelerar sus defensas contra la IA adversaria.

  • Monitor: Mantenga una visibilidad continua de la red y automatice las detecciones para identificar amenazas tempranamente.
  • Suponer-incumplimiento: Opere con la expectativa de que se produzcan infracciones y concéntrese en una respuesta y contención rápidas.
  • Proteger: Proteja sus ecosistemas de confianza fortaleciendo los controles donde los ataques impulsados ​​por IA pueden causar el mayor daño. Construya un programa de seguridad “listo para Mythos”, como sugerido por la Cloud Security Alliance.
  • Afilar: Perfeccione continuamente sus manuales y estrategias de respuesta para contrarrestar las amenazas en evolución.

Detección y respuesta de la red Corelight

Descubra nuevos métodos de ataque con Plataforma NDR abierta de Corelight. Con visibilidad integral de la red y análisis de comportamiento profundo, Corelight está diseñado para ayudar a su SOC a detectar amenazas avanzadas impulsadas por IA más rápido, para que pueda actuar antes de que los incidentes se intensifiquen. Obtenga más información en corelight.com/elitedefense.

¿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.