¿Qué metodologías son útiles cuando se aplica ingeniería inversa a malware / shellcode?

  

¿Cómo se inicia el análisis? ¿Comienzas en main y esparcido desde allí, o tienes un método mejor?

Comience con un análisis básico exhaustivo (tanto dinámico como estático): enumere las exportaciones, las importaciones, el uso de funciones, syscalls, winapi, mutex, las dependencias dll, cadenas y algunos grep en eso. Ejecute el análisis dinámico en entornos limitados básicos para llegar a algunos, aunque parciales y pueden ser un tanto incorrectos, puede presentar varias teorías sobre algunas de las funciones principales de ejecutable / dll.

dicho esto, si estamos hablando de java / .net, etc., por supuesto, descompílelos, pero no existe una práctica común sobre el uso de malware en dichos entornos.

Si encuentra llamadas a funciones sospechosas, digamos que el ejecutivo intenta escribir en algunos archivos de sistema / valores de registro críticos, o implementar archivos con nombres extraños, debe estar preocupado (o contento, según el color de su sombrero): ))

  

¿Cómo encuentra e identifica una funcionalidad importante o una funcionalidad en particular que le interesa?

Las cadenas pueden ser útiles: puede detectar algo sospechoso como una cadena que comienza con cmd.exe ... o incluso nombres de host, combinaciones de contraseña de usuario y otros El hacker de recursos y el caminante de dependencia son herramientas básicas para enumerar exportaciones, importaciones y recursos incluidos. La funcionalidad más importante casi siempre tiene que ser ingeniería inversa en IDA o una herramienta de análisis estático similar.

  

¿Cómo se asigna un flujo de control de alto nivel?

Si todo lo anterior falla, las capacidades gráficas de IDA son excelentes y se pueden usar para ello.

  

¿Cómo gestionas las rutinas de ayuda que has identificado? Considero que los marcadores son insuficientes y el bloc de notas es demasiado primitivo.

IDA tiene un sistema de comentarios, opciones para colorear, cambio de nombre y más. Para el proceso general, me gusta graficar las cosas cuando es necesario, es la forma más clara de hacerlo, incluso en visio.

  

¿Cómo evita perderse en la avalancha de código de ensamblaje?

Casi nunca haces ingeniería de ingeniería a nivel de asm TODO el código disponible. Algunos son más eficientes en el análisis dinámico (Olly e Immunity son geniales, la inmunidad es una bifurcación de Olly con muchos giros) y nunca se necesita revertir todo el código para poder resolverlo. Tengo un código de color en IDA y renombro constantemente las partes ya invertidas a algo más sensible que 'loc_402BBD'

  

¿Algún otro truco / consejo para abordar este tipo de tareas?

1. Nunca te quedes atascado en un solo estado mental, te puede traer muchos problemas; piensa en el código de análisis durante días y obtén una parte que cambia totalmente la forma en que te veías en las cosas, horrible.
2. Practica, mucho, no hay nada igual, créeme.

Un método que me encanta es usar un software de monitoreo de API. Mi favorito es el de Rohitab (google). Depuro el malware en cuestión y paso a paso mientras superviso las llamadas a la API realizadas en el software. Esto le proporcionará mucha información sobre lo que está haciendo el malware. Por ejemplo, el monitoreo de las llamadas FileRead y FileWrite le permitirá saber qué archivos crea o lee el malware. Tenga en cuenta que esto es algo así como una técnica de caja gris y no puramente ingeniería inversa. Aunque, si encuentra algo interesante en el monitor API, sabrá en qué parte del ensamblaje es la parte interesante.

Saludos.

Anuncio 1: No importa cómo empieces, es una cuestión de preferencia. Normalmente empiezas desde main() , ya que no hay otras opciones si consideras realmente pasar por el código. También importa a qué te refieres con análisis, si esto es paso a paso en este caso, main() es una buena opción.

Anuncio 2: Ver anuncio 4.

Anuncio 3: si está escrito en ensamblaje, la mayoría de las veces hay un bloque principal con saltos a todas las funciones una por una. Si está escrito en C, también hay un bloque principal que se usa de manera similar, ya que el malware es a menudo una pequeña pieza de software.

Anuncio 4: etiquetando todas las direcciones con nombres de funciones

Anuncio 5: ver anuncio 4

Anuncio 6: Puedes usar las siguientes cosas:

• El desensamblador etiqueta todas las llamadas a las bibliotecas del kernel y del sistema operativo de forma automática, para que quede claro lo que está sucediendo en estos niveles.
• Máquina virtual para ejecutar código: qemu, el vino es útil para esto. No para aislar, pero en realidad para rastrear la actividad de malware de una manera precisa, cuando no se puede utilizar el depurador. KVM también es una buena opción decente.
• Identifique fragmentos de código y su función, por ejemplo, entienda las técnicas de compilación y de creación de malware, y con este conocimiento, pasar por esto es mucho más fácil.

En general, lo más difícil es comenzar, pero una vez que se analiza una parte importante, cada segunda pieza de código es más fácil. Al comprender varios compiladores e idiomas y la forma en que producen el código de la máquina, es mucho más fácil hacerlo.

Además, tener una base de datos de conocimiento de fragmentos de código y salidas de código de máquina del compilador ayuda mucho. Esta es una tarea de largo camino y hacer esto sin tener frameworks es muy difícil, especialmente porque hay muchos compiladores hoy (nuevas versiones), es más difícil que nunca.