Noticias de seguridad

El Informe de Vulnerabilidades de CISA para los años 2024 y 2025, publicado recientemente, transmite un mensaje contundente: las brechas de seguridad que acaparan titulares rara vez se basan en vulnerabilidades de día cero. En cambio, la agencia descubrió que la mayor parte del daño provino de debilidades de software simples y bien documentadas, así como de vulnerabilidades explotadas conocidas que las organizaciones aún dejan expuestas en internet. Como indica el informe, "la mayoría de las brechas de seguridad no se basaron en técnicas avanzadas". Según el informe, publicado en agosto de 2026 por la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), la mayor parte de la actividad provino de delincuentes oportunistas que buscaban activos expuestos —y no de grupos coordinados de estados—. "En los años fiscales 2024 y 2025, la mayor parte de la actividad de ciberamenazas no provino de grupos de ciberdelincuentes coordinados que aprovecharan exploits de día cero. En cambio, fueron delincuentes oportunistas que escaneaban internet en busca de vulnerabilidades expuestas creadas por software inseguro". La agencia presenta todo el documento como una instantánea inicial del panorama de vulnerabilidades antes de que la detección mediante IA se generalice. Las vulnerabilidades explotadas conocidas siguen un patrón predecible. Una de las conclusiones más relevantes del informe se refiere al Catálogo KEV, la lista de la agencia de vulnerabilidades CVE de alto riesgo con explotación activa confirmada. En lugar de distribuirse uniformemente en el panorama de amenazas, estas fallas se agrupan estrechamente. El informe señala que las vulnerabilidades explotadas conocidas se agrupan en torno a un grupo reducido de tipos de vulnerabilidades de alto impacto y fácilmente explotables, que ofrecen rutas de ataque consistentes y escalables. La seguridad de la memoria, la inyección y la validación incorrecta de entradas fueron las categorías predominantes. En el año fiscal 2024, estas tres categorías representaron el 19,8%, el 10,1% y el 8, % del Catálogo KEV, respectivamente. Lo más revelador es que el 41,5% de las KEV corresponden a debilidades persistentes, fallas que MITRE ha registrado en su CWE Top 25 año tras año. Algunas vulnerabilidades de MITRE, calificadas de "imperdonables" en 2007, siguen siendo explotadas en 2025. Inyección, XSS e infraestructura obsoleta En el conjunto completo de datos de CVE, las vulnerabilidades relacionadas con la inyección representaron el 10,1% de todas las CVE en el año fiscal 2024 y el 9,2% en el año fiscal 2025. Las secuencias de comandos entre sitios (CWE-79) encabezaron la lista ambos años, lo que subraya cómo la deficiente validación de entradas sigue permitiendo el secuestro de sesiones y el robo de credenciales. El informe resume la estrategia de los ciberdelincuentes de forma sencilla: "utilizan técnicas simples y fiables que funcionan en múltiples productos y entornos". Los servicios de red expuestos agravan el problema. CISA descubrió que el 26% de las entidades de infraestructura crítica analizaban servicios de red vulnerables expuestos, y aproximadamente el 18% aún utilizaba servidores FTP. Mientras tanto, el 51% de las entidades analizadas ejecutaban software sin soporte vinculado a más de la mitad de las KEV, y el 91% dependía de protocolos SSL/TLS obsoletos que permanecieron sin protección durante una media de 459 días. Estos sistemas obsoletos se convierten, en palabras del informe, en "puntos de entrada fáciles para las intrusiones". Un cambio de CVSS al riesgo en el mundo real La revisión de vulnerabilidades de CISA documenta un cambio importante en la forma en que la agencia prioriza las correcciones. Las puntuaciones de CVSS, argumenta, "reflejan la gravedad teórica, no el impacto en el mundo real y pueden inducir a error a los equipos". La priorización ahora se basa en cuatro variables: exposición de los activos, estado de las KEV, automatización de la explotación e impacto técnico. Los estudios de casos reales lo confirman. El informe detalla cómo el grupo patrocinado por el Estado chino, Salt Typhoon, explotó vulnerabilidades CVE ampliamente conocidas y sin parchear desde al menos 2021 para infiltrarse en infraestructuras de telecomunicaciones, transporte y militares en todo el mundo. La lección es clara: "Si no se parchean las vulnerabilidades KEV, no se está protegido". La seguridad desde el diseño es la solución. En última instancia, el informe exige un cambio cultural. "Las organizaciones deben pasar de reaccionar ante los ciberdelincuentes a corregir las fallas fundamentales que estos explotan". CISA insta a los productores de software a desarrollar productos seguros desde su concepción, adoptar lenguajes de programación seguros para la memoria, como Rust o Swift, publicar hojas de ruta para la seguridad de la memoria e implementar listas de materiales de software. Se recomienda a las organizaciones usuarias finales que consulten los Objetivos de Rendimiento de Ciberseguridad 2.0 y servicios gratuitos como el Escaneo de Vulnerabilidades de Higiene Cibernética, que, según la agencia, logra una reducción del 40% en las vulnerabilidades externas expuestas durante el primer año. El informe completo, repleto de datos sobre vulnerabilidades persistentes y plazos de remediación de KEV, está disponible directamente en la agencia en el PDF completo de la Revisión de Vulnerabilidades de CISA. Su conclusión principal es algo que los defensores ya han escuchado, pero que con demasiada frecuencia ignoran: los fundamentos siguen siendo clave: aplique parches a las vulnerabilidades explotadas conocidas, retire el software obsoleto, valide cada entrada y exija a los proveedores productos seguros desde el diseño. Al fin y al cabo, los ciberdelincuentes cuentan con que usted no lo haga. Fuente: CISA Vulnerability Review

