Evasión de Antivirus 2-Bases de la detección y analisis de malware

0. Punto de partida

En el artículo anterior comentamos como los antivirus comenzaban a separar entre lo que es malware y lo que no de manera sencilla. En este vamos a asentar los puntos básicos de como se analiza una acción maliciosa e introducir al contexto del malware. Vamos a ir poco a poco comentando y ejemplificando los métodos principales para asentar un par de categorias y términos con los que vamos a tener que trabajar.

1. Detección estática

La detección estática es “as is”, son el conjunto de cosas que podemos analizar con el malware una vez cae. Es decir si a mi me cae en un disco el malware que puedo hacer para observar su contenido “sin tocarlo”. En ese sentido en el post anterior hemos visto dos métodos de los primigenios sobre la detección estática: el hash del fichero y el firmado. Ninguno de los dos son necesariamente resolutivos del problema, porque ningún método es resolutivo en si mismo y definitivo. Existen más métodos en los cuales profundizaremos como la entropía o las consecuciones de bytes firmados por soluciones de seguridad como maliciosos, lo cual también veremos en profundidad en adelante. La evasión de este método está muy documentado por Rasta Mouse y el proceso de limpieza a mano de estos bytes como documenta en offensivedefence.co.uk .

De manera adicional podemos realizar detecciones sobre comportamiento el cual se realiza estáticamente, por ejemplo podemos observar llamadas en el código a VirtualAlloc o cuestiones similares que pueden levantar alertas.

2. Detección dinámica

Son las que nacen del comportamiento del propio malware en su funcionamiento por tocar unos u otros componentes u ejecutar unas u otras accioens que se pueden considerar maliciosas o anómalas. Por ejemplo imaginemos que nuestro objetivo es realizar un dump del proceso LSSAS en el que se encuentran las credenciales del usuario mediante procdump:

procdump.exe -ma lsass.exe lsass.dmp

Esta acción levantará los siguientes eventos:

• 4688 : En la generación del proceso procdump.exe
• 4673 : por el uso de SeDebugPrivilege
• 10 : abres LSSAS con permisos de lectura de memoria, siendo un evento de Sysmon.
• 4656 : Se solicita un acceso de un proceso a un objeto, en concreto a LSSAS.

Todo esto ha ha realizado una serie de comportamientos que se ejecutan y son evidentemente maliciosos. Pero también puede ser detectado por realizar llamadas a IPs las cuales no tienen buena reputación o simplemente no tienen reputación ¿no?

Yo por mucho que llame a un instalador spotify.exe si no llama al dominio spotify.como sino a la ip 192.168.0.1 o a un dominio con mala reputación o que se haya creado hace poco puedo sospechar. Ya dependerá del grado de inteligencia que tengas desplegada y tu capacidad de reacción, pero a primera instancia parece raro. También podría dudar de procesos que sacan mucha información hacia fuera, que tienen una comunicación constante con el exterior, procesos con puertos desconocidos o procesos con puertos que no permito tener expuestos.

3. Detección por comportamiento

Según detallaba la parte de la detección dinámica se veía ya que pasabamos a la detección por comportamiento, ya que como verás no son categorías estancas y un mismo comportamiento o funcionalidad la puedes pillar de muchas maneras diferentes. Un ejemplo bastante entendible es el siguiente:

Que narices hace un notepad conectandose a localhost ¿Estamos locos? ¿que es lo próximo? ¿Mi calculadora pidiendo un café en starbucks?.

Al final en el comportamiento vamos a estudiar lo que es normal y lo que no, lo que tiene sentido o lo que no y a correlaccionar eventos. Por ejemplo en el post de Covenant C2 ¿Como funciona un Servidor de Command & Control? empezabamos a introducir conceptos y herramientas como sleep para no tener un tráfico recurrente y poder comunicarnos de manera puntual y solo para saber si es necesario con nuestr beacon ya que si mantenemos comunicaciones recurrentes será más fácil ser detectados.

Pero también tenemos que entender que implica un comportamiento que puede suponer una exfiltración desde diferentes máquinas.

O ser capaz de concatenar lógicamente una serie de movimientos laterales que se van reproduciendo en nuestra infraestructura poco a poco y para nada necesariamente el mismo día (o sí!).

4. Eventos e Indicadores de Compromiso (IoCs)

