Detección de inyección reflexiva de DLL

En los últimos años, los progtwigs maliciosos (y algunas herramientas de prueba de la pluma, como la carga útil del medidor de prueba de Metasploit) han comenzado a usar la inyección reflexiva de DLL (PDF) para cargar una DLL en la memoria de un proceso. El beneficio es que el archivo nunca se escribe en el disco y es difícil de detectar. Muchos ejemplos que he visto se basan en el trabajo de Joachim Bauch .

Sin embargo, en DEF CON 20, Andrew King demostró que podía detectar los archivos DLL inyectados utilizando una inyección reflexiva de DLL . Su presentación se llamó ” Detección de inyección reflectiva “. Desafortunadamente, no ha liberado el código fuente (que ciertamente no tiene obligación de hacer).

ACTUALIZACIÓN : Aparentemente lo extrañé, pero Andrew hizo este trabajo de código abierto hace un par de años: https://github.com/aking1012/dc20

Además, una herramienta llamada ” Antimeter ” puede detectar el motor del medidor de metro cuando se carga con inyección de dll reflectante. De nuevo, de código cerrado.

Entiendo que la herramienta de Andrew King y el Antimeter están escritos en Python y usan pydbg / pydasm para enumerar la memoria de ejecutables en ejecución.

¿Alguien tiene algún código fuente general (en Python, C, Delphi o de otro tipo) que esté dispuesto a compartir y que demuestre cómo detectar la inyección reflexiva de DLL? Hay herramientas forenses de memoria que pueden analizar un volcado de memoria y encontrar esto, pero estoy buscando ejecutar una aplicación en un sistema en ejecución (como hace antimeter) y encontrar procesos con DLL inyectados de manera reflectiva.

Si está interesado en comprender cómo funciona la inyección reflexiva de DLL, hay un código de código abierto escrito en Delphi que muestra cómo hacerlo.

ACTUALIZACIÓN : probé y puedo inyectar archivos DLL sin derechos de administrador (y como usuario habitual), pero, por supuesto, como USUARIO solo puedo inyectar en procesos que se ejecutan con el mismo nivel de integridad (y en mi sesión) … pero eso Todavía cubre aplicaciones como el paquete Office, Internet Explorer, etc.

¿Qué hay de enganchar la API de VirtualProtect? Debido a que los archivos DLL que se cargan a sí mismos seguramente se ejecutarán en su rango de código de memoria. Esto se debe a que (como usted mencionó) ellos usan los derechos de acceso del Usuario, por lo que tienen que usar la API de espacio de usuario del proceso.

NTSYSAPI NTSTATUS NTAPI ZwProtectVirtualMemory( IN HANDLE ProcessHandle, IN PVOID * BaseAddress, IN SIZE_T * NumberOfBytesToProtect, IN ULONG NewAccessProtection, OUT PULONG OldAccessProtection ); 

Si lo conecta al comienzo de su progtwig, puede filtrar las llamadas de protección sospechosas (la que permite la ejecución del código). Luego, buscaría un encabezado de PE o similar en frente de las páginas solicitadas para saber que es un módulo que se puede cargar … nota: creo que no se requieren archivos DLL normales ya que LoadLibrary maneja esto dentro del espacio Kernel. ¿Correcto? TODO: verificar

Normalmente, el encabezado de PE está ubicado a 0x1000 (4096) bytes o una página delante del primer código ejecutable. Así que un enfoque MUY básico puede ser buscar la etiqueta “MZ”:

 char* pe = ((char*)BaseAddress) - 0x1000; if ((NewAccessProtection == PAGE_EXECUTE || ... ) & pe[0] == 'M' && pe[0] == 'Z') { // do checks here } 

Si necesita más información sobre la conexión de API, simplemente pregunte o lea toneladas de artículos en la red. Otro candidato para enganchar es: FlushInstructionCache (…). Pero creo que solo Blizzard está usando esto para los módulos anti cheat de Warden, ya que no hay razón en la architecture x86 para llamarlo.

… solo un pensamiento,

será