No es Genjutsu, es un Network Provider DLL

Escrito por Paolo Urbina Acuña

Tabla de contenidos

1. Tabla de contenidos
2. Inicio de la Aventura
3. Proveedores de Red, Nada que ver con los ISP
4. Técnica MITRE
5. Cadena de infección
6. La Herramienta PSBits
7. Simulación de Ataque
8. Operación Fantasma
9. Búsqueda de Eventos
10. Conclusiones
11. Referencias

Inicio de la Aventura

El equipo Falcon OverWatch de CrowdStrike en el reporte “2023 Threat Hunting Report” descubrió en el análisis de una intrusión, una nueva sub-técnica que no estaba registrada en el framework MITRE ATT&CK, la cual denominaron como “Network Provider DLL” bajo la técnica “Modify Authentication Process”. Ante este hecho, Falcon OverWatch recomendó la creación de esta subtécnica y MITRE la incluyó en la ATT&CK v13 bajo el ID T1556.008¹.

Proveedores de Red, Nada que ver con los ISP

Para tener un poco de contexto, ¿Qué es un Network Provider o Proveedor de red?

Un proveedor de red es un archivo DLL del sistema operativo Windows, que admite un protocolo de red específico implementado mediante la API del proveedor de red (NPAPI). Esta API permite ejecutar acciones dentro del sistema como, por ejemplo, examinar los recursos de red dentro de una máquina, solicitar usuarios asociados a una conexión o actuar como un administrador de credenciales.

Cuando un proveedor de red es configurado como un administrador de credenciales, recibe una notificación cada vez que ocurre un evento de autenticación de Windows, como un inicio de sesión o cambio de contraseña. Dentro de este procedimiento, Winlogon llama a los enrutadores de varios proveedores (MPR)² para enviar el estado de esta autenticación a los administradores de credenciales.

La autenticación de inicio de sesión es validada mediante LSA (Local Security Access). Esto ocurre ya que la función NPLogonNotify(), perteneciente a la API, puede ser implementada en el administrador de credenciales para recibir la información mediante la estructura MSV1_0_INTERACTIVE_LOGON, que almacena la autenticación del inicio de sesión para enviar un estado de comprobación a la base de datos SAM (Security Access Manager) y validar si las credenciales entregadas durante este evento se encuentran registradas.

En resumen, un proveedor de red configurado como administrador de credenciales recibe la autenticación de los inicios de sesión de Windows, dando justificación ante el uso de este componente para realizar la técnica identificada en esta actividad y ejecutarla para fines maliciosos.

Técnica MITRE

T1556.008 – Modify Authentication Process: Network Provider DLL, según MITRE ATT&CK, es una técnica que aprovecha el proceso de autenticación de Winlogon en Windows para capturar credenciales sin cifrar mediante el servicio mpnotify.exe.

El vector de ataque consiste en registrar una DLL de proveedor de red malicioso como administrador de credenciales con el fin de que, cada vez que exista un evento de inicio de sesión producido mediante una autenticación en la interfaz de Winlogon, Mpnotify.exe notifique a la DLL del proveedor de red las credenciales registradas y almacenadas en un archivo de texto plano. En la siguiente imagen, se muestra una representación de la actividad descrita.

Cadena de infección

1. El usuario ingresa sus credenciales a la interfaz de autenticación de la máquina objetivo.
2. Estas credenciales son enviadas a Winlogon.exe para almacenar el inicio de sesión.
3. Mediante un canal RPC, Winlogon.exe envía las credenciales a mpnotify.exe para que notifique el evento de inicio de sesión a los proveedores de red.
4. En este punto, el atacante inyecta la DLL maliciosa en el directorio raíz C:\Windows\System32. Luego, se ejecuta un script de powershell para registrar el proveedor de red malicioso en el sistema.
5. La DLL configurada es asignada al proveedor de red previamente registrada por el atacante.
6. Al recibir el evento de inicio de sesión, la DLL genera un archivo de texto sin cifrar con las credenciales del usuario en texto plano.

La Herramienta PSBits

Los métodos descritos en la subtécnica pueden ser realizados por la herramienta PSBits, desarrollada por Grzegorz Tworek, que permite utilizar diferentes scripts y binarios para realizar pruebas ofensivas con el fin de comprender el funcionamiento de estos a nivel de código. Actualmente, se encuentra disponible en la plataforma Github³.

Dentro de esta herramienta, se encuentra NPPSpy, el cual contiene todos los componentes necesarios para replicar la técnica que queremos ejecutar.

NPPSpy po’ Papito

NPPSpy es un conjunto de scripts perteneciente a la herramienta PSBits como se muestra en la imagen 5.1.1, que entrega los componentes necesarios para configurar un proveedor de red como administrador de credenciales junto con la DLL maliciosa.