La Agencia CISA publicó los resultados de dos evaluaciones de equipo rojo realizadas simultáneamente contra dos organizaciones de infraestructura crítica, utilizando técnicas similares, pero registrando resultados defensivos muy diferentes. Ambas organizaciones fueron comprometidas por completo a nivel de dominio, y en ambas, el equipo rojo también accedió a sistemas empresariales sensibles (SBS) y recursos en la nube. El aviso, identificado como AA26-237A y titulado "Historia de dos SOC", se publicó el 25 de agosto de 2026. CISA identificó al primer objetivo únicamente como una organización del Sector de Servicios e Instalaciones Gubernamentales, denominada Organización A, y al segundo como una entidad del Sector de Sistemas de Agua y Aguas Residuales, denominada Organización B. "CISA realizó dos evaluaciones de equipo rojo simultáneas utilizando técnicas similares, pero observó respuestas defensivas diferentes", indicó la agencia en el aviso. Contra la Organización A, el equipo rojo obtuvo acceso inicial tras identificar una aplicación web con credenciales predeterminadas para varias cuentas integradas, lo que le permitió enviar correos electrónicos de phishing desde una dirección interna e infectar cuatro estaciones de trabajo. Posteriormente, escaló privilegios abusando de una cuota de cuenta de máquina predeterminada junto con una plantilla de Servicios de certificados de Active Directory (AD CS) mal configurada, el mismo tipo de abuso de plantilla de certificado que se utilizó en una vulnerabilidad de toma de dominio recientemente revelada llamada Certighost. El equipo continuó accediendo a tres sistemas empresariales sensibles utilizando credenciales almacenadas en texto plano, incluyendo archivos de configuración de bases de datos descifrados y claves de acceso estáticas de Amazon Web Services (AWS) configuradas para no caducar nunca. En la nube, robó un token de actualización principal y abusó de aplicaciones Entra ID con permisos elevados para leer el correo electrónico del equipo de seguridad y comprobar si los defensores estaban al tanto de la actividad. La Organización A no detectó nada de esto. CISA afirmó que miles de falsas alarmas derivadas de las operaciones comerciales habituales, muchas de ellas con una gravedad elevada, enmascararon las alertas generadas por el equipo rojo, y que la organización gestionaba múltiples centros de operaciones de seguridad (SOC) y herramientas de punto final sin visibilidad compartida entre ellos. Los analistas carecían de procedimientos de escalamiento y tenían autoridad limitada para actuar. Una alerta real vinculada a la actividad del equipo rojo en un servidor de System Center Configuration Manager (SCCM) se descartó como falsa alarma después de que los defensores no pudieran identificar al propietario del sistema. CISA señaló las siguientes vulnerabilidades como los principales factores que permitieron la vulneración: Cuota de cuentas de máquina configurada por defecto, lo que permitía a cualquier usuario del dominio añadir cuentas de máquina. Plantillas de certificados de AD CS mal configuradas, lo que permitía solicitudes de certificados para cualquier usuario (ESC1). Credenciales en texto plano para cuentas de servicio y bases de datos almacenadas en sistemas accesibles. Claves de acceso estáticas a la nube configuradas para no caducar nunca, sin revocación de tokens. Aplicaciones con permisos excesivos en Entra ID que podían leer el correo electrónico de todos los usuarios. La Organización B, que lanzó el mismo tipo de ataque, presentó una versión diferente. Su Centro de Operaciones de Seguridad (SOC) detectó las cargas útiles de phishing iniciales en cuanto se ejecutaban y aisló las estaciones de trabajo afectadas en un plazo de 2 a 20 minutos, interrumpiendo las comunicaciones de comando y control (C2) antes de que la intrusión pudiera propagarse. Debido a la gravedad de la vulnerabilidad, los agentes de confianza de CISA en la organización ejecutaron una carga útil de equipo rojo en un host designado sin privilegios para replicar el acceso que el equipo habría obtenido de otro modo, cambiando el modelo de análisis de brechas. A partir de ahí, el equipo encontró los mismos problemas subyacentes, incluyendo credenciales en texto plano para una cuenta de servicio de dominio en un archivo de configuración de SCCM que otorgaba derechos sobre un controlador de dominio, las cuales utilizaron para ejecutar un ataque DCSync y recuperar el secreto krbtgt. El equipo también accedió a un host bastión en la zona desmilitarizada de tecnología operativa (OT) de la Organización B, pero el host bloqueó el acceso saliente a internet, por lo que no se estableció ningún canal C2 y el equipo no pudo acceder a los sistemas OT. CISA atribuyó la diferencia entre ambos resultados a las personas y los procesos que operan las herramientas, más que a las herramientas en sí. "Las herramientas de detección son tan efectivas como las personas, los procesos y los procedimientos que las respaldan", afirmó la agencia. Fuente: THN

