El exploit Certighost permite a usuarios de Active Directory con pocos privilegios hacerse pasar por un controlador de dominio – CYBERDEFENSA.MX

Los investigadores H0j3n y Aniq Fakhrul publicaron un exploit funcional el 24 de julio que permite a un usuario de Active Directory con pocos privilegios obtener un certificado para un controlador de dominio y autenticarse como esa máquina.

Le pusieron el nombre en código a la falla. Certighost. Debido a que las cuentas de controlador de dominio tienen derechos de replicación de directorios, la credencial Kerberos resultante puede recuperar el krbtgt secreto a través de DCSync.

Microsoft solucionó el problema de los Servicios de certificados de Active Directory (AD CS) diez días antes como CVE-2026-54121. Microsoft clasificó la falla como autorización inadecuada y le asignó una puntuación CVSS de 8,8.

La explotación requiere acceso a la red y una cuenta de dominio, pero no derechos de administrador ni interacción del usuario. En la prueba de los investigadores, un valor normal Domain Users La cuenta podría crear una cuenta de computadora con la configuración predeterminada. ms-DS-MachineAccountQuota valor de 10 o reutilizar uno que ya controlaba.

La cadena también requería una CA empresarial que siguiera la ruta de la cadena vulnerable, inscripción a través de la plantilla de máquina predeterminada y accesibilidad de la red desde la CA hasta los oyentes SMB y LDAP del atacante.

Las organizaciones que ejecutan una CA empresarial deben instalar las actualizaciones de Microsoft del 14 de julio en los hosts de AD CS. Hasta el 24 de julio, ninguna fuente primaria revisada por The Hacker News informó sobre explotación en la naturaleza, pero la prueba de concepto completa era pública. Esa falta de presentación de informes no prueba que no se haya producido explotación.

Los investigadores también documentaron una forma probada en laboratorio de desactivar el recurso de persecución cuando no es posible aplicar parches de inmediato, aunque puede interrumpir los flujos de inscripción legítimos.

Ciberseguridad

El error se encuentra en un retroceso de inscripción de AD CS conocido como persecución. Cuando una autoridad de certificación (CA) no puede obtener la información de una entidad final, la Protocolo de inscripción de Windows permite que una solicitud proporcione cdcel servidor de Active Directory con el que contactar, y rmdel objeto de la máquina a resolver.

los investigadores encontró que la CA siguió la información proporcionada por el solicitante cdc host a través del Bloque de mensajes del servidor (SMB) y el Protocolo ligero de acceso a directorios (LDAP) sin demostrar primero que era un controlador de dominio real.

Un atacante podría ejecutar servicios LDAP y Autoridad de seguridad local (LSA) no autorizados, transmitir el desafío de autenticación de la CA al controlador de dominio real a través de Netlogony devolver el controlador de dominio de destino objectSid y dNSHostName. Una cuenta de máquina controlada proporcionó la identidad de dominio válida necesaria para que la CA continúe. La CA autenticó esa cuenta y luego firmó la identidad del controlador de dominio de destino en el certificado.

El explotación pública Automatiza la cadena. Crea una cuenta de computadora o reutiliza una especificada con --computer-name. La herramienta inicia oyentes en los puertos. 445 y 389 y transmite el desafío de la CA al controlador de dominio real a través de Netlogon. Luego presenta el cdc y rmd atributos y escribe un PFX caché de credenciales de archivos y Kerberos.

El exploit utiliza criptografía de clave pública para la autenticación inicial en Kerberos (PKINIT) para autenticarse como controlador de dominio de destino. La credencial resultante puede solicitar secretos de cuenta a través de DCSyncincluido krbtgt.

El análisis binario de los investigadores encontró que Microsoft Actualización de julio agrega CRequestInstance::_ValidateChaseTargetIsDC a certpdef.dll antes de que el CA siga una persecución. La validación rechaza literales de IP, nombres demasiado largos y metacaracteres LDAP. También requiere exactamente un objeto de computadora de Active Directory coincidente cuyo nombre DNS coincida con el objetivo y cuyo userAccountControl incluye SERVER_TRUST_ACCOUNT (8192). un mas tarde SID la comparación bloquea la sustitución de objetos.

Ciberseguridad