1. ConfigureRegistrySettings.ps1: Script de powershell que registra el proveedor de red en la máquina.
2. Get-NetworkProviders.ps1: Script de powershell que enumera los proveedores de red registrados en la máquina.
3. NPPSpy.c: Código fuente utilizado en el archivo dll malicioso.
4. NPPSpy.dll:DLL maliciosa que se asigna al proveedor de red previamente registrado.

Destripando a la Bestia NPPSpy.c

La función NPGetCaps() perteneciente a NPAPI de Windows es implementada en el proveedor de red y permite entregar al sistema operativo la naturaleza y las funciones que posee el proveedor. Este, en otras palabras, sería el corazón de un proveedor de red.

La función NPLogonNotify() también perteneciente a NPAPI, que permite notificar a los administradores de credenciales sobre los eventos de inicios de sesión y el tipo de autenticación que está recibiendo. Este posee una sintaxis definida con diferentes parámetros. En este caso, nos interesa el método lpAuthInfo.

lpAuthInfo recibe el tipo de autenticación proveniente del inicio de sesión de Windows, apuntando a dos opciones de autenticacione, pueden ser MSV1_0_INTERACTIVE_LOGON o KERB_INTERACTIVE_LOGON; parte de la investigación fue realizada en un entorno local, por lo que el autenticador es MSV1_0_INTERACTIVE_LOGON.

La magia ocurre en la función SavePassword(). Esta función recibe como parámetros las credenciales del usuario que ha iniciado sesión en la máquina mediante el método lpAuthInfo, adquiridos desde MS1V_0_INTERACTIVE_LOGON, que luego son declarados en las variables UserName y Password.

La función SavePassword() viene con los parámetros username y password, que pasan a poseer información una vez que NPLogonNotify realiza el barrido de su código y obtener las credenciales del inicio de sesión. Luego, con la función CreateFile, perteneciente a la API de Windows, permite crear un archivo.

Simulación de Ataque

El escenario de pruebas para replicar esta actividad fue realizado mediante un entorno virtual controlado (VirtualBox) con el sistema operativo Windows 10, junto con la herramienta NPPSpy.

Condiciones para el uso de la Técnica

Se deben dar las siguientes condiciones para utilizar el conjunto de scripts dentro de la máquina:

1. Se necesita elevación de privilegios para registrar el proveedor de red mediante powershell y la inyección de la DLL maliciosa en el directorio raíz C:\Windows\System32.
2. Deshabilitar el antivirus de la máquina (en este caso, Windows Defender) para utilizar la DLL maliciosa ya que al momento de que la dll pisa el sistema, el antivirus lo detecta como se muestran en la imagen.

Desarrollo del Gameshark

El primer paso es copiar nuestra dll maliciosa al directorio raíz C:\Windows\System32. Se requiere permisos de administrador para colocar el archivo como se observa en la imagen 5.1.

En la imagen que sigue, se observa en la consola de powershell la ejecución del script Get-NetworkProviders.ps1 que entrega los detalles de los proveedores de red existentes en el sistema. Por defecto, en la máquina de pruebas con el sistema operativo Windows 10 vienen incorporado los proveedores LanmanWorkstation, RDPNP, Webclient y VboxSF (incorporado junto con VirtualBox).

El script ConfigureRegistrySettings.ps1 permite añadir el nuevo proveedor de red como servicio al registro de Windows. Para este caso, el nuevo proveedor de red será Washuleru.

Se vuelve a ejecutar el primer script para verificar el registro del nuevo proveedor. Como se ve en la siguiente imagen, el proveedor de red Washuleru se encuentra en el registro, asignado con el archivo WashuleruSpy.dll en el directorio raíz.

Luego de implementar todo lo necesario, reiniciamos la máquina e ingresamos las credenciales en la interfaz de autenticación. Para este caso, fue utilizado la cuenta de usuario JJHarry con la contraseña 31minutos.

Al iniciar sesión, nos dirigiremos al directorio raíz C:\ donde fue generado el archivo de texto “NPPSpy.txt”. Podemos observar en la imagen siguiente que las credenciales utilizadas para entrar a la máquina han sido almacenadas en texto plano sin cifrar la información.

La prueba del gameshark da el conocimiento del método y demuestra paso a paso como implementar la técnica desarrollada por el investigador, pero ¿qué pasa si realizamos algunos ajustes?

Parte de la herramienta diseñada por Tworek otorga libre acceso para que los analistas puedan ejecutar esta técnica en entornos de pentesting. Dado este caso, desarrollé el mismo ataque, modificando la generación del archivo de texto en otra ubicación del sistema, junto con una nueva DLL y un script HTML para exfiltrar la información obtenida en el .TXT hacia un formulario de Google.

Operación Fantasma

En SavePassword(), modificamos la salida del archivo de texto hacia el directorio público (C:\Users\Public).

Ocupando el servicio x64 Native Tools Command Prompt for VS 2019 (disponible con la descarga de Visual Studio), ubicamos el directorio que aloja el código (NPWashuleru.c) y ejecutamos la línea de comando:

