Mientras investigaba una intrusión, Huntress encontró algo bastante fascinante relacionado con la recolección adversaria de credenciales.
Los actores de amenazas suelen recolectar credenciales de forma retrospectiva, extrayendo lo que ya está en el sistema (como Mimikatz). Algunas herramientas, como Responder, le permiten al actor de amenazas escuchar en toda la red y capturar algunos hashes que circulan por el Active Directory.
Pero no es tan común que en Huntress veamos a actores de amenazas manipular un sistema de forma proactiva no solo para recolectar credenciales, sino para recolectar contraseñas en texto plano*. Normalmente, solo vemos este esfuerzo proactivo mediante la manipulación del registro UseLogonCredential.
Y sin embargo, mientras investigábamos una intrusión reciente, encontramos una técnica inusual para robar credenciales en texto plano.
Un actor de amenazas había obtenido acceso a una red compleja, permaneció oculto en rincones oscuros del entorno, y luego implementó la técnica de Grzegorz Tworek NPPSPY para hacer un 'ataque de intermediario' en el proceso de inicio de sesión del usuario, y guardar el nombre de usuario y la contraseña en un archivo discreto.
Parece que la comunidad ha documentado esta técnica NPPSPY en teoría, pero hasta ahora parece que nadie ha documentado haberla encontrado implementada de forma maliciosa en el mundo real.
En este artículo, veamos cuándo el equipo de Huntress se encontró con esta técnica en la vida real.
¿Qué hace NPPSPY?
Antes de entrar en los detalles de esta técnica, grabé un video corto de cómo funciona. En resumen: es posible interceptar el proceso de inicio de sesión como intermediario y guardar la contraseña de un usuario en texto plano en un archivo del sistema de archivos:
Estoy simplificando la técnica porque soy un simplón comparado con las notas de Grzegorz [1, 2] y la documentación de Microsoft. Muchos ya han escrito sobre esta técnica y la han incorporado a marcos de seguridad, como el conjunto de pruebas de Atomic Red, así que no me detendré demasiado en los detalles de esta explicación.
Cuando te sientas a iniciar sesión en tu máquina y escribes tu contraseña para autenticarte, se realizan muchas acciones distintas en segundo plano con tus credenciales: cálculo de resúmenes criptográficos, verificación, idas y vueltas hacia un controlador de dominio, etc.
La conversación entre Winlogon y Local Security Authority Subsystem Service (LSASS) es la más relevante para nuestro caso. Winlogon es tanto la interfaz gráfica que usamos para ingresar nuestras credenciales, como el socio conversacional de LSASS para permitirte iniciar sesión.
Es más difícil manipular a LSASS para intentar recolectar credenciales, así que la técnica NPPSPY toma el camino de menor resistencia enfocándose en Winlogon.
Cuando le das tu contraseña a Winlogon, este abre un canal (RPC) hacia mpnotify.exe y le envía la contraseña. Mpnotify entonces va y les informa a algunas DLL sobre esta credencial.
Aquí es donde NPPSPY cobra vida. A Mpnotify se le informa maliciosamente sobre un nuevo proveedor de red adversario a considerar. Este proveedor de red está controlado por el atacante y viene con una DLL con puerta trasera que el adversario ha creado. Esta DLL escurridiza simplemente escucha este intercambio de credenciales en texto plano desde Winlogon hacia mpnotify y luego lo guarda.
¿Qué encontramos en el mundo real?
Permíteme llevarte de vuelta al caso.
Durante esta intrusión, los padrinos de DFIR, Jamie Levy y Harlan Carvey, usaron su magia forense para guiar al equipo a encontrar y prestar atención a un 'C:\Windows\System32\lsass.dll'. Habían identificado que esto estaba asociado a una cuenta comprometida y nos aconsejaron ir a determinar de qué se trataba.
Ahora bien, todos somos buenos elementos en el equipo del SOC, y si un Gran Jefe da una orden, puedes apostar que la vamos a cumplir. Conseguimos la DLL, la diseccionamos, planteamos la hipótesis de que era NPPSPY y luego la implementamos en nuestro laboratorio local para verificar esta teoría.
Después de haber hecho pruebas localmente, analizamos el sistema comprometido. Muy satisfactoriamente, pudimos confirmar las técnicas exactas que había usado el actor de amenazas.
- El proveedor de red en este caso se llamaba logincontroll (el error tipográfico es intencional)
- Ocupaba HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order y creó el valor logincontrol
- Y luego apuntó logincontroll con la ruta C:\Windows\System32\lsass.dll en el registro HKLM\SYSTEM\CurrentControlSet\Services\logincontroll\NetworkProvider
A continuación, se muestran capturas de pantalla del sistema comprometido:
En nuestro laboratorio y luego en el equipo comprometido, identificamos que C:\Windows\Temp\tmpCQOF.tmp era el archivo codificado de forma fija que el actor de amenazas había designado para escuchar y registrar las credenciales como Username -> Password:
Ahora bien, no puedo mostrarte lo que había en ese archivo en el sistema comprometido, solo lo que recreamos en nuestro entorno de pruebas. Pero créeme, ver un montón de nombres de usuario y contraseñas en texto plano fue IMPRESIONANTE.
Rarezas pendientes
Sabes, algo que siempre resulta interesante en las investigaciones es que, incluso cuando llegas a una conclusión, siempre queda un hilo suelto, esperando a que lo jales, lo desenredes y te pierdas aún más en el asunto.
Identificamos esta técnica en un servidor Exchange comprometido.
¿Recuerdas C:\Windows\Temp\tmpCQOF.tmp, el archivo que llevaba un registro de las credenciales en texto plano? La evidencia sugería que las direcciones de correo electrónico y sus respectivas contraseñas en texto plano terminaron en el volcado.
Así quedé yo al darme cuenta de esto. Ahora bien, teniendo en cuenta que solo soy un simple mono tití sin cerebro, me confundo con facilidad. ¿Cómo terminó el poner una puerta trasera en el proceso de inicio de sesión local recopilando las direcciones de correo y contraseñas de los usuarios que se autenticaban para revisar sus correos, en esta máquina Exchange?
Para tratar de entender lo que mostraba la evidencia, buscamos el consejo del líder técnico de investigación de Huntress y líder del Consejo de los Sabios, Dave Kleinatland 🧙.
Dave coincidió en que era extraño, pero sugirió
Las autenticaciones relacionadas con Exchange SÍ pueden quedar atrapadas en la red de NPPSPY para capturar credenciales en texto plano en tránsito... Si estás capturando credenciales en una máquina Exchange, vas por buen camino.
Esto sugiere que, para NPPSPY, existen beneficios poco documentados al apuntar a servidores específicos dentro de un Active Directory. Vimos la evidencia de primera mano: atacar una máquina Exchange también recopiló las credenciales en texto plano de usuarios que solo intentaban acceder a sus correos.
Investigar y defender
Una preocupación que tuvimos al armar este blog es que, al poner el foco en una técnica de seguridad ofensiva interesante y poco utilizada, Huntress sería en parte responsable de un aumento en su uso en el futuro cercano.
Por eso, quisimos dedicar algo de tiempo a cómo los defensores pueden investigar y detectar esto.
Para mis colegas del equipo rojo, algunos lugares indican cómo implementar NPPSPY. El DLL predeterminado que Grzegorz amablemente proporciona será marcado por Defender, pero la amabilidad de Grzegorz no tiene límites, y él proporciona el código C para que lo compiles tú mismo.
Revisión de sistemas en vivo
Grzegorz proporciona este script para examinar los Network Providers y las rutas de los archivos DLL asociados.
Desde el punto de vista del registro, es un 'servicio', pero no es realmente un servicio y, por lo tanto, no puede detectarse como tal. En la captura de pantalla a continuación, puedes ver la comparación de NPPSPY con los otros legítimos: 'logincontroll' tiene relativamente pocas firmas, números de versión o descripciones. Pero se considera trivial para los actores de amenazas agregar muchos de estos, así que no te bases en su ausencia para la detección.
Análisis forense
Como muchas cosas en seguridad de la información, Harlan parece haber cubierto ya todas las bases, sin importar cuán novedosa sea la técnica.
Al aprovechar el complemento de servicios para RegRipper v3.0, veremos el nombre de servicio muy sospechoso que ya hemos identificado con la implementación de NPPSPY de nuestro actor de amenazas.
Monitoreo y detección
El nombre del archivo que registra las credenciales en texto claro está fijado directamente en el código fuente y, por lo tanto, no tenemos oportunidades de detección aquí.
Aunque la documentación de NPPSPY recomienda colocar el DLL en C:\windows\System32, no es obligatorio. El siguiente ejemplo demuestra cómo un adversario puede colocar el DLL requerido en cualquier directorio, como C:\windows\temp. Por lo tanto, no tenemos oportunidades de detección aquí para ningún directorio requerido.
Esta técnica de NPPSPY es ruidosa. Y detectarla es posible con varias herramientas de monitoreo de seguridad que vigilan los procesos y comandos que se ejecutan en una máquina. Podrías usar Sysmon como opción gratuita. En Huntress, contamos con nuestro listener de Process Insights, que facilita el seguimiento del linaje de procesos padre-hijo.
Hay varias oportunidades de detección para NPPSPY, ya que los adversarios tienen que
- Ser un usuario privilegiado
- Crear y manipular varias entradas del registro
- Llevar un DLL al disco
- Y luego escribir credenciales en texto claro en un archivo en algún lugar
Elastic tiene una consulta de regla para este tipo de manipulación del proveedor de red. Le asignan una severidad media... personalmente, yo le asignaría a este tipo de actividad una criticidad súper nuclear... pero esa es solo mi opinión.
IOC y comportamiento
- OS Credential Dumping - ATT&CK T1003
- Valores bajo HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
- En nuestro caso: logincontroll
- Entradas sin explicación en HKLM\SYSTEM\CurrentControlSet\Services\<here>\NetworkProvider
- En nuestro caso: logincontroll
- DLL sin explicación en carpetas (muy difícil de detectar)
- En nuestro caso: C:\windows\system32\lsass.dll
- Archivos en los que se escribe continuamente (en mi opinión, básicamente imposible de detectar)
- En nuestro caso: C:\Windows\Temp\tmpCQOF.tmp
Remediación
Para remediar y erradicar esta maldad, hicimos pruebas furiosas con nuestras instantáneas de máquinas virtuales.
- Eliminar solo C:\windows\system32\<attacker.dll> detiene la escritura en el archivo de credenciales
- Eliminar solo la clave HKLM:\SYSTEM\CurrentControlSet\Services\<Attacker provider name>\NetworkProvider detiene la escritura en el archivo de credenciales
Por lo tanto, eliminar tanto el DLL controlado por el atacante como la entrada del registro detendrá sin duda la actividad de recolección de credenciales en texto claro.
A continuación hay un extracto del informe que recibió el socio de nuestra parte, que permitió remediaciones automáticas con un solo clic para deshacer el enredo en que NPPSPY había puesto a la máquina.
Entonces, ¿ganaron los malos actores?
Algunos podrían culpar a los investigadores de seguridad en estos casos. Es fácil suponer que, porque crean técnicas y comparten pruebas de concepto, son la raíz del mal en el ecosistema cibercriminal.
Esto no podría estar más lejos de la verdad. El problema no es la investigación en seguridad ofensiva. El problema son los cibercriminales.
Si bien esta técnica fue ideada por un investigador de seguridad, el actor de amenazas podría haber aprovechado toda una variedad de otras técnicas maliciosas para lograr sus objetivos; esta fue solo una de ellas, aunque bastante intensa.
La investigación en seguridad ofensiva nos ayuda a los defensores a mantenernos alerta, y nos motiva a mejorar constantemente nuestro oficio. Esos atacantes entraron de alguna manera, y siempre hay lecciones por aprender sobre cómo fortalecer las defensas e imponer un costo a los adversarios idiotas.
Técnicas como NPPSPY probablemente ya se han usado en el mundo real antes. Por lo que podemos ver, Huntress parece ser el primero en compartir y documentar su uso real por parte de actores de amenazas. Las herramientas ofensivas no permanecen elusivas ni misteriosas por mucho tiempo una vez que la comunidad defensiva les presta atención.
Esperamos que este artículo sea una pequeña contribución que ayude a la comunidad a defenderse y a crear mejores defensas.
• • •
Anexo: texto claro vs. texto plano
*Consulté documentos de NIST para concluir qué es NPPSPY. Una idea general es que el texto claro significa texto sin cifrar, mientras que el texto plano es el texto que forma parte de un intercambio criptográfico más complejo.
Por supuesto, si una contraseña está a punto de ingresarse en una autenticación criptográfica, como ocurre en un inicio de sesión de Windows, ¿no la convertiría eso en texto plano? Potencialmente. Pero NPPSPY parece ocurrir antes de que la criptografía realmente entre en juego, por lo que parece más apropiado inclinarse hacia el lado del texto claro.
Si alguien tiene una opinión firme al respecto, por favor escríbeme a mí en Twitter.