Dentro de esto como hemos ido viendo existen “eventos”, lo cual es un concepto bastante claro y que atraviesa Windows “si haces esto se genera un ID”. De manera teórica parece sencillo, pero discernir un evento de una acción maliciosa a una acción legitima puede ser dificil y requerir un análisis en profundidad. Aquí recordaros lo que se comentó en el post anterior sobre que es o que no es malicioso.
El concepto que puede ser nuevo en este punto es el de Indicador de Compromiso (IoC) el cual es bastante sencillo. Es una muestra de que algo es malo en base una detección posterior. Es algo muy común que trataremos en estos post y para lo cual podemos usar un reporte mismo de The DFIR Report en el que nos detallan que tras su analisis los siguientes IoCs son maliciosos:

d3f@ckloader
http://78.47.105[.]28/manual/152/152.zip
http://78.47.105[.]28/manual/152/1522.zip

SecTopRAT
45.141.87[.]218:9000

Brute Ratel:
megupdate[.]com:443 / 5.181.159[.]31:443
administrative-manufacturer-gw.aws-usw2.cloud-ara.tyk[.]io:443

Cobalt Strike
provincial-gaiters-gw.aws-use1.cloud-ara.tyk.io:443 / 44.196.9.9:443

QDoor
88.119.167[.]239:443
143.244.146[.]183:443

Además en el post nos proponen reglas y mejoras, pero los IoCs son algo muy importante. Ten en cuenta que tener inteligencia suficiente como organización, así como que tu proveedor de EDR y soluciones que usses, tengan información actualizada te puede ayudar en caso de que un atacante haya cometido un error en cualquier punto y haya reutilizado un endpoint para un ataque que vas a sufrir, esté en su código o lo que sea. Por lo que detectar activamente llamadas a cualquiera de estos servicios desde tu infarestrctura puede ayudarte, aunque no tiene porque ser la base. De hecho en muchos analisis el IoC tras un postmortem en un incidente puede ayudarte, por ejemplo, puede que no estes detectando una salida de tráfico pero si hay un actor de amenazas que cuando cifra sus ficheros deposita siempre en C:\windows\ un fichero “ransologs.txt” puedes monitorizar un evento previo como es la subida de carga en las máquinas y la generación de ese fichero para levantar un incidente. Son cosas que te permiten adelantarte en caso de que sea posible y que si estás durante el incidente te pueden ayudar a tomar acciones.

5. Análisis y sandboxing

Cuando nos enfrentamos al analisis de un malware, custom hecho por nosotros dentor de la parte ofensiva o desde el blue team podemos encontrarnos multitud de capas de seguridad sobre el propio malware. Estas capas pueden ser en el propio despliegue, sobre los procesos de ejecución o sobre el contenido. En general tienen que tratar no solo de ser efectivas en si mismas, sino no aumentar la facilidad de descubrir el funcionamiento del malware. Para ello existen muchas herramientas de diferentes tipos y para diferentes causísticas como la ofuscación, cifrado, antidebuging, antianalisis, protecciones sobre comportamiento…

Los Antivirus tratan de diversas maneras adelantarse al comportamiento del atacante estableciendo controles sobre el funcionamiento en el sistema y así poder determinar cuales son anómalos y cuales no. El problema principal desde nuestro punto es que estos métodos de manera intencional no son transparentes, por lo que descubrir cuales son cada uno de los pasos que se realizan en una detección concreta es complejo y normalmente requiere de un trabajo de debuguear las técnicas que utilizan y así poder saltarselas.

Para poder explicar un poco su funcionamiento y visualizarlo debemos de visualizar también el comportamiento de un malware complejo. Es por ello que vamos a exponer un poco lo que es una Sandbox. Una Sandbox es básicamente una máquian virtual para analisis de malware la cual incluye un montón de funcionalidades preparadas para analizar comportamientos maliciosos. Personalmente suelo usar Any Run para realizar pruebas o simplemente estudiar, aunque hay que tener en cuenta que con la versión community hay bastantes limitaciones, entre ellas una a nivel de OPSEC que es la inteligencia compartida que viene de todo lo que subas. Lo que subas es público salvo que pagues para que no lo sea, y nadie te asegura que ellos no lo utilicen por muy provado que sea, por lo que mucho cuidado con lo que subes. En mi caso vamos a usar una muestra de Lumma Stealer obtenida a través de Malware Bazaar para analizar su comportamiento en la sandbox.

