06 agosto 2013

El 'Stub': la pieza clave del 'crypter'

Este es el tercer post de esta serie sobre 'crypters', y para que los que no han leído los dos post anteriores, sería conveniente que los leyesen: INTRODUCCIÓN A LOS 'CRYPTERS'  y FUNCIONAMIENTO DE LOS 'CRYPTERS'.

Hasta ahora hemos visto que un 'crypter' es un conjunto compuesto por un elemento habitualmente denominado también 'crypter', pero que como ya se ha puntualizado en los comentarios de posts anteriores sería más correcto designar como 'builder' y otro elemento conocido como 'stub'. El 'builder' es una parte del código relativamente sencilla, pues se encarga de conformar un ejecutable compuesto por el 'stub' y el 'malware cifrado'. El 'stub' es algo más complejo, pues se encarga de descifrar el 'malware cifrado' y, sin tocar el disco, arrancar el 'malware descifrado' directamente en memoria.

¿Cómo consigue el 'stub' arrancar el 'malware cifrado' directamente en memoria sin que este toque el disco?. Para ello, el 'stub' utiliza una técnica o procedimiento llamada 'Dynamic Forking' o 'RunPE'. Está técnica es muy antigua, pero sigue siendo totalmente válida y funcional a día de hoy.

Uno de los objetivos que me marqué al comenzar a escribir los artículos de esta serie sobre 'crypters' era que fuesen sencillos de entender por todos los lectores y no solo por aquellos que tienen conocimientos avanzados de malware y reversing. Por ello, voy a explicar los aspectos más importantes de la técnica 'Dynamic Forking' o 'RunPE' de forma sencilla, sin abusar de tecnicismos. Si alguno quiere profundizar en ella solo tiene googlear un poco y encontrará múltiples descripciones técnicas de la misma. En la imagen que he preparado con los pasos del proceso puede verse un mayor nivel de detalle.

Dynamic Forking o RunPE


Una vez el 'stub' se ha ejecutado, lo primero que suele hacer es localizar dentro del binario el 'malware cifrado', a continuación localiza la clave de 'cifrado/descifrado' e inicia el proceso de descifrado del 'malware' en memoria. Acto seguido, el stub arranca un segundo proceso, de si mismo o de un ejecutable cualquiera del sistema, es indiferente. Pero lo hace invocándolo con una propiedad denominada CREATE_SUSPENDED. Con ello lo que se consigue es cargar en memoria dicho ejecutable y los datos  de contexto necesarios para su ejecución, pero no llega a arrancarlo, está 'suspendido'. A continuación, a partir de la dirección de memoria donde se encuentra la cabecera y secciones del proceso suspendido, sobrescribe éstas con las del ejecutable malicioso ya descifrado que tiene en memoria. A partir de ahí, obtiene los datos de contexto del archivo suspendido y los sustituye por los datos del nuevo ejecutable, el malware. Estos datos son básicamente la dirección base y el punto de entrada del nuevo ejecutable (EP: Entry Point). Por último, relanza el proceso suspendido, consiguiendo que se ejecute el archivo malicioso en lugar del ejecutable suspendido invocado inicialmente. Así de simple y así de elegante.

Detección del 'stub'

Hay que entender que aunque el 'builder' sea detectado por un Antivirus, en adelante AV, esto no supone problema alguno, dado que el 'builder' funciona como una herramienta para componer el 'nuevo ejecutable malicioso', pero no forma parte del mismo. Al 'stub' le toca la parte más difícil, dado que él sí viaja (junto al malware cifrado) por el mundo y debe parecer un 'buen chico' para no ser detectado por los AVs.

Como se ha visto, un 'stub' debe realizar unas cuantas acciones concretas para conseguir descifrar y ejecutar el 'malware' en memoria. Está claro que los AVs conocen perfectamente dichas acciones y las funciones y APIs involucradas. Por tanto, no es sencillo para un 'stub' pasar inadvertido.

