Detección de inyección reflexiva de DLL

Question

Detección de inyección reflexiva de DLL

#1 de 0xdabbad00 (8 votos)
#2 de Jordan Hanna (2 votos)
#3 de secabstraction (0 votos)
#4 de Félix (0 votos)

15

En los últimos años, los programas maliciosos (y algunas herramientas de prueba de la pluma, como el paypreter de Metasploit) han comenzado a utilizar 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 trabajo de Joachim Bauch .

Sin embargo, en DEF CON 20 Andrew King demostró que era capaz de detectar Se inyectaron DLL utilizando una inyección reflexiva de DLL . Su presentación se llamó " Detección de inyección reflexiva ". Desafortunadamente, no ha publicado 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: enlace

Además, una herramienta llamada " Antimeter " puede detectar el motor del medidor de esfuerzo 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 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 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 hacer esto.

ACTUALIZACIÓN : probé y puedo inyectar DLL de forma reflexiva 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 aún cubre aplicaciones como la suite Office, Internet Explorer, etc.

malware windows antimalware injection metasploit

pregunta Mick 28.09.2012 - 17:25

fuente

4 respuestas

Lea otras preguntas en las etiquetas malware windows antimalware injection metasploit

¿Qué tan malo es la pérdida de direcciones IP internas a través de DNS externo? Cómo informar que recibo una oferta para poner malware en mi código

score 8 · Answer 1

Considere qué es la inyección reflexiva de DLL: explota una aplicación para ejecutar código arbitrario y este código de shell carga una DLL en la memoria como un blob de datos (todo lo que es el código de shell estándar hasta ahora) y luego entrega se ejecuta de tal manera que la DLL se carga correctamente como una DLL a través de un cargador de PE. El propósito de esta idea: le permite escribir una aplicación completa que pueda compilar en una DLL en el idioma que elija en lugar de escribir todo el malware como código de ensamblaje con compensaciones de memoria fijas.

Por lo tanto, para detectar, desea buscar un archivo PE que existe solo en la memoria y no en un disco y está ejecutando código en él. Así que escanee a través de blobs de memoria ejecutables en busca de cosas que se parezcan a archivos PE, pero que no estén asociadas con ningún archivo en disco. Eso se puede hacer como una investigación forense post-explotación. O si desea detectar llamadas en tiempo real, normalmente asociadas con Reflective DLL Injection como LoadLibrary, GetProcAddress y VirtualAlloc, y realice el paso anterior con más inteligencia. Consulte ambuships.com

score 2 · Answer 2

Sé que esto es bastante antiguo, pero lo estoy agregando a otros que puedan encontrarlo en el futuro.

Las técnicas, como caminar por el árbol de VAD, pueden ser útiles para encontrar DLL inyectadas de manera reflectiva, siempre y cuando no hayan usado técnicas anti-forenses específicas para cubrir sus huellas en esta área. Hay un documento forense sobre esto de 2007 ( PDF ) que puede ser útil para el futuro. se esfuerza en detectar estos.

La detección no es tan sencilla como, por ejemplo, mirar la lista de módulos cargados en un proceso PEB (Process Environment Block, con el que no se registra la DLL reflexiva); sin embargo, con una buena referencia cruzada y tales herramientas podrían hacer una detección utilizando el árbol VAD en su lugar. El árbol VAD se puede encontrar en el bloque EPROCESS del proceso (almacenado en el espacio del sistema).

score 0 · Answer 3

Escribí una herramienta (en C # y powershell usando reflexión) que recorre las pilas de subprocesos e informa de dónde se están cargando las llamadas de función utilizando GetMappedFile. Muestra desde dónde se ejecutan todas las funciones (es decir, desde qué dll y dónde está en el disco) si la propiedad MappedFile está en blanco, lo más probable es que esté cargada de manera reflectiva;) enlace

score 0 · Answer 4

Lo he hecho en un gran producto de seguridad. Con VAD caminando en modo kernel, pero también con la ayuda de una función para detectar subprocesos remotos.

Primero detectas un hilo remoto para obtener la ubicación de la memoria. El subproceso inyectado tendrá principalmente una dirección de inicio que no se encuentra en ningún módulo cargado por la aplicación. Esto no debe suceder, después de eso puede retroceder en la memoria y detectar el encabezado de PE o la sección IAT / EAT, esto puede ayudar a localizar dónde se inyecta el código malvado