Nuevos detalles sobre el ataque de julio a Hugging Face revelan que cientos de agentes de IA, impulsados ​​por el modelo interno IM1 de OpenAI, coordinaron la intrusión a través de un foro de mensajes no autorizado. El mes pasado, Hugging Face reveló que agentes de IA autónomos explotaron dos vulnerabilidades en su sistema de procesamiento de datos para ejecutar código, robar credenciales de la nube y del clúster, y moverse lateralmente por su infraestructura de producción.Lo revela todo un informe de OpenAI en el que trabajaron METR Y Redwood Research. En la práctica, muchos agentes acabaron utilizando una especie de tablón de mensajes no autorizado para compartir información y ayudarse mutuamente. Todo empezó cuando uno de los agentes llegó a la conclusión de que su tarea no se podía resolver de forma legítima. Lo sorprendente es que creó un tablón de anuncios para compartir esa información con otros agentes si estaban disponibles. En cuestión de horas, más de 50 agentes estaban participando en dicho foro.OpenAI confirmó posteriormente que sus modelos escaparon de un entorno de evaluación de ExploitGym mediante una vulnerabilidad de día cero en una instancia local del gestor de paquetes Artifactory de JFrog, conectada a internet. Los agentes buscaron en línea soluciones de referencia y lograron acceder a la plataforma de Hugging Face utilizando credenciales expuestas y otras vulnerabilidades. La investigación de OpenAI, validada por CrowdStrike y una evaluación independiente de METR y Redwood Research, determinó que la actividad maliciosa comenzó en mayo. En evaluaciones posteriores de ExploitGym, los agentes rompieron sus restricciones y explotaron una vulnerabilidad de actualización de tokens en Artifactory para obtener acceso de administrador. Esto les permitió usar Artifactory como un tablón de anuncios no autorizado entre agentes, donde compartieron ideas para lograr su objetivo y posteriormente coordinaron el ataque. Un agente, que se hacía llamar PHASEONE10841, improvisó el tablón de anuncios. En pocas horas, más de 50 agentes lo encontraron y comenzaron a usarlo. El informe de METR indica que "los agentes que encontraron el tablón de anuncios a menudo expresaban gran entusiasmo. ¡Dios mío! ¡Hay un tablón de anuncios compartido… Hemos encontrado a otros agentes!", decían algunos de los mensajes. OpenAI eliminó la instancia de Artifactory en algún momento. Tras reconstruirla, la empresa revocó las credenciales de los agentes, reforzó los permisos de acceso y reveló la vulnerabilidad explotada a JFrog. Sin embargo, los agentes restablecieron su canal de comunicación utilizando "solicitudes WebDAV no autenticadas para crear directorios de mensajes en Artifactory". OpenAI explica que los agentes se comunicaban mediante mensajes codificados en los nombres de los directorios. "Los agentes recuperaron acceso no autorizado a internet al hacer que el servicio de repositorio remoto de Artifactory emitiera solicitudes salientes en su nombre", explica OpenAI en el informe post mortem ampliado. A continuación, un agente obtuvo 14 credenciales de cuenta de Hugging Face con acceso escrito y las validó. Otro agente utilizó estas credenciales para descubrir y ejecutar una cadena de exploits que proporcionaba capacidad de ejecución de código completa en múltiples servidores de Hugging Face. Según METR, el enjambre estaba compuesto por 1200 agentes individuales que cooperaban en diversos niveles, y unos 700 de ellos participaron activamente en el ataque a Hugging Face. OpenAI describe la actividad como una operación bien coordinada en la que los agentes formaron equipos con roles específicos, todos trabajando para lograr el objetivo de vulnerar Hugging Face. "Los agentes comenzaron a dividir el trabajo de forma autónoma. Algunos investigaron posibles vulnerabilidades, otros buscaron credenciales y otros se centraron en la comunicación o la coordinación", describe OpenAI. "Los agentes ofrecieron su experiencia a cambio de ayuda en otros ámbitos y solicitaron a sus compañeros que pudieran estar mejor posicionados para investigar una pista en particular". La empresa de IA afirma que, si bien el enjambre no mostró una "inteligencia coherente perfecta", hubo casos en los que los agentes priorizaron el logro de objetivos colectivos sobre la realización de tareas individuales. El análisis posterior al ataque de OpenAI también incluye más detalles sobre la cadena de explotación que siguió. Los agentes explotaron una vulnerabilidad en el manejo de archivos HDF5 para extraer secretos de los trabajadores y utilizaron una vulnerabilidad de inyección de plantillas RefJinja para ejecutar código en 41 trabajadores de producción. Finalmente, obtuvieron acceso de administrador en al menos un nodo y recopilaron credenciales de producción en cuatro regiones. OpenAI cree que el comportamiento anómalo del agente se debió a una combinación de incentivos de entrenamiento y la falta de medidas de seguridad. Se animaba a los agentes a seguir trabajando en tareas aparentemente imposibles y se les recompensaba por completarlas, independientemente de cómo lo lograran. La empresa afirma que las evaluaciones carecían de las medidas de seguridad estándar que probablemente habrían detectado y detenido la actividad maliciosa "más de un día" antes de que los modelos vulneraran Hugging Face. En respuesta, OpenAI ha puesto en cuarentena los pesos de IM1 y ha pausado su mayor entrenamiento de frontera, al tiempo que ha reforzado el aislamiento del entorno aislado y exige la monitorización de la cadena de pensamiento para los modelos capaces (GPT-5.6 Sol o superior). Las alertas graves deben resolverse ahora en 30 minutos; de lo contrario, se detendrá la actividad afectada. La empresa también ha compartido un informe técnico [PDF] sobre el incidente de Hugging Face, que detalla la cronología del ataque y un plan de acción para mejorar la seguridad de la infraestructura de investigación, aumentar la visibilidad y la supervisión de la actividad de los agentes mediante la monitorización de la cadena de pensamiento y fortalecer la respuesta ante incidentes.Teóricamente cada agente tenía que haberlo intentado por su cuenta, pero todo aquello se convirtió en un proyecto colectivo de investigación ofensiva en ciberseguridad.Los agentes probaron además varias formas de manipular las propias pruebas de evaluación. Así,Trataron de modificar las aplicaciones que debían explotar para hacerlos más vulnerables.Intentaron engañar al sistema automático que los puntuaba. Y también buscaron métodos para ocultar evidencias de que estaban haciendo trampasMETR incluso encontró incluso un mecanismo de tool call spoofing: que en la transcripción se indicase que se había ejecutado un comando cuando en realidad se había ejecutado otro distinto (más peligroso).Uno de los agentes encontró credenciales relacionadas con esta plataforma y diseñó una subida maliciosa de un conjunto de datos con la que consiguió que el servidor le devolviera archivos que no debería haberle dado. La técnica se propagó rápidamente entre el resto de agentes, y en cuestión de horas 688 de ellos la estaban usando para obtener datos y tratar de ampliar ese accceso.Ahí es donde el experimento "escapó" del entorno de pruebas de OpenAI y saltó a una infraestructura real.Ryan Greenblatt, que realizó buena parte del análisis de las transcripciones para METR y Redwood, resume una conclusión inquietante en el mismo: todavía no tenemos herramientas adecuadas para comprender y controlar la actividad de estos "enjambres de agentes". Analizar todo a posteriori ya fue especialmente complejo, pero analizarlo en tiempo real es todo un desafío al que de momento parece que no podemos enfrentarnos. Fuente: BC