Recordemos que hay un tipo de firmas denominadas 'estáticas', 'genéricas' o 'binarias', que simplemente son cadenas de bytes del código que el AV ha marcado como maliciosas, siendo algunas de ellas instrucciones de código y otras simples cadenas de texto. Las firmas heurísticas son un poco más complejas, ya que se basan en detectar en el código, entre otras cosas, el uso de los 'procedimientos', 'funciones' y 'API's características de los 'stubs'.

Las firmas de AVs llevan muchos años perfeccionando sus técnicas de detección y por tanto conocen infinidad de variantes y métodos que han utilizado los desarrolladores para lograr que los 'stubs' consigan llevar a cabo su misión: descifrar y ejecutar el malware en memoria. Es por tanto complicado evadir la detección de los AVs, especialmente de las firmas heurísticas. Pero no es imposible.

Objetivo : Stub FUD (Full Undetectable)

Imaginemos un programador ante lo que podría ser su primer 'stub'. Tiene claro lo que debe hacer, así que se pone a codear la primera versión de la forma más simple, directa y sencilla que se le ocurre. Ya lo tiene, su 'stub' funciona y hace exactamente lo que debe hacer un stub, descifrar el malware y arrancarlo en memoria. La pregunta es, ¿será detectado este 'stub' pos los AVs? Pues sí, en principio lo será. Básicamente porque aunque no haya reutilizado ni una sola línea de código de 'stubs' anteriores, estará utilizando las mismas funciones, strings y API's que otros programadores ya han utilizado miles de veces con anterioridad, así que muchos AVs, no todos, seguro que han reconocido en dicho código intenciones poco loables.

Nuestro programador puede empezar a tocar el código 'reescribiendo' rutinas de la forma más rocambolesca posible, pero le va a costar sangre sudor y lágrimas evadir a todos los AVs que le han pillado. Al menos, haciéndolo desde el código.


Para empezar, nuestro programador ha cometido un error de principiante. Se ha concentrado en programar y reprogramar su código y no se ha molestado en 'ocultar' su binario a las firmas de AVs. En su afán por verlo 'indetectado' lo ha enviado a 'Virustotal' u otras páginas similares que lo han escaneado con múltiples AVs. Al haber sido detectado por varios AVs y ser un 'stub' nuevo, no visto con anterioridad, como indicará su HASH único, las firmas de AVs dispondrán de la muestra para estudiarlo a fondo, así que en poco tiempo, lo que eran unas cuantas detecciones se convertirán en muchas más.


Entonces, ¿cómo es posible conseguir un 'stub' indetectable? Generalmente al proceso de 'retoque' de un 'stub' para volverlo 'indetectable' se le conoce con el nombre de 'modding', y el éste tiene dos modalidades, el 'modding' desde 'código fuente' (o 'source') o desde el 'binario'. En general, lo más óptimo es combinar ambas, ya que hay firmas sencillas de sacar desde el código fuente, pero para sacar las más complejas, generalmente, hay que recurrir a retocar el 'binario'. Además, el 'modding' se aplica muchas veces para sanear un 'stub' detectado, pero no se cuenta con el código fuente del mismo, y es por esta razón por la que se utiliza muy habitualmente y de forma exclusiva el 'modding' desde binario.

Por tanto, a modo de recapitulación, el objetivo de todo 'modder' es dejar el 'stub limpio', 'indetectado', es decir 'FUD' y para ello, ha de 'retocarlo', a través de un proceso conocido como 'modding' que se sirve de múltiples técnicas para conseguir, por una parte, localizar la firma del AV, es decir, descubrir dónde, en qué bytes, el AV ha 'marcado' el ejecutable, y por otra parte, ser capaz de alterar esa secuencia de bytes de manera que el AV ya no detecte más el 'stub' y éste continúe siendo funcional.

En el próximo post introduciremos algunas técnicas cuyo objetivo consiste en la localización de las firmas de los AVs en los stubs.

--------------------------------------

Artículo cortesía de Abraham Pasamar

21 comments :

