En este número
🌡️ Nivel de amenaza
⚡ Noticias: Cinco noticias de seguridad que conviene conocer
🔎 Análisis a fondo: La brecha de la baja de empleados
🎣 ¿Es phishing?
🔬 Investigación técnica: No robaron una contraseña. La falsificaron.
🛠️ Herramienta de la semana: Tor para la investigación de seguridad controlada
👏 Persona de la semana: Romain Thomas
📅 Evento de la semana: Black Hat USA 2026
📚 Libro de la semana: Spycraft
😅 El meme
❓ Una pregunta antes de despedirnos
Desde fuera, la baja de un empleado puede parecer completa: el portátil está devuelto, la tarjeta de acceso desactivada, el correo de despedida enviado y la tarta ya no queda. Es un final convincente.
Lo incómodo es que ninguno de esos pasos le dice a una sesión antigua, a un token olvidado o a una unidad compartida que la persona se ha ido. Si la salida no llega a los propios sistemas, el acceso puede seguir como si el lunes fuera un día laborable más.
Ahí empieza este número: con una despedida limpia, un rastro de accesos desordenado y una pregunta que debería ser más fácil de responder: ¿qué sigue funcionando, exactamente?
🌡️Nivel de amenaza
⚡ Noticias
Cinco versiones de confianza de AsyncAPI llevaban malware, y la procedencia válida no las detuvo
Unos atacantes comprometieron los flujos de trabajo de publicación de AsyncAPI el 14 de julio y publicaron cinco versiones maliciosas en cuatro paquetes de npm. Los paquetes contenían Miasma, un backdoor capaz de ejecutar comandos en los sistemas afectados. El código se activaba al importarse y no durante la instalación, por lo que --ignore-scripts no ofrecía ninguna protección. Los equipos deben inspeccionar los archivos de bloqueo de dependencias, las cachés de compilación y los registros de CI, y después rotar las credenciales accesibles para las compilaciones potencialmente afectadas.
Dos fallos explotados colocan AD FS y SharePoint al frente de la cola de parches de julio de Microsoft
Microsoft enumera en las notas de su versión de julio 622 vulnerabilidades, aunque los totales varían según la metodología de recuento. Dos fallos ya se estaban explotando: CVE-2026-56155 permite la escalada local de privilegios en Active Directory Federation Services, mientras que CVE-2026-56164 afecta a SharePoint local y es alcanzable sin autenticación. CISA añadió ambos a su catálogo de Vulnerabilidades Explotadas Conocidas (Known Exploited Vulnerabilities), con lo que la infraestructura de identidad y los servidores SharePoint expuestos pasan a ser las prioridades inmediatas.
SonicWall confirma ataques activos contra dos vulnerabilidades de SMA 1000
SonicWall afirma que unos atacantes están explotando CVE-2026-15409 y CVE-2026-15410 contra dispositivos SMA 1000. La primera es un fallo de falsificación de solicitudes del lado del servidor con una puntuación CVSS de 10.0. La segunda puede permitir la inyección de código en determinadas condiciones. Aplicar el hotfix es solo el primer paso. SonicWall también recomienda una revisión forense y, si se encuentran indicadores de compromiso, reconstruir el dispositivo a partir de una imagen de confianza.
Los ID de cliente OAuth falsos permiten a los atacantes probar credenciales de Entra sin completar un inicio de sesión
Proofpoint observó a atacantes que generaban grandes cantidades de identificadores de aplicaciones OAuth falsificados y que usaban las respuestas de Microsoft Entra para deducir si las cuentas y las contraseñas eran válidas. Como el intento no genera un inicio de sesión correcto convencional, las reglas de monitorización habituales pueden pasarlo por alto. Entre las señales útiles figuran la ausencia de nombres de aplicación, los identificadores en blanco, los volúmenes inusuales de ID de cliente inexistentes y patrones de error como AADSTS700016 junto a intentos con credenciales válidas.
Investigadores encontraron una ruta de clics sintéticos hacia los flujos de trabajo de Claude for Chrome
Manifold Security afirma que otra extensión del navegador con acceso a claude.ai podría generar clics sintéticos que activen tareas predefinidas de Claude for Chrome relacionadas con servicios como Gmail, Google Docs, Calendar y Salesforce. El ataque descrito requiere que ya haya en el navegador una extensión maliciosa o comprometida. Las organizaciones que prueban agentes de navegador deben revisar los permisos de las extensiones, limitar las aplicaciones conectadas y evitar los ajustes de aprobación desatendida en los flujos de trabajo sensibles.
🔎 Análisis a fondo
La brecha de la baja de empleados
El empleado llevaba semanas fuera. La tarjeta de acceso ya no funcionaba, la cuenta principal estaba desactivada y la salida parecía completa.
Entonces alguien revisó los registros del servidor.
Apple alega que un exempleado que no había devuelto un portátil de la empresa encontró la manera de volver a entrar en su red interna y descargó archivos confidenciales de hardware. Las acusaciones siguen ante los tribunales y la cuestión de la intención les corresponde a ellos. Para los equipos de seguridad, el misterio más revelador es lo que ocurrió antes de la descarga:
¿En qué seguía dispuesto a confiar el sistema de Apple?
Reuters informó de las acusaciones y de la respuesta de la otra parte.
El primer sospechoso: la cuenta principal
Cuando un empleado se va, la cuenta de identidad central suele ser el primer lugar donde se mira. Se desactiva, se termina el acceso y se da la tarea por completada.
Pero una cuenta es solo una de las vías de entrada a un entorno.
Una aplicación puede conservar una sesión activa. Un servicio puede aceptar un token emitido antes. Un dispositivo de la empresa puede llevar un certificado válido. Un script interno puede usar una clave de API creada por el empleado pero almacenada en otro lugar. Una contraseña compartida puede no estar vinculada en absoluto a una identidad individual.
Cada una de ellas puede seguir siendo utilizable después de que desaparezca la cuenta principal.
Piense en un token emitido a las 9:00 de la mañana. La cuenta del empleado se desactiva al mediodía, pero la aplicación valida el token localmente en lugar de consultar al proveedor de identidad su estado actualizado.
El proveedor de identidad sabe que la cuenta está desactivada. La aplicación solo sabe que el token está correctamente firmado y no ha caducado.
Ambos sistemas parecen funcionar. El fallo vive en el espacio que hay entre ellos.
El ticket estaba en verde
Es posible que el registro de la baja siga pareciendo perfecto:
La cuenta se desactivó.
Se devolvió la tarjeta de acceso.
Se enviaron las solicitudes de retirada de accesos.
Se cerró el ticket de salida.
El ticket demuestra que el flujo de trabajo realizó las acciones previstas. No demuestra que todas las aplicaciones, dispositivos y credenciales hayan dejado de aceptar al exempleado.
Si cinco sistemas tenían acceso y solo cuatro confirman su retirada, el quinto sistema no es un éxito silencioso. Es una pregunta sin respuesta.
Quizá la solicitud nunca llegó. Quizá el sistema no logró procesarla. Quizá el acceso se retiró pero la confirmación nunca se devolvió. Hasta que se conozca el resultado, no se puede tratar con seguridad esas posibilidades como equivalentes.
El portátil desaparecido cambia la investigación
Un portátil de la empresa no es solo un activo pendiente de devolución. Puede contener sesiones activas, credenciales almacenadas localmente, certificados de dispositivo y un historial de confianza con los servicios internos.
Eso significa que recuperar el dispositivo y revocar su acceso son dos acciones distintas. Un portátil puede figurar como desaparecido mientras los certificados asociados siguen siendo válidos. Una cuenta de usuario puede estar desactivada mientras una aplicación sigue aceptando una sesión creada desde ese dispositivo.
La salida física se produjo. La relación técnica no terminó necesariamente con ella.
Por eso cada cuenta, token, clave, certificado y dispositivo de confianza necesita tres datos:
¿Quién o qué es su propietario?
¿Qué sistemas lo aceptan?
¿Cómo se puede revocar, rotar o dejar que caduque?
Si se desconoce el propietario, el flujo de trabajo de baja no tiene ningún motivo fiable para incluir la credencial. Puede sobrevivir simplemente porque ningún sistema reconoce la salida del empleado como relevante para ella.
La pista oculta en el tráfico normal
Supongamos que un token antiguo se usa tres semanas después de que su propietario se haya ido. ¿Reconocería el sistema de monitorización su importancia, o registraría una solicitud autenticada correcta más?
Sin contexto de propiedad, la solicitud puede parecer normal. El token es válido. El certificado es conocido. El dispositivo ya se ha conectado antes.
Si se asocian al mismo evento el antiguo propietario y la fecha de salida, el panorama cambia. Una solicitud correcta puede revelar que una vía de acceso sobrevivió a la salida. Los fallos repetidos pueden poner al descubierto un script olvidado, una sesión en caché o un dispositivo que sigue intentando reconectarse.
Nada de esto demuestra una intención maliciosa. Sí revela que la limpieza fue incompleta, que es justo lo que el control debería detectar.
Cerrar todas las puertas
Cada vía de acceso requiere un cierre distinto. Las contraseñas compartidas deben rotarse. Puede ser necesario revocar los certificados de dispositivo. Hay que terminar las sesiones existentes. Las aplicaciones independientes pueden requerir cambios de cuenta por separado. Puede ser necesario sustituir las claves de API sin interrumpir los servicios que las usan.
La acción cambia, pero la evidencia exigida debe seguir siendo la misma.
Una baja está completa cuando la organización puede identificar las vías de acceso, confirmar que cada una dejó de funcionar y detectar cualquiera que reaparezca.
Hasta entonces, el empleado puede haberse ido mientras una parte de su acceso sigue dentro.
🎣 ¿Es phishing?
Un dominio legítimo no hace legítimo el flujo de trabajo. No introduzca nunca un código de dispositivo que no haya generado usted mismo.
🔬 Investigación técnica
No robaron una contraseña. La falsificaron.
A veces el atacante ni siquiera necesita su contraseña. Solo necesita que su servidor crea que ya la tiene.
Ese es el núcleo incómodo de CVE-2026-55040, una omisión de autenticación crítica en Microsoft SharePoint Server local, divulgada el 14 de julio de 2026 y descubierta por el investigador de Rapid7 Labs Stephen Fewer; se demostró por primera vez en directo en Pwn2Own Berlín y no se detectó en la práctica. Tiene una puntuación CVSS v3.1 de 9.1 y afecta a SharePoint Server 2016, 2019 y Subscription Edition.
Cómo se rompe la confianza
SharePoint se ejecuta sobre IIS y ASP.NET, y su modelo de autenticación se basa en notificaciones (claims): una solicitud presenta un token firmado que afirma una identidad, y se supone que los módulos del backend verifican criptográficamente ese token antes de que se establezca una sesión. Ese paso de verificación es todo el límite de seguridad: todo lo que viene después (permisos, paneles de administración, acceso al contenido) da por hecho que el token se comprobó correctamente antes de llegar hasta allí.
CVE-2026-55040 rompió esa suposición. Varias debilidades en la canalización de validación de JWT de SharePoint hacían que se pudiera lograr que el servidor aceptara un token que debería haber rechazado, y asociaría la sesión resultante con la identidad que afirmaba el token, no con la de quien realmente envió la solicitud. Sin contraseña. Sin cookie de sesión robada. Sin acceso previo. Solo un token que el servidor estaba dispuesto a creer.
Hay una condición previa: el atacante ya tiene que saber a quién quiere suplantar. En la práctica es un listón bajo: los nombres de usuario suelen poder descubrirse mediante reconocimiento rutinario (enumeración de AD, OSINT, datos de filtraciones anteriores) y no son secretos como lo es una contraseña. Lo que hace la vulnerabilidad es convertir «conozco un nombre de usuario» en «soy ese usuario, plenamente autenticado, con el acceso que tenga ese usuario». Si la identidad elegida es la de un administrador del sitio, el atacante hereda las operaciones de administración de SharePoint sin tocar jamás las credenciales de ese administrador.
La superficie expuesta empeora esto respecto a un fallo típico solo interno: los endpoints relevantes están bajo rutas como vtibin y _layouts, a las que se puede acceder de forma remota sin autenticación en las configuraciones predeterminadas de SharePoint. No es una API interna de nicho a la que el atacante necesite un acceso previo para llegar: está expuesta por defecto en cualquier implementación accesible desde Internet.
Por qué esto no termina en el «acceso no autorizado»
Esta es la parte que debería hacer que figure en esta sección del boletín y no solo en una viñeta de las notas del parche: la investigación de Rapid7 no se detuvo en la omisión de autenticación. Su equipo descubrió que CVE-2026-55040 puede encadenarse con una segunda vulnerabilidad, actualmente sin parche, para lograr ejecución remota de código completa sin autenticación: sin inicio de sesión, sin credenciales, sin interacción del usuario, ni siquiera una identidad de administrador. El par se desarrolló y se demostró conjuntamente como una participación en Pwn2Own Berlín y se divulgó de forma responsable a Microsoft en mayo. (Nota: este componente de RCE sin parchear es un problema distinto e independiente de CVE-2026-58644, una RCE de deserialización que Microsoft también corrigió el 14 de julio; no deben confundirse.)
Conviene incluir la cronología de divulgación de Microsoft, porque muestra lo deliberadamente que se planificó todo:
18 de mayo de 2026: Rapid7 divulga a Microsoft la cadena de explotación completa de RCE sin autenticación
20 de mayo de 2026: Microsoft confirma los hallazgos y reparte la corrección en dos ciclos de actualización: la omisión de autenticación en julio, el componente de RCE en agosto
29 de mayo de 2026: Rapid7 acepta un embargo de 30 días sobre los detalles técnicos tras la divulgación de julio, con la salvedad de que publicará antes si se produce una explotación en la práctica o una divulgación por terceros
14 de julio de 2026: La divulgación pública de CVE-2026-55040 y el parche se publican juntos en el Patch Tuesday
Eso significa que el parche de julio no cierra la historia: la interrumpe. Rompe la cadena en el primer eslabón, antes de que el segundo esté siquiera corregido. Cualquier organización que aplique hoy el parche de CVE-2026-55040 queda protegida frente a la cadena conocida actualmente, ya que la mitad de RCE no es alcanzable sin una identidad falsificada válida. Pero la lección de fondo (que una identidad falsificada, una vez aceptada, es funcionalmente indistinguible de una real) no desaparece con un ciclo de parches, y el parche de RCE de agosto es, en la práctica, un segundo plazo ya marcado en el calendario.
Estado de explotación: en el momento de redactar este texto, CISA y Microsoft no han catalogado CVE-2026-55040 como explotada activamente en la práctica; Microsoft la ha etiquetado como «Exploitation More Likely» (explotación más probable) y no como explotación confirmada. Es un estado sensiblemente distinto del de otras tres CVE de SharePoint corregidas en el mismo ciclo (CVE-2026-32201, CVE-2026-45659, CVE-2026-56164), que CISA confirmó que se están explotando activamente y se usan para acceso no autorizado, RCE, robo de claves de máquina de IIS y persistencia de malware. Aún no hay ninguna prueba de concepto pública de CVE-2026-55040; Rapid7 ha retenido los detalles técnicos completos bajo su embargo de 30 días. Los equipos de seguridad no deben interpretar el periodo de silencio como un periodo de gracia: es una cuenta atrás programada hasta agosto.
Qué vigilamos
La alerta vigente de CISA sobre el bastionado de SharePoint está redactada para las CVE hermanas que ya se están explotando activamente, no para CVE-2026-55040 en concreto, pero los comportamientos que describe (robo de claves de máquina de IIS, abuso de deserialización, persistencia, despliegue de malware) son las mismas categorías de actividad posterior a la explotación que cabría esperar cuando la mitad de RCE de esta cadena se haga pública. Si su instancia de SharePoint era accesible desde Internet antes del 14 de julio, aplicar el parche responde a «¿sigo siendo vulnerable?», pero no a «¿ya me utilizaron?». Conviene revisar en cualquier instancia expuesta, según nuestra propia lectura del patrón de amenaza:
Acciones de administración o cambios de contenido o permisos procedentes de sesiones que no se correlacionan con un evento de inicio de sesión real
Nuevos administradores de colecciones de sitios o concesiones de roles elevados sin un ticket correspondiente del servicio de asistencia o de gestión de cambios
Solicitudes inusuales o anómalas a vtibin / _layouts en los registros de IIS anteriores al parche
Cualquier movimiento lateral o intento de autenticación originado en la cuenta de servicio de SharePoint o en la identidad del grupo de aplicaciones
Conexiones salientes o nuevas tareas programadas iniciadas desde el propio servidor de SharePoint
El patrón, otra vez
FortiBleed trataba de un acceso que cambiaba de manos: credenciales recolectadas, verificadas y vendidas como inventario. Esto trata de un acceso que nunca llegó a existir realmente: una sesión que se engañó al servidor para que creyera legítima, sin que hiciera falta robo alguno. Mecanismo distinto, misma conclusión: cuando hay algo visible a lo que responder, el compromiso importante puede haberse producido ya en silencio, aguas arriba. Y en este caso, la segunda mitad de la cadena aún está por llegar.
🛠️ Herramienta de la semana
Tor
Tor suele asociarse con la navegación anónima, pero para los equipos de seguridad uno de sus usos más valiosos es la investigación controlada.
Dónde encaja
Imagine que el nombre de una empresa aparece en un sitio de filtraciones de ransomware. La publicación afirma que se robaron archivos internos y da a la organización un plazo para responder.
Antes de tratar la afirmación como una brecha confirmada, un analista debe inspeccionar la página, registrar lo que se publicó y determinar si alguna muestra de datos es genuina. Hacerlo desde un navegador corporativo normal puede revelar la dirección IP pública de la organización a la infraestructura investigada.
El navegador puede revelar más que una dirección IP. Las cookies, las extensiones, las fuentes y otras características pueden ayudar a distinguir a un visitante de otro. La actividad de investigación también puede mezclarse con las cuentas habituales y el historial de navegación del analista.
Tor Browser crea una separación entre la investigación y el entorno de navegación normal de la organización. Enruta el tráfico a través de varios relés, oculta la dirección IP original al destino e incluye protecciones diseñadas para dificultar la identificación del navegador mediante fingerprinting.
Cómo funciona la conexión
Un navegador normal suele conectarse directamente al destino. Por tanto, el sitio web puede ver la dirección IP pública desde la que se originó la solicitud.
Tor envía la conexión a través de varios relés antes de que llegue al destino. Cada relé conoce solo el paso anterior y el siguiente de la ruta. El destino ve la dirección del último relé de Tor en lugar de la IP corporativa o doméstica del analista.
Este diseño también permite acceder a los servicios onion. Estos servicios operan dentro de la red Tor y se usan habitualmente para publicaciones centradas en la privacidad, comunicaciones seguras y, en algunos casos, sitios de filtraciones criminales y foros clandestinos.
Un flujo de trabajo práctico
Abra Tor Browser dentro de un entorno de investigación dedicado, separado de la navegación corporativa habitual. Visite el servicio onion pertinente y registre la afirmación, la hora de publicación, la organización afectada y cualquier plazo indicado. Capture la página y conserve la URL original para que la evidencia pueda revisarse aunque la publicación cambie o desaparezca. Examine con cuidado las muestras visibles. Compare los nombres de archivo, las estructuras de los documentos o los marcadores no sensibles con la información interna antes de concluir que los datos son auténticos. Registre lo que se ha verificado, lo que sigue siendo una afirmación del atacante y lo que todavía no puede confirmarse. Traslade los hallazgos al proceso de respuesta a incidentes sin descargar ni redistribuir datos expuestos innecesarios.
Este flujo de trabajo puede dar al equipo de respuesta una respuesta temprana a una pregunta útil: ¿la publicación es ruido reciclado, una afirmación sin evidencia que la respalde o una señal creíble que requiere una investigación inmediata?
Más allá de la monitorización de ransomware
Tor puede respaldar otras formas de investigación de seguridad. Los analistas pueden usarlo para examinar infraestructura de phishing, seguir pistas de inteligencia de amenazas, monitorizar referencias a dominios de la empresa o estudiar cómo se anuncian las credenciales y los accesos robados.
También puede ayudar a los investigadores a llegar a recursos de seguridad que no están disponibles o están restringidos en su ubicación. En cada caso, su propósito es el mismo: crear distancia entre la investigación y la identidad o la red de quien la lleva a cabo.
Lo que no sustituye
Tor no garantiza el anonimato completo. Iniciar sesión en una cuenta personal, reutilizar un nombre de usuario conocido, revelar información identificativa o interactuar con un patrón de comunicación familiar puede identificar al investigador, sea cual sea la ruta de red.
Los archivos descargados introducen otro riesgo. Abrir un documento en una aplicación externa puede crear una conexión fuera de Tor o exponer información sobre el dispositivo. Los archivos sospechosos deben manejarse en un entorno de análisis aislado, no abrirse directamente desde la sesión de investigación.
Además, Tor solo protege las aplicaciones configuradas para enviar su tráfico a través de él. No protege automáticamente todas las conexiones del dispositivo, y enrutar otro navegador por la red Tor no ofrece las protecciones de privacidad integradas en Tor Browser.
No sustituye una estación de trabajo de investigación aislada, la protección de endpoints, el manejo cuidadoso de la evidencia, el asesoramiento jurídico ni unos procedimientos de investigación claros. Tor protege la ruta hacia el destino. La seguridad de la investigación sigue dependiendo de lo que ocurra antes, durante y después de la conexión.
👏 Persona de la semana
Romain Thomas es un ingeniero de seguridad conocido por su trabajo en ingeniería inversa, protección de software y ofuscación en Android, iOS, macOS y Windows.
Lo que hace especialmente valiosa la contribución de Romain T es que comparte lo que construye con la comunidad de seguridad en general.
Romain creó LIEF, una biblioteca de código abierto que ayuda a investigadores y desarrolladores a analizar y modificar formatos ejecutables como PE, ELF y Mach-O. Hoy, LIEF respalda muchos proyectos de ingeniería inversa, instrumentación y seguridad.
Su trabajo de código abierto incluye también contribuciones a QBDI y QBDL, además de Open Obfuscator, un proyecto que inició para avanzar en la protección de aplicaciones móviles.
Este reconocimiento no es solo por una herramienta exitosa. Es por años dedicados a hacer más accesible el trabajo complejo de seguridad y a dar a otros investigadores una base más sólida sobre la que construir.
Esta semana, ese trabajo, y la persona que hay detrás, merece el foco.
📅 Evento de la semana
Evento de la semana: Black Hat USA 2026
Black Hat USA comienza el sábado 1 de agosto con cuatro días de formación técnica, antes de que las cumbres, las presentaciones de investigación y las demostraciones de Arsenal continúen la semana siguiente.
Incluso sin viajar a Las Vegas, esta es una semana útil para seguir la agenda. La investigación divulgada en Black Hat suele marcar las conversaciones sobre vulnerabilidades, detección y herramientas que vienen después. El programa de este año presta especial atención a las amenazas autónomas de IA, la identidad y la confianza, la seguridad de la infraestructura y las herramientas defensivas de código abierto.
📚 Libro de la semana
Spycraft: The Secret History of the CIA’s Spytechs, from Communism to al-Qaeda
Por Robert Wallace, H. Keith Melton y Henry R. Schlesinger
Spycraft revela cómo los ingenieros de la Office of Technical Service de la CIA construyeron cámaras, disfraces, dispositivos de ocultación y sistemas de comunicación para entornos hostiles. Su lección sigue vigente para la ciberseguridad: la tecnología cambia, pero la seguridad eficaz depende de comprender al adversario, el entorno y a la persona que usa la herramienta.
😅 El meme
Si alguien dejara hoy su organización, ¿podría demostrar, sin comprobar manualmente cada sistema, que todas las cuentas, sesiones, tokens, claves y credenciales compartidas vinculadas a esa persona han dejado de funcionar?
The Breach Brief, Equipo de Ostorlab: No robaron una contraseña. La falsificaron.