cl.exe /LD NPWashuleru.c

Esto genera el archivo NPWashuleru.dll, distinta a la entregada por el autor de NPPSpy e indetectable por el AV.

Se desarrolla un script de PowerShell llamado GhostProvider.ps1, que realiza el montaje completo de la técnica, sin la necesidad de realizar configuraciones previas para la prueba.

Adicionalmente, fue desarrollado un script HTML anidado con código JavaScript, para recibir un archivo de texto desde el navegador. Este utiliza la API de Google Forms para configurar la entrega del archivo de texto con las credenciales mediante un formulario, proporcionando el ID del campo como la pregunta y la información del archivo como respuesta.

Con fetch(), se declara el enlace del formulario con su ID correspondiente (ID_FORM) y, por método POST, se exfiltra la información al documento.

Al realizar estas configuraciones previas, tenemos una versión del gameshark diferente que omite ciertas condiciones del escenario de ataque, con los siguientes artefactos:

Reiteramos el inicio de sesión, pero con distintas credenciales. En este caso, utilizaremos el usuario puaterasu con password sharingan.

Al ejecutar el script de Powershell, la DLL se transfiere al directorio público C:\Users\Public. Se observa que, al colocar la DLL en el sistema, el AV no lo detecta como malicioso.

También verificamos los proveedores registrados en el sistema con el registro de Windows, ejecutando la línea de comando:

reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

Este puede ser ejecutado en una consola cmd o bien en una consola Powershell:

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

Luego, reiniciamos la máquina e iniciamos sesión nuevamente. Podemos ver que encontramos el archivo de texto creado en el directorio configurado en la DLL (C:\Users\Public).

Al abrir Ups_WashuleruSpy.txt, vemos que las credenciales se capturan exitosamente, después del inicio de sesión.

Con el ataque realizado, se exfiltra la información con el archivo leerDataTxt.html. Se examina desde el navegador para elegir el archivo de texto.

Una vez elegido, se observa el contenido del archivo para verificar si la información fue entregada correctamente.

Desde el formulario, vemos que las credenciales fueron obtenidas por el adversario, enviadas desde la máquina infectada (entorno de pruebas).

Búsqueda de Eventos

Al observar el registro de eventos de Sysmon, se encuentra solo el evento 11, el cual indica que se ha creado el archivo Ups_WashuleruSpu.txt (FileCreate) por el servicio mpnotify.exe a nivel de SYSTEM.

Conclusiones

Existen distintas técnicas y herramientas que abusan de la directiva LSASS y SAM para extraer credenciales, sobre todo los hashes de contraseñas como Mimikatz, Impacket, LaZagne, etc. Este tipo de actividades ha llevado a los ambientes de seguridad a desarrollar contramedidas de estas.

El nuevo método que ofrece la técnica T1556.008 no necesita dumpear procesos que gestiona credenciales, si no que utiliza procesos legítimos de Windows para no causar ruido en el sistema. El uso de una DLL para configurar un proveedor de red malicioso sugiere un método de persistencia para que “escuche” los inicios de sesión del usuario en la máquina.

Es interesante como un proceso como mpnotify.exe tiene las capacidades de recibir las credenciales por parte de Winlogon y notificar a los administradores de red sobre los eventos de autenticación. Si vemos el evento de Sysmon, se aprecia que este proceso legítimo utiliza altos privilegios para crear un archivo con credenciales en texto plano, siendo un evento de alta criticidad ya que también, evade los controles de defensa del AV (Windows Defender) y da el paso a la exfiltración gracias a las funcionalidades que entrega la API de Google Forms para obtener información por un script de JavaScript.

Sin embargo, hay que prestar atención a la manipulación de los registro de NetworkProvider. Con los scripts de Powershell, se observa que existen proveedores por defecto en el sistema, por lo que la creación de uno de estos puede ser sinónimo de actividad sospechosa. Sin embargo, para que esto suceda, el adversario debe lograr la elevación de privilegios ante el uso del registro de Windows.

Ante este hecho, debe tomarse en consideración los comandos reg.exe y Set-ItemProperty que estén realizando actividad en las siguientes ramas del registro, para monitorear los proveedores de red y descartar la escritura de uno malicioso:

• HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
• HKLM\SYSTEM\CurrentControlSet\Services\<nombre_provider>\NetworkProvider

Adicionalmente, los proveedores que traen por defecto Windows son los siguientes:

Versión sistema operativo	Proveedores de red
Windows 10	RDPNP, LanmanWorkstation, Webclient
Windows 11	RDPNP, P9NP, LanmanWorkstation, Webclient

Referencias

1. https://attack.mitre.org/techniques/T1556/008/ ↩︎
2. Componente de Windows que permite la comunicación entre el sistema operativo y los proveedores de red existentes en el sistema https://learn.microsoft.com/es-es/windows/win32/secauthn/multiple-provider-router ↩︎
3. https://github%5B.%5Dcom/gtworek/PSBits ↩︎