python - Detección de inyección reflectiva DLL

windows delphi

Question

En los últimos años, el malware (y algunas herramientas de prueba de pluma como la carga útil del medidor de Metasploit) han comenzado a usar la inyección reflectiva de DLL (PDF) para cargar un archivo 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 fue capaz de detectar las DLL inyectadas mediante inyección reflectiva DLL . Su presentación se llamó " Detección de inyección reflexiva ". Desafortunadamente, no ha publicado el código fuente (que ciertamente no tiene la obligación de hacerlo).

ACTUALIZACIÓN : Aparentemente me lo perdí, pero Andrew abrió este trabajo hace un par de años: https://github.com/aking1012/dc20

Además, una herramienta llamada " Antimeter " puede detectar el motor del medidor cuando se carga con una inyección reflectiva dll. Nuevamente, fuente cerrada.

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

¿Alguien tiene algún código fuente general (en Python, C, Delphi u otro) que estén dispuestos a compartir y que demuestre cómo detectar la inyección reflectiva 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 el antímetro) y encontrar procesos con DLL reflexivamente inyectados.

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

ACTUALIZACIÓN : Probé y puedo inyectar reflexivamente DLL sin derechos de administrador (y como un usuario normal), pero por supuesto como USUARIO I solo puedo inyectar en procesos que se ejecutan en el mismo nivel de integridad (y en mi sesión) ... pero eso todavía cubre aplicaciones como el paquete de Office, Internet Explorer, etc.

Answer 1

¿Qué hay de conectar la API de VirtualProtect? Debido a que las DLL que se cargan a sí mismas seguramente se ejecutarán en su rango de código de memoria. Esto se debe a que (como mencionó) usan los derechos de acceso de los usuarios, por lo que deben usar la API de proceso del espacio de usuario.

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

Si enlaza eso al principio de su programa, puede filtrar las llamadas de protección sospechosas (la que permite la ejecución del código). Luego buscaría un encabezado PE o similar delante de las páginas solicitadas para saber que es un módulo cargable ... nota: creo que esto no se necesita para DLL regulares ya que LoadLibrary maneja esto dentro del espacio Kernel. ¿derecho? TODO: verificar

Normalmente, el encabezado PE se encuentra 0x1000 (4096) bytes o una página delante del primer código ejecutable. Entonces, 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 el API de enganche, solo pregunte o lea toneladas de artículos en la red. Otro candidato enganchado es: FlushInstructionCache (...). Pero creo que solo Blizzard está usando esto para los módulos warden anti cheat ya que no hay razón para que la arquitectura x86 llame a esto.

... solo un pensamiento,

será