Cuando se trata de resolver errores de software, analizar muestras de malware o descubrir configuraciones incorrectas de seguridad, el Sysinternals Suite probablemente pueda resolver tu problema. Para muchos profesionales de TI y seguridad, esta colección de utilidades de Windows es como una navaja suiza.
- ¿Necesitas un administrador de tareas con esteroides? Process Explorer te cubre.
- ¿Quieres ejecutar un proceso en un equipo remoto? Revisa PsExec.
- ¿Hay un archivo sensible que quieras eliminar? SDelete al rescate.
Pero, ¿qué pasa cuando el software que necesitas resolver es el propio SysInternals Suite? Eso es exactamente lo que pasó durante una investigación reciente de una brecha de seguridad.
Process Monitor (Procmon) es una de las utilidades más populares de SysInternals, que ofrece a los usuarios una interfaz simple para auditar procesos, archivos y actividad de red con un nivel de detalle extremadamente granular. Por dentro, usa un driver para recopilar eventos de interés. Lamentablemente, Procmon v3.32 no pudo cargar su driver en el equipo con Windows 7 de 64 bits que estábamos analizando.
Curiosamente, la misma versión de Procmon había funcionado sin problemas en un equipo con Windows 7 de 32 bits ese mismo día. Considerando el mensaje de error anterior y el comportamiento distinto entre arquitecturas, nuestro equipo sospechó que había un problema de firma de drivers.
Desde Windows Vista/Server 2008, Microsoft agregó Driver Signing Enforcement a sus sistemas operativos de 64 bits para combatir el aumento de drivers maliciosos (rootkits). Esto hace (un poco) más difícil para los atacantes insertar puertas traseras en drivers legítimos y cargar código personalizado en el kernel. Con esto en mente, decidimos buscar pistas adicionales en los registros de eventos de Windows.
Según la captura anterior, pudimos ver claramente que Windows se negó a cargar el driver de Procmon por problemas de "integridad de código". Esta información coincidía con las quejas de usuarios en el foro de SysInternals:
- https://forum.sysinternals.com/driver-verifier-violation-in-latest-procmon_topic32681.html
- https://forum.sysinternals.com/procmon-v332-fails-on-x64-win7_topic32654.html
¿Entonces Procmon tenía una puerta trasera? ¿Se le olvidó a Mark firmar el driver? ¿O había algo más en la raíz del problema? Una forma sencilla de averiguarlo es examinar la firma digital del driver extraído. Según los registros de eventos, el archivo sospechoso estaba ubicado en:
\Device\HarddiskVolume1\Windows\System32\drivers\PROCMON23.SYS
Este volumen estaba asignado a la unidad C:. Sin embargo, el archivo PROCMON23.SYS no se encontraba dentro del directorio "drivers".
En lugar de rendirnos, decidimos investigar el archivo procmon.exe. Procmon normalmente se distribuye como un único ejecutable de 32 bits que determina la arquitectura del sistema operativo y ejecuta la versión correspondiente de sí mismo. Si el sistema operativo es de 64 bits, se extrae una versión de 64 bits de Procmon desde los recursos del EXE de 32 bits y se coloca en "%TEMP%\Procmon64.exe" como archivo oculto.
Cuando se ejecuta Procmon64.exe, extrae una copia del driver problemático desde sus propios recursos PE hacia el directorio %SYSTEMROOT%\System32\drivers. Lamentablemente, PROCMON23.SYS no estaba ahí para examinarlo (probablemente se eliminó cuando el driver no pudo cargarse). Desde aquí, podíamos adjuntar un depurador a Procmon64.exe e ir avanzando paso a paso hasta que se soltara el driver, o podíamos tomar el camino fácil y extraer el driver con un editor de recursos. Elegimos el camino más rápido hacia la victoria y usamos Resource Hacker.
Como se ve en la captura anterior, Resource Hacker permite navegar fácilmente los recursos dentro de Procmon64.exe. BINRES nos llamó la atención, ya que probablemente significaba Binary Resource y contenía un archivo PE llamado RCDRIVERNT. Con estos indicios, estábamos seguros de que era nuestro sospechoso. Para extraer el driver, hicimos clic derecho en el recurso y elegimos guardar el archivo como Procmon332Driver.sys. Para inspeccionar el archivo extraído, hicimos clic derecho sobre él, elegimos "Propiedades" en el menú contextual y seleccionamos la pestaña "Detalles".
¡Eureka! Recuperamos el driver incluido con Procmon v3.32. Para validar la firma digital de nuestro driver, usamos Sigcheck de SysInternals.
Los resultados sugerían que el driver de Procmon v3.32 no podía verificarse completamente hasta la autoridad raíz confiable del certificado en este equipo con Windows 7 de 64 bits. Para apoyar nuestra comparación, repetimos el mismo proceso de extracción de driver en Procmon v3.31. Con ambos drivers en mano, inspeccionamos las firmas digitales usadas para firmar cada driver de 64 bits.
Claramente, algo andaba mal con los certificados raíz confiables de este equipo con Windows 7. Lamentablemente, no podíamos arriesgarnos a afectar la integridad forense del sistema para llegar al fondo del problema mientras estábamos en el sitio.
De vuelta en el laboratorio
Después de limpiar los sistemas de nuestro socio, no pudimos evitar preguntarnos qué pasaba por dentro con Procmon. Para reproducir el estado del sistema infectado, creamos una VM con Windows 7 de 64 bits con SP1 y la llevamos al mismo nivel de parches que el sistema original. ¡Por suerte, el problema se reprodujo!
Desde ahí probamos varias cosas, incluyendo confiar manualmente en certificados e instalar parches para actualizar los certificados raíz confiables. Ya casi nos quedábamos sin ideas hasta que recordamos las actualizaciones de Microsoft que agregaron soporte para la firma de certificados SHA-2 (en preparación para las probables vulnerabilidades de SHA-1).
Después de instalar KB3033929, la ruta de certificación del driver extraído dejó de fallar en la validación. 😃
¡Así de simple, los problemas con el driver se resolvieron y Procmon volvió a funcionar!
Notas finales
Esperamos que hayas disfrutado este blog y que hayas aprendido algo con él. Si quieres ver más guías paso a paso, cuéntanos compartiéndolo. Si tienes alguna pregunta, no dudes en escribirnos en Twitter a través de @HuntressLabs.
