Saludos Mundo Libre.
Este es un texto externo ha este blog pero lo quiero publicar ya que me parece muy interesante he traducido el texto como es asi que aqui lo tienen.
Malware 1 - De Explotar a la infección
Marcos Nicholls - 07 de diciembre 2010
En esta serie de posts voy a buscar a los ataques de malware más recientes que ha planteado por el contexto. El análisis y las observaciones abarcará el ciclo de vida completo de software malicioso, proporcionando una visión general de las últimas tendencias en ataques maliciosos vivida por nosotros. Los blogs se detalle un ataque de la etapa inicial de explotar a la entrega de software malicioso como resultado, explotación y posterior infección. El primer blog ofrece una visión técnica de la entrega inicial y aprovechar las etapas que implica a PDF malicioso, como ha sido comúnmente observados con ambos ataques dirigidos y oportunistas en el último año. Los puestos restantes se cubren tanto el análisis del malware obtenida como resultado de la etapa de la infección y las posteriores comunicaciones entre el host infectado y servidores remotos maliciosos.
El PDF malicioso obtuve de una investigación reciente APT donde se extrajo el archivo de una estación de trabajo infectada. Este mensaje inicial de la serie cubre la etapa de vector de infección de un ataque de malware y se verá en JavaScript que se identifica en el archivo PDF. El análisis a continuación, seguirá en el análisis shellcode y la adquisición de software malicioso posterior desde un sitio remoto.
Para el análisis inicial PDF, podemos utilizar la herramienta PDF-Id de Didier Stevens que se puede obtener de aquí. Esta secuencia de comandos PDF proporciona una visión general de la presencia de ciertas palabras clave asociadas a PDF malware o explota. La presencia o ausencia de estas palabras clave le ayudará a decidir si un archivo PDF es potencialmente maliciosos y requiere un análisis posterior, o si es efectivamente benigno, es decir, no requiere mayor análisis.
La pantalla de abajo proporciona una visión general del documento PDF. La presencia de JavaScript es un indicador de que este archivo es probable que sea dañino por lo que es importante extraer este JavaScript, ya que es probable que contenga un exploit.
Hay muchas maneras de extraer el código JavaScript, como el uso de la secuencia de comandos PDF-Parser para deflactar los arroyos y analizar los objetos contenidos dentro de o bien, utilizar un sitio en línea para extraer los datos para usted. La solución más rápida es utilizar Jsunpack a escribir de forma automática la secuencia de comandos en un archivo. Usando Jsunpack de la línea de comandos, el programa que va a extraer el código JavaScript del PDF y escribir en el disco en un archivo (filename.pdf.out). El código resultante se muestra a continuación:.
Mirando el archivo revela JavaScript ofuscado y lo que parece ser shellcode. Los controles de código para Adobe Reader versión y explotar o CVE-2007-5659 o CVE-2009 0927. En la imagen, podemos ver que el autor de malware ha tratado de ocultar las llamadas. El código anterior utiliza una serie de declaraciones y eval String.fromCharCode para extraer los valores de la gran variedad de números enteros se traduzcan finalmente en el script de abajo que contiene el código shell. El uso de un depurador como Rhino, podemos recorrer el código y deobfuscate el código para identificar cómo funciona. En la siguiente imagen, podemos ver que el código se concatenan para formar un 'bucle' que extrae la siguiente etapa de Javascript:
El código siguiente etapa contiene el código de explotación y shellcode como se esperaba. Ahora es posible extraer el código shell del guión y determinar su función. El exploit utiliza depende de la versión y los controles para Adobe Reader 7.8.9 en adelante. Código se muestra a continuación.
Again, there are various ways of extracting and analysing the shellcode. We could insert a breakpoint in the form of “%uCCCC” into the start of the code and execute the PDF in Adobe, whilst running in a debugger such as Ollydbg. The debugger would hit the breakpoint at the start of the shellcode and we could view it running in the context of Adobe Reader. Alternatively, we can take the shellcode directly from the script, convert it to hex and then use a tool such as Shellcode2Exe to create a standalone executable that may be analysed in a debugger or IDA Pro. Using the latter approach, it is necessary to convert the code to hexadecimal and then convert to an executable.
Después de crear un archivo ejecutable de la shellcode, el análisis puede comenzar en un intento de entender lo que sucede como resultado de la explotación. El código shell es de tamaño pequeño y es probable para iniciar la descarga para obtener el código malicioso. Viendo el código en un desensamblador, podemos ver una serie de cuerdas, las llamadas a DLL y una URL
El código shell se puede cifrar y es útil para desplazarse por el código en un depurador para entender completamente la capacidad. Este punto de entrada shellcode ya dice el inversor de una gran cantidad de información, si sabe dónde buscar. En cuanto a este código, podemos adivinar que el código shell intentará encontrar la ubicación de algunos archivos DLL. Cualquier código tendrá que utilizar la API de Windows, y la dirección real en el espacio de memoria de un determinado proceso debe ser conocido. La solución más satisfactoria para encontrar direcciones de Windows necesarios funciones de la API está conectado con el uso de LoadLibrary () y GetProcAddress () las rutinas de la biblioteca de kernel32.dll. Por lo tanto los autores de malware que emplean a un número de técnicas para la búsqueda de estos en cualquier host de Windows y Service Pack. Estos mecanismos incluyen caminar a través de la SEH (Structured Exception Handler) y, como en este caso, al repasar la lista de módulos cargados en el PEB (Proceso de Medio Ambiente del bloque). La siguiente captura de pantalla de la AIF demuestra las funciones estándar para encontrar Kernel32.dll con el PEB. Los comentarios también se incluyen en el código.
El código en el desplazamiento por encima de 401.044 es el método estándar para identificar la ubicación de la PEB. Esta instrucción se almacena el puntero al PEB en EAX. Esto siempre se coloca en fs: [30h] en el TEB (Tema Medio Ambiente del bloque). La instrucción importante siguiente se carga el puntero a la estructura del gestor de datos - PEB_LDR_DATA, que está presente en el desplazamiento 0x0c en PEB. Además en este PEB_LDR_DATA estructura, el código puede utilizar el desplazamiento 0x1c para identificar InitializationOrderModuleList.
struct PEB_LDR_DATA{
...
struct LIST_ENTRY InLoadOrderModuleList;
struct LIST_ENTRY InMemoryOrderModuleList;
struct LIST_ENTRY InInitializationOrderModuleList;
};
Esta es la lista que se utiliza para identificar a cada módulo de carga y ayuda a la shellcode en la localización de las direcciones de base de kernel32.dll y otras funciones de la API que pueda ser necesaria para infectar el sistema. Una vez más, el código se mueve en forma previsible, a condición de que el analista sabe qué esperar. Ahora se procede a cargar la lista de entrada y la primera entrada contiene información acerca del módulo ntdll.dll. Al pasar por la lista para la segunda entrada en el 0x08 desplazamiento podemos obtener la dirección base de kernel32, como se ve en la imagen de abajo:
La dirección base se considera 7C80000 y EBX contiene ahora un puntero a esta dirección. Ahora que el código shell contiene la ubicación de kernel32.dll, el código puede cargar los archivos DLL necesarios y las funciones necesarias para continuar la ejecución. La siguiente etapa de ejecución es para el código shell para identificar la ubicación de la carpeta Temp, para almacenar el malware descargado. Se hace un llamado a Kernel32.GetTempPath, almacena la ubicación y concatena el nombre de archivo "n.exn" a la ruta.
El código shell que continúa la ejecución y resuelve la dirección de Urlmon.dll, que normalmente se utiliza para llamar a la función "UrlToDownloadFile". Shellcode incorpora esta función para descargar malware. La dirección de la función se ha resuelto y la shellcode por último, carga la dirección URL maliciosas para descargar el malware. La fase final de ejecución se ilustran en las siguientes imágenes.
Esto concluye la Parte 1 de esta serie de posts. En la parte 2, vamos a analizar el malware que ha infectado el sistema, como resultado de la explotación inicial PDF. Este artículo pretende mostrar cómo un gran número de las hazañas de malware comienzan con un objetivo PDF que conduce a la ejecución de código shell para obtener el malware siguiente etapa.
Fuente:http://www.contextis.co.uk/resources/blog/malware1/
Saludos Mundo libre
No hay comentarios:
Publicar un comentario