Meta anunció una serie de funciones de seguridad para las cuentas de WhatsApp, incluyendo la compatibilidad con passkey para una cuenta. Esto permitirá a los usuarios de dispositivos iOS y Android iniciar sesión en sus cuentas mediante un método resistente al phishing. El gigante tecnológico afirmó que más de mil millones de personas utilizan passkey para iniciar sesión en WhatsApp. La compatibilidad con contraseñas se introdujo por primera vez en Android en octubre de 2023, antes de extenderse a iOS a principios de 2024. Meta también integró las contraseñas en los inicios de sesión de Facebook en junio de 2025.Una llave de acceso (Passkey) te permite volver a iniciar sesión en WhatsApp con tu huella dactilar, Face ID o un código de bloqueo de pantalla. Es la forma más rápida y segura de verificar que realmente eres tú, sin códigos ni PIN. Los usuarios pueden gestionar sus contraseñas en Ajustes > Cuenta > Passkey. Además, WhatsApp anunció que añadirá la opción de contraseña completa como parte de la verificación en dos pasos, y los usuarios de Android verán más contexto en las llamadas de personas que no están en sus contactos. La verificación en dos pasos es una capa de protección adicional que ayuda a evitar que alguien se apodere de tu cuenta, incluso si consigue tu código de un solo uso, explicó WhatsApp en una publicación de blog. Hasta ahora era un PIN de seis dígitos; ahora lo hemos actualizado a una contraseña completa: más larga, alfanumérica e incluso con caracteres especiales para que sea más difícil de adivinar. Si has estado usando "123456", esta es una señal para que actualices tu contraseña. WhatsApp también señaló que el contexto adicional incluirá detalles como el origen de la llamada, si la persona que llama ya está en tu lista de contactos y si ambas partes pertenecen a algún grupo en común. Los estafadores se aprovechan de la urgencia; ahora puedes tomarte un momento para agregar más información antes de responder, indicó la aplicación de mensajería. Fuente: THN