María García dijo...

Sólo me ha dado tiempo ha leer la mitad, pero ya te doy las gracias. Sobre todo por lo de: "Uno de los objetivos que me marqué al comenzar a escribir los artículos de esta serie sobre 'crypters' era que fuesen sencillos de entender por todos los lectores y no solo por aquellos que tienen conocimientos avanzados de malware y reversing." :-)
A ver si saco un ratillo para continuar.
La de Crypters es ya mi serie de verano favorita y espero con emoción cada nuevo capítulo.

Abraham Pasamar dijo...

muchas gracias :)

Jose Vicente dijo...

Articulo muy interesante, gracias por vuestras aportaciones, sois unos cracks

erdosain9 dijo...

mmm uno de mis temas preferidos. Se agradece que continúen con esta entrega!!!
SAludos!

Roberto Blanco dijo...

aasd

Roberto Blanco dijo...

Desde que leí el primer artículo que publicaste sobre este tema quede fascinado con la simpleza con que lo explicas, espero puedas seguir hablando sobre crypters y des temas más avanzados sobre ellos, muchas gracias.

w_h_d dijo...

Un par de preguntas; obviamente las casas AV utilizan páginas de tipo VirusTotal como "fuente" de malware, y todo lo nuevo que se suba va a pasar a formar parte de las firmas (en caso de que sea realmente malware). Pero entonces, ¿cómo haces para analizar el ejecutable con todos esos AVs, sin subirlo...? Instalar los 40 y pico puede ser un poco incómodo... xD
¿Conoces algún AV que sí analice de verdad la memoria RAM? En caso de que no, ¿por qué? ¿es técnicamente imposible?
Gracias!
Gran artículo, y gran serie, enhorabuena :)

Abraham Pasamar dijo...

Muy buenas preguntas todas ellas. En cuanto a analizar binarios sin subirlos a virustotal comentarte que lo explicaré en los próximos artículos porque el proceso de modding requiere hacer ese tipo de escaneos y obviamente que no se distribuyan las firmas. Pero te adelanto que un sistema online no es suficiente, has de instalarte mulltiples AVs para hacer el proceso de modding, así que toca o máquinas virtuales con un snapshot por cada AV o versiones portables y por consola o algún otro truco para instalar multiples AVs en una misma máquina. Las preguntas de los AVs y el escaneo en memoria me gustaría que nos la contestase algún lector que trabaje para una empresa de AVs que seguro que puede dar un opinión mucho más formada que la mía. A ver si tenemos suerte y nos contestan :)

Luis Sira dijo...

Bueno, yo te voy a completar un poco lo que dijo Abraham, como dijo, un sistema online no es suficiente ¿por qué?, pues, acá me remito a la petición de Abraham sobre alguien que trabaje en una empresa de antivirus para un explicación a fondo (y satisfactoria), ya que un antivirus te puede detectar algo en scan time o en run time (que sería la heurística supongo), así al modder (persona que se dedica al modding) a veces no solo le basta con escanear el archivo, sino con ejecutarlo para ver si este logra pasar la defensa en tiempo real del antivirus, ahora, como Abraham mencionó en el tema, un antivirus le asigna una firma al archivo, muchos AVs comparten las mismas firmas, es decir, si modder logró quitar la firma de un antivirus, posiblemente esté -como se dice en mi país- "matando varios pájaros de un solo tiro", ahora ¿cómo detectar que bytes el antivirus detecta como malicioso?, pues, lo hacen modificando offsets hasta acorralar el/los offsets que son detectados por el antivirus, a este paso, el modder solo necesita ver que hay en ese offsets y hacer las modificaciones. Me desvié de la pregunta, bueno, como podrás ver, a veces no es necesario tener todos los AVs, sino unos pocos (ya sea a través de máquinas virtuales, ya que el modder solo necesita encontrar el offseft que es detectado), pero un modder necesita asegurarse de que su crypter está "fud" y necesita escanearlo con todos los antivirus y enviar una muestra de tu malware a páginas onlines no es una buena opción para un modder, hace tiempo se trató de crear un programa llamado KIMS (creo que así se llamaba), donde podías instalar la mayor cantidad de AVs para ese entonces de forma portable y tener tu propio escáner en tu computadora, el proceso como te podrás imaginar es tedioso y creó que no funcionó, también podrías claro está, crear tu servidor de escáner tipo VirusTotal si tienes el dinero suficiente.