Comenzamos Descargando y abriendo el malware en una de las máquinas que nos proporciona AnyRun y clikandolo.

Un Steeler es un malware el cual fundamentalmente busca ejecutarse en tu máquina, robar todo y salir corriendo. Si la detección se hace posteriormente al Stealer “le da igual” ya que su objetivo ya lo ha conseguido. Muchas veces cuando nos encontramos stealers es en phishings que se realizan y que luego serán vendidos por parte de Initial Access Brokers a terceros para realizar otras operaciones. Depende mucho del grupo y la utilidad del stealer, hay algunos que se centran en robar solo credenciales, pero otros tratan de robar sesiones activas en algunos servicios o credenciales de banco. Depende del objetivo al que se dirigen básicamente.

Un punto positivo de una sandbox es que te va a porporcionar información ordenada de las acciones que realiza el malware paso a paso según vas interactuando con ello, por lo que tendrás facilidades para estudiar el bicho.

En este caso esta muestra viene perfecta para recordar una cosa muy sencilla expuesta en el post anterior

Podemos ver la matriz de Mitre sobre las técnicas utilizadas por el malware y vemos que encaja en concreto con lo que estamos analziando, acceso a credenciales, descubrimiento, consultas de registro.

Analizando el tráfico podemos ver llamadas a dominios que ya han sido categorizados como maliciosos pero que podrían llamarnos la atención en un análisis inicial.

También mediante el apartado MalwareConf al ser un software ya analizado el propio Any Run nos proporciona configuración del Lumma con los diferentes C2 a los que podría llamar. Tener varios dominios apuntando a uno o múltiples C2 es importante normalmente ya que permite hacer el malware resiliente y que si pierdes un C2 o lo banean puedas seguir operando. En este punto podemos ver de hecho dominios a los que no se ha llamado por parte del Lumma pero que podría hacerlo.

También detectamos la clave de cifrado del payload en ChaCha20 así como diferentes strings que pueden ayudar a la detección.Tendremos un resumen dertallado de todas las acciones ejecutadas.

Podemos entrar a detalle y como vemos esta versión de Lumma tiene como objetivo obtener ciptomonedas teniendo diferentes llamadas a wallets para tratar de robar su contenido.

Es importante tener en cuenta que en el analisis con una sandbox de un malware tienes diferentes configuraciones o acciones que ejecutar y ritmos de trabajo. Tanto la existencia o no de técnicas antianalisis como tener un grado de OPSEC aceptable para desarrollar tareas de analista es relevante. En este punto hemos realizado llamadas a un C2 dando archivos a un atacante el cual va a observar esa activación del malware. Esto puede ser un indicador para el atacante de que ha sido detectado y realizar acciones que eviten ser descubierto o rearticular su operativa.

Una herramienta así nos permite ir bastante abajo para poder ver cada uno de los puntos. Por ejemplo podemos analizar el contenido de algunas de las peticiones del malware mediante Suricata IDS.

En general hemos visto como funciona una Sandbox y como aterrizar el comportamiento de un malware real a diferentes tipos de analisis que se pueden dar. Es importante que tengamos en cuenta como se realizan este tipo de analisis no solo para realizar tareas defensivas y ayudar al blue team o para tener nociones de evasión, sino también para poder analizar técnicas reales y poder utilizarlas en nuestras operaciones ofensivas de cara a simular acciones de actores reales. En caso de que quieras revisar en concreto esta ejecución de Any Run está disponible en este link

---

Apoya el contenido de ciberseguridad en castellano

Si esta publicación te ha sido útil y quieres apoyar mi trabajo para que continúe creando más contenido, aquí te dejo algunas formas de apoyar:

1. Compartir el contenido 📲 Si crees que esta guía puede ser útil para otras personas, compartirla en tus redes sociales es una gran ayuda.

2. Donar en Ko-fi 💖 Puedes hacer una donación rápida a través de Ko-fi para ayudarme a seguir publicando guías y tutoriales. ¡Cada aportación cuenta y es muy apreciada!

3. Usa mi enlace de afiliado de NordVPN y NordPass para mejorar tu seguridad y apoyar la creación de contenido 🛡️ Puedes suscribirte a NordVPN con un 75% de descuento y 3 meses gratis o a NordPass con un 53% de descuento y 3 meses gratis y mejorar tu seguridad a la vez que apoyas el contenido de ciberseguridad en español.
   

---

¡Gracias por tu apoyo! 🙏