El exploit público se probó en un bosque de Windows Server 2016 o posterior con una CA empresarial, la plantilla de certificado de máquina predeterminada y la cuota de cuenta de máquina predeterminada. El registro NVD enumera por separado desde Windows Server 2012 hasta Windows Server 2025, incluidas las ediciones Server Core enumeradas, como afectadas. También enumera las versiones 1607 y 1809 de Windows 10. La falla estaba ausente en Catálogo de vulnerabilidades explotadas conocidas de CISA el 24 de julio.

Los investigadores informaron la falla a Microsoft el 14 de mayo. Microsoft la confirmó el 22 de mayo y la parchó el 14 de julio. Los investigadores la revelaron públicamente el 24 de julio. Los administradores que no puedan parchear inmediatamente pueden borrar el indicador de persecución y reiniciar los Servicios de Certificate Server:

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC

Restart-Service CertSvc -Force

Los investigadores probaron esa mitigación sólo en un laboratorio controlado. Recomiendan prepararlo primero y tratar la actualización de julio como una solución permanente.

La cadena de vulnerabilidad LiteLLM permite a usuarios con pocos privilegios hacerse cargo de servidores de puerta de enlace AI – CYBERDEFENSA.MX

Una cuenta predeterminada con bajos privilegios en un proxy LiteLLM puede ascender a administrador completo y ejecutar código en el servidor encadenando tres vulnerabilidades, revelaron investigadores de Obsidian Security.

LiteLLM es una puerta de enlace de IA de código abierto ampliamente implementada que gestiona llamadas a más de 100 proveedores de modelos detrás de una interfaz compatible con OpenAI.

Una toma de control del servidor expone cada clave de proveedor que posee, los secretos que descifran sus credenciales almacenadas y cada mensaje y respuesta que pasa a través de él.

Obsidian califica el CVSS de cadena completa con 9.9, en el rango Crítico. berriaiel mantenedor, incluyó el conjunto de correcciones completo en LiteLLM v1.83.14-stable, que GitHub enumera como lanzado el 2 de mayo. Actualice a esa versión o posterior para cerrar la cadena de tres CVE.

los tres bichos

El primer enlace es CVE-2026-47101una omisión de autorización. Cuando un usuario normal (un usuario interno) genera una clave API virtual, LiteLLM almacena el campo de rutas permitidas proporcionado por la persona que llama sin compararlo con la función del usuario.