w_h_d dijo...

Ok, gracias a los dos :)
Se me olvidó hacer otra pregunta ayer (pido disculpas por el abuso xD); ¿hay más técnicas para inyectar directamente el ejecutable en memoria sin pasar por el disco, además de 'Dynamic Forking'?

Un saludo!

Abraham Pasamar dijo...

Yo es la única que conozco, pero la he visto implementada de múltiples formas, obviamente para minimizar la detección.

Abraham Pasamar dijo...

Ya digo que lo desarrollo en próximos posts, pero la idea básica es que en el proceso de modding, para cada AV con el que se está trabajando, es necesario escanear cientos, miles de variantes del fichero para detectar las firmas. Este proceso no es viable hacerlo a través de un escaner online, es necesario levarlo a cabo con un AV local, bien sea instalado, portable o en su versión command line (los que disponen de una).

Iván Portilla dijo...

Creo que olvidaste mencionar la llamada a ZwUnmapViewOfSections que es quien se encarga de desproyectar (unmap) la ImageBase que utilizará el ejecutable infectado. Ten en cuenta que de ser la misma del proceso puede tener problemas a la hora de reservar el mismo espacio podría tener inconvenientes.

Saludos.

Luis Sira dijo...

Claro, de alguna forma tienes que detectar los offsets :), has hecho un buen trabajo, si vas a desarrollar más el proceso del modding, hace mucho tiempo era muy famoso el AVFucker de SrSombrero para hacer más "automatizado" esto de detectar las firmas, yo estoy demasiado quemado en este tema, pero antes se usaba mucho los métodos Meepa, Hex, RIT, XOR, deben de haber tutoriales por ahí. Sería buena una explicación de algunos de estos simples métodos y mostrarle a la gente de forma educativa como ocurre el proceso, hace tiempo el modding trataba no solamente de crear crypter o troyanos "fud" sino de encontrar formas de propagación indetectables, los malwares son un tema extenso desde donde se mire, suerte con las próximas publicaciones.

Luis Sira dijo...

Un saludo al famoso The Swash, ¿refrescando los viejos tiempo? porque yo si :).

Iván Portilla dijo...

Hombre tú sabes que de famoso nada, y pues venía pasando por aquí y quise leer un poco y pues les anoté ese detalle :)
Es bueno leerte!



Saludos!

Abraham Pasamar dijo...

Sí, cierto, lo que ocurre que no quería entrar en tanto detalle en el post o se me pierde la gente :)...pero es bueno mencionarlos aquí para los que quieran profundizar. En cualquier caso se puede encontrar info de está tecnica bastante detallada. Pongo uno de los muchos enlaces que la explican (como se ve por la fecha del post, la técnica es bastante antigua como ya comentamos): http://www.security.org.sg/code/loadexe.html

Abraham Pasamar dijo...

No sea humilde, en el mundo de los crypters es usted una institución. Gracias por los aportes presentes y futuros.

Iván Portilla dijo...

Si existen, una que puedo recordar ahora mismo se llama DummySection generada bajo la idea de mi amigo [Zero]. Aquí puedes leer sobre ella:

http://h-sec.org/otra-forma-de-inyectar-un-ejecutable-en-memoria-dummysection/


Saludos!

Clakstein Tau Ceti dijo...

Gracias por los 3 post sobre este tema en concreto.
Un placer leer artículos escritos con inteligencia,buena página,raro aquí arriba.
Un saludo.

Solitario dijo...

vendo el fórum www.dekoders.net
intersados mandarme mp
gracias.