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.
No hay comentarios:
Publicar un comentario