La verdad que siempre que vengo a hablar de malware, hablo
de mis métodos de librerías y dependencias… que si hacemos ejecutables
portables con DAFe,
o de si nos aprovechamos con BugDLL, de la forma
de buscar dependencias de los ejecutables, y de su innecesidad de incluir las
extensiones junto al nombre de la librería. Todo, por modificar de una manera
suave, algún Offset en común, con las dolorosas firmas que compañías antivirus,
colocan en ciertas partes del malware evitando la realización de modificaciones
simples sobre los binarios.
En este caso viajaremos hasta la Import Table, donde encontraremos el nombre de las librerías necesarias
para la ejecución de cada binario, junto a sus Apis. Anteriormente encontré
métodos en los que agregando un carácter (X), delante del API desde un editor
hexadecimal este se volvía indetectable… claro que era muy posible que nos
cepillásemos media Import Table y en
algún sistema Windows 3.1 funcionase.
En este caso migraremos las instrucciones, hasta un hueco en
el que se permita escribir en memoria el nombre de las dependencias, APIs o
demás información de la IT, para más
tarde llamar a estas nuevas direcciones sin romper el flujo del ejecutable.
En primer lugar, abriré el Stub de mi anterior entrada con LordPE y dirigiéndonos al “Directory
Table” y después a “Import Table”, nos encontraremos con la siguiente ventana.
DLLName indica el
nombre de la librería utilizada por nuestra aplicación, es un Stub en Visual Basic 6 el cual, guarda en la
dirección 40413C,
el nombre de la librería MSVBVM60.DLL,
necesaria para la ejecución del mismo. Modificando esta librería de una mala
manera, conseguiríamos que la aplicación no se ejecutase.
Abriendo OllyDbg
y buscando la dirección de memoria mencionada anteriormente, llegaríamos hasta
el nombre de la librería en ASCII.
En la parte baja se muestra la dirección encontrada desde la
vista ejecutable.
Realizaremos una copia de MSVBVM60.DLL en modo binario.
Para más tarde, buscar un hueco en el ejecutable con Topo o simplemente viendo si queda
espacio ejecutable suficiente bajo la IT,
realizaremos un “Binary Paste”.
Una vez duplicado el nombre de la librería, podremos
sustituir el espacio de la antigua por NOPs
o código basura.
Haremos la copia de las modificaciones sobre el ejecutable y
guardaremos nuestro trabajo. En caso de querer ejecutar la aplicación, nos
encontraremos con el siguiente mensaje de error.
Nuestro Stub por
ahora está roto. Es el momento de volverlo a cargar en LordPE. Viendo que el DLLName
ahora no se encuentra disponible, deberemos de editarlo para incluir en Name RVA, la nueva dirección donde se
encuentra el nombre de la librería, la 40418A.
Guardaremos, y automáticamente nos mostrará el cambio en
pantalla.
Ya tenemos nuestra redirección a otro espacio del ejecutable
terminado, para evitar una posible firma sobre las dependencias. De la misma
manera, podremos realizar el mismo proceso sobre las APIs, modificando el valor
de ThunkValue junto al de APIName.
La siguiente imagen, mostrará a la izquierda el verdadero
lugar de la referencia al API vbaExceptHandler
y a la derecha el relleno de NOPs en amarillo, junto a la copia del API.
Igualmente podremos redireccionar todas las
instrucciones de la IT utilizando la dirección del OriginalFirstThunk, aunque podríamos dejar firmas con el gran
número de direcciones a mover.
Saludos 4n4les! ;)
eres un puto maquina tio.
ResponderEliminarUn saludo
maquina man :)
ResponderEliminarMuchas gracias a los dos! =D
ResponderEliminarLos archivos de ejemplo?
ResponderEliminar