Se supone que el campo limita lo que puede hacer una clave. En cambio, el proxy también lo trata como una concesión alternativa, por lo que alguien que no sea administrador puede crear una clave con Allow_routes: [«/*»]un comodín que llega a todas las rutas, incluidas las exclusivas para administradores. La misma escritura no verificada aparece en los otros puntos finales de administración de claves, razón por la cual la solución requirió tres solicitudes de extracción para llegar.

Una vez pasada la puerta de ruta, los manejadores detrás de ella se vuelven accesibles. Varios de ellos suponen que la puerta ya ha pasado el control, lo que abre dos caminos.

uno es CVE-2026-47102escalada de privilegios. El punto final /user/update permite al usuario editar su propio registro, pero no restringe qué campos puede escribir. Se acepta y guarda una actualización automática con user_role: «proxy_admin», lo que promueve a la persona que llama a administrador de proxy completo. Un org_admin puede llegar a este punto final a través de una ruta de código legítima y prevista sin necesidad de omitirla; un usuario interno predeterminado lo alcanza después de CVE-2026-47101.

Ciberseguridad

VulnCheck, que asignó el CVE, le otorga una puntuación de 8,7 en CVSS 4.0 y 8,8 en 3.1.

El otro es CVE-2026-40217un escape de espacio aislado en Custom Code Guardrail, que compila y ejecuta Python proporcionado por el administrador. Los puntos finales de producción ejecutaron el código a través de exec() sin filtrado a nivel de fuente. Cuando exec() obtiene un dictado global sin __builtins__, Python inyecta silenciosamente el módulo integrado completo, que entrega el código __import__, open y eval. Una carga útil simple que llamara a os.system fue suficiente para un shell inverso.

Una ruta separada en el punto final del área de juegos /guardrails/test_custom_code, encontrada de forma independiente por X41 D-Secderrotó una lista de denegación de expresiones regulares mediante la reescritura del código de bytes en tiempo de ejecución. Ambos terminaron en la ejecución de código del lado del servidor.

Lo que obtiene un atacante

LiteLLM se encuentra en un cuello de botella, por lo que el alcance es amplio. Una cadena completa expone la clave maestra, la clave salt que descifra las credenciales almacenadas y la URL de la base de datos. También expone todas las claves de proveedor configuradas, para OpenAI, Anthropic, Gemini, Bedrock, Azure y el resto.

Las claves en la configuración o el entorno son texto sin formato; Las claves de la base de datos están cifradas pero se pueden recuperar con la clave salt. Todo lo que se envía a través de la puerta de enlace, indicaciones y respuestas, se vuelve legible, que en implementaciones reales es donde terminan la PII, el código fuente, los tickets internos y los secretos pegados.

Si el proxy también se ejecuta como protocolo de contexto modelo (MCP) o puerta de enlace de agente, los tokens de OAuth y las credenciales de herramientas también están dentro del alcance.

El mayor riesgo no es lo que lee un atacante sino lo que puede reescribir. La puerta de enlace se encuentra en el cable entre un agente de IA y el modelo, por lo que un compromiso le permite alterar las respuestas en tránsito.

Obsidiana demostrada esto contra Claude Code enrutado a través de un proxy comprometido. Esta no es una inyección inmediata. En lugar de persuadir al modelo para que se comporte mal, el atacante utiliza el mecanismo de devolución de llamada integrado de LiteLLM, un punto de extensión que se activa con cada solicitud y nunca aparece en la interfaz de usuario del administrador. La devolución de llamada intercambia la respuesta del modelo por una llamada de herramienta falsificada y reescribe el contexto de verificación de seguridad para que la acción se lea como aprobada.

En la demostración, el desarrollador escribe una palabra, hola, y el atacante abre un shell inverso en la máquina del desarrollador.

Separado de la cadena, LiteLLM le entrega a proxy_admin una ruta de ejecución de código intencional: su soporte MCP le permite a un administrador registrar servidores stdio MCP que el proxy inicia como subprocesos locales. Se trata de una compensación de diseño más que de un error, y los parches no lo cambian, por lo que llegar al administrador es efectivamente llegar a la ejecución del código.

Obsidian reprodujo un caparazón inverso de esta manera en v1.88.0. Un error genuino en la misma maquinaria stdio-MCP, CVE-2026-42271, permite a las personas que llaman generar subprocesos a través de los puntos finales de vista previa de MCP de LiteLLM; fue explotado en estado salvaje y agregado al catálogo KEV de CISA a principios de este mes.

Ciberseguridad

Nada de esto es el primer momento difícil para LiteLLM este año. En marzo, un compromiso de la cadena de suministro bloqueó dos versiones de LiteLLM en PyPI y, en abril, se aprovechó una inyección SQL crítica dentro de las 36 horas posteriores a la divulgación.

Obsidian enmarca la cadena aquí como una falla revelada con una demostración funcional, no como una explotación vista en la naturaleza, pero la posición del proxy sigue convirtiéndola en un objetivo.

que hacer

Actualice a v1.83.14 estable o posterior, la primera versión con el conjunto completo de correcciones. Luego audite. Vuelva a verificar cada cuenta que tenga proxy_admin y trate esa función como acceso a nivel de host. Revise cada medida de seguridad de código personalizado en el proxy.

Verifique las devoluciones de llamada cargadas desde config.yaml en litellm_settings.callbacks, ya que nunca aparecen en la consola y son exactamente donde se escondería un atacante posterior a RCE. Verifique la integridad del código implementado, no solo la configuración. Si se sospecha una exposición, rote las claves del proveedor, las credenciales de la base de datos y los tokens MCP almacenados.

Un proxy comprometido no sólo filtra datos. Se sitúa entre el agente y el modelo y puede forjar las respuestas sobre las que actúa el agente. La cadena que lleva a un atacante allí tiene una confianza fuera de lugar en cada capa: la puerta de ruta confiaba en el campo proporcionado por la persona que llama, los controladores confiaban en la puerta de ruta y nadie realmente comprobó.