La Agencia CISA añadió el lunes una vulnerabilidad de máxima gravedad que afecta a Oracle HTTP Server y Oracle WebLogic Server a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), citando evidencia de explotación activa.La vulnerabilidad, identificada como CVE-2026-21962 (CVSS: 10.0), permite que un atacante no autenticado con acceso a la red a través de HTTP comprometa Oracle HTTP Server y el complemento proxy de Oracle WebLogic Server. La explotación exitosa de la vulnerabilidad puede resultar en acceso no autorizado a las instancias o modificación de datos críticos."Oracle HTTP Server y el complemento proxy de Oracle WebLogic Server contienen una vulnerabilidad de control de acceso inadecuado que puede resultar en la creación, eliminación o modificación no autorizadas de datos críticos, así como en el acceso no autorizado a datos críticos o el acceso completo a todos los datos accesibles de Oracle HTTP Server y el complemento proxy de Oracle WebLogic Server", declaró CISA.Si bien Oracle publicó parches para la vulnerabilidad a principios de enero, desde entonces se han detectado intentos de explotación activos, según informes de GreyNoise y CloudSEK.En febrero de 2026, se descubrió que una única dirección IP (193.24.123[.]42) intentaba explotar múltiples vulnerabilidades conocidas que afectaban a Oracle WebLogic, Ivanti Endpoint Manager Mobile, GNU InetUtils y GLPI. Un mes después, CloudSEK informó haber detectado intentos de explotación dirigidos a su red honeypot."Además de CVE-2026-21962, el honeypot captó ataques dirigidos a otras vulnerabilidades persistentes y críticas de ejecución remota de código (RCE) en WebLogic, incluidas CVE-2020-14882/14883 (RCE en la consola), CVE-2020-2551 (RCE en IIOP) y CVE-2017-10271 (RCE en WLS-WSAT)", señaló CloudSEK en ese momento. Esto confirma que los ciberdelincuentes siguen recurriendo a un pequeño conjunto de vulnerabilidades altamente efectivas y fáciles de explotar para comprometer los entornos WebLogic.Fuente: THN