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…]

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:

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.

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:

• Oletools: http://www.decalage.info/python/oletools/
• Oledump: http://blog.didierstevens.com/programs/oledump-py/
• Virtualbox. Máquina Virtual Windows XP (Equipo huésped)
• dnschef para simular conexión a internet: https://thesprawl.org/projects/dnschef/
• Whireshark: https://www.wireshark.org/

Equipo huésped Windows XP:

[Read more…]