Como suele ser habitual por estas fechas, ahí va nuestra felicitación de parte de todo el equipo de Security Art Work. Les deseamos unas felices fiestas y un próspero 2016. Pórtense bien, tengan cuidado ahí fuera, pásenlo lo mejor que puedan y pórtense bien. Sí, está repetido.

¿Qué?

Ah, eso. Sí, claro, si quieren verla tendrán que ejecutarla. Les garantizo que es inofensiva, a no ser que el ascii art les dé urticaria.

#!/bin/sh
# v0. Parametrización del año en curso para que nos sirva para los siguientes
# v1. Como somos muy de felicitar el año también en enero, se contempla este 
# caso

curr=`date +%Y`
if (( `date +%m` == 01 )); then
	Y=$curr
else
	Y=`expr $curr \+ 1`
fi

cat <<EOF |sed -n '1!G;h;$p' |sed s/Z/" "/g |tr SECURITYAtWOrK .:\\\\@\(\)_\|\'\`adel
ZZZZZZi0CSZZZZZZZZZZZZZZZZZZZ,0GEZ
ZZZZ,G0iZZZZZZZZ,,SZZZZZZZZZZZZL0LSZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ~
ZZZ100;ZZZZZZZSfLLLEZZZZZZZZZZZZ100EZZZZZZZZ~ZZZZZZZZZZZZZZZZZZZZZZZRUI
ZZ100;ZZZZZZZZZ;LL1SZZZZZZZZZZZZZt00;ZZZZZZRUIZZZZZZZZZZZZZZZZZZZZtCYTY
Zi00fZZZZZZZZZZZZZZZZZZZZZZZZZZZZSC00,ZZZZZYTYCTTTTTTTTTTTTTTTTTTTZZY-Y
SG00,ZZZZZZZZZZ,iiiSZZZZZZZZZZZZZZ;00CZZZZZY-YZZZ¡FrKizZNWviOWO!ZZZZYZY
100CZZZZZZZZZZZELLLSZZZZZZZZZZZZZZSG00;ZZZZYZYZZZZZZZZZZZZZZZZZZZZZCY-Y
C00fZZZZZZZZZZZ,LLLSZZZZZZZZZZZZZZZC00fZZZZY-YCTTTTTTTTTTTTTTTTTTTTZRUI
G00tZZZZZZZZZZZ,LLLSZZZZZZZZZZZZZZZL00LZZZZRUIZZZZZZZZZZZZZZZZZZZZZZZT
G00tZZZZZZZZZZZSLLLSZZZZZZZZZZZZZZZf00LZZZZZT
C00fZZZZZZZZZZZSLLLSZZZZZZZZZZZZZZZC00fZZZZ^^^[T]^^^Z	ZZZZZZ/AZZZZtCZZ
i00GZZZZZZZZZZZ,LLfSSZZZZZZZZZZZZZSG00;ZZZZ/ASAASASCZ	ZZZZZZZ//ZZCC
SG00EZZZZZZZZZZELLLiSZZZZZZZZZZZZZ;00CZZZZZZ/SASASCZZ	ZZZZZZtA//CCAA
ZE00CZZZZZZZZZZiLLLLLtE,EiiZZZZZZZC00EZZZZZZ/SAASACZZ	ZZZZtERT>RI<TIEAZZ
ZZE00tZZZZZZZZSfLL1SiLLLLLL;ZZZZZf00EZZZZZZZZ/ASACZZZ	ZZZZEoETZZZZTEEEZ
ZZZ,G01ZZZZZZZZZSZZSZSZSSZSZZZZZt0G,ZZZZZZZZZ/SSACZZZ	ZZZZSEEEAAAAEoESZZZZ
ZZZZZf0LZZZZZZZZZZZSZZZZZZZZZZZL0fZZZZZZZZZZZZ/SCZZZZ	ZZZZZSEEoEEEEESZZZZ
ZZZZZZSCG;ZZZZZZZZZZZZZZZZZZZ;0CSZZZZZZZZZZZZZZ*ZZZZZ	ZZZZZZZTSSSSTZZZZZ
EOF

echo "\nTodo el equipo de Security Art Work os desea FELICES FIESTAS y PRÓSPERO $Y"

Recientemente hemos visto como en medios generalistas comienza a hablarse del concepto de secuestro virtual, una estafa que va a más y que puede afectar a cualquiera de nosotros.

Lo primero que hay que saber es que un secuestro virtual no es un secuestro. Es decir, no hay nadie secuestrado, aunque el delincuente trate de hacernos creer lo contrario.

Un secuestro virtual es una estafa en la que la víctima recibe una llamada en la que se le asegura que han secuestrado a un familiar suyo, y se le pide a cambio un rescate económico. Sin embargo, no existe tal secuestro, ya que la víctima está a menudo escogida al azar y la información del rehén está extraída de redes sociales u obtenida en de la propia víctima.

Las fuerzas y cuerpos de seguridad del estado están informando sobre la forma de actuar de estos delincuentes, para poder identificarlos mejor:

[Read more…]

(N.d.E. Interrumpimos la programación habitual para anunciar una noticia de la que nos sentimos muy orgullosos)

Desde que S2 Grupo comenzó su andadura hace ya unos cuantos años, los que formamos parte de ella hemos visto cómo años tras año ha sido galardonada con diferentes premios y reconocimientos, incluyendo el premio que este mismo blog recibió hace ya unos años.

En este caso, es la revista SIC la que, en la duodécima convocatoria de sus Premios SIC y coincidiendo con la edición XXVI del congreso global de ciberseguridad, seguridad de la información y privacidad Securmática, concede a S2 Grupo uno de sus premios por su “apuesta firme por la excelencia en la prestación de servicios de seguridad de la información, incluyendo la I+D+i y los servicios gestionados“.

La revista SIC, con una experiencia en el sector de más de 20 años y organizadora de Securmática, Respuestas SIC y Espacio TiSEC, reconoce a través de este premio el buen hacer en materia de seguridad de la información de nuestra empresa.

Desde S2 Grupo queremos agradecer a la revista SIC que nos haya concedido este premio, comprometiéndonos a seguir trabajando duro para que no sea el último.

Nota del editor: mañana por la mañana, nuestro compañero Antonio Sanz estará hablando sobre el malware del que trata el presente post, y la gestión del incidente asociado a la detección del mismo, en las VIII Jornadas STIC del CCN-CERT.

El pasado mes de agosto, varios empleados (bastante bien escogidos) de uno de nuestros clientes (una empresa estratégica), recibieron una serie de mensajes un tanto “sospechosos”, que referían el entonces relativamente reciente accidente del avión de Malaysia Airlines, sobre cuya investigación no paraban de llegar noticias.

Al abrir el documento, que en principio tenía extensión .doc, aparecía efectivamente una especie de “comunicado”, o similar, sobre el accidente en cuestión.

Sin embargo, un análisis básico revelaba que el fichero era en realidad un RTF (y no un DOC), y que venía con regalo: nuestro viejo amigo, el exploit CVE-2012-0158. Como los hashes del fichero todavía no tenían presencia pública en los servicios habituales (VirusTotal, Malwr.com, etc. obviamente, tampoco el AV corporativo lo detectaba), y dado el caracter de los destinatarios de los mensajes, pensamos que no vendría mal “jugar” un poco más con el artefacto, y lo pusimos a macerar en nuestra sandbox.

Tras unos 12 minutos (!) de espera, el especímen por fin intentó contactar con algo, y, para nuestra sorpresa, ese algo no era sino un proveedor público de servicios WebDAV. Así que el bicho utilizaba ese protocolo sobre HTTP (y no sobre HTTPS en principio), sea lo que fuera lo que pretendiera recibir o transmitir con ayuda del mismo…

Efectivamente, simulando en nuestro laboratorio el servidor WebDAV al cuál estaba intentando llegar, el especímen trataba en primer lugar de descargar información desde una determinada ruta del WebDAV, y a continuación, dejaba ficheros con nombres pseudoaleatorios, pero extensiones conocidas, sobre otra ruta.

Tras explotar, el adjunto RTF malicioso se sustituía a sí mismo por un documento “limpio” (el del comunicado sobre el accidente) que llevaba empotrado (de forma que si analizabas el documento droppeado por separado, no había forma de reparar en la existencia del exploit o del resto del malware), y lo abría con el Word, simulando perfectamente la apertura habitual de un fichero DOC.

Sin embargo, por debajo estaba droppeando y ejecutando un fichero .vbs, que a su vez droppeaba una DLL que llevaba empotrada en su propio código fuente, codificada en hexadecimal.

Esta DLL (droppeada directamente sobre %SystemRoot% si el usuario disponía de los privilegios necesarios, o sobre el perfil del usuario en caso contrario) se cargaba utilizando el comando de Windows regsvr32, persistiendo a través de una invocación del mismo sobre la habitual rama del registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run. En el caso de este adjunto, la clave se escribía con el nombre Barbicas.

Profundizando sobre el análisis dinámico de la DLL (el análisis estático no arrojaba mucha más información), observamos la presencia de un packer, que para unpackear a su huésped lleva a cabo gran cantidad de operaciones intensivas en CPU (durante el proceso de unpacking, que dura varios minutos, una de las CPU del equipo víctima se mantiene al 100% de utilización). El packer desofusca el código del malware sobre nuevas páginas del mapa de memoria del proceso y pasa a ejecutarlo (direcciones 0x7FF40000 y 0x7FF80000 en la captura de muestra).

En la memoria del proceso puede encontrarse la URL del servidor WebDAV, así como el nombre de usuario y contraseña para acceder al mismo, la ruta de bajada y subida desde y hacia el servidor, y las extensiones de los ficheros que se suben al mismo.

Una vez unpackeada con técnicas estándar, fue posible dumpear la DLL (reconstruyendo su Import Table) para pasar a analizar estáticamente en más profundidad el código desofuscado. Lo primero que nos llamó la atención fue la presencia de las tablas de inicialización del algoritmo AES en la sección de datos de la DLL.

En efecto, el malware utilizaría el algoritmo de cifrado AES en modo CBC.

La clave utilizada tiene una longitud de 256 bits, estando hardcodeada en el código del ejemplar.

En efecto, el tamaño de los ficheros cifrados siempre es múltiplo de 16 bytes, el tamaño de bloque del AES, y el fichero cifrado incluye el vector de inicialización del modo de cifrado en bloques (como se desprende de los parámetros utilizados en las llamadas a las rutinas de cifrado y descifrado observadas durante el análisis dinámico que llevamos a cabo), añadiendo otros 16 bytes extra al tamaño de los ficheros.

Por lo tanto, hasta el momento teníamos un malware no público, capaz de conectarse a un servidor WebDAV (un protocolo cuanto menos original en lo que respecta a campañas sobre las que se tenga constancia) de Internet utilizando una cuenta (usuario y contraseña) hardcodeada en el código, y capaz tanto de obtener información cifrada con AES (estando la clave de 256 bits también hardcodeada) desde una ruta de esta cuenta del WebDAV para recibir instrucciones (canal de comando y control), como de cifrar y almacenar información hacia otra ruta de la cuenta del servidor WebDAV (canal de exfiltración).

Pero las sorpresas aún no habían acabado; tras analizar los demás ficheros adjuntos (recordemos que varios usuarios recibieron mensajes maliciosos), resulta que cada uno era diferente:

• El comunicado sobre el accidente aéreo droppeado (el documento “limpio”) resultó ser el mismo para todos los adjuntos
• Tanto el fichero .vbs como la DLL droppeadas eran diferentes para cada mensaje (tanto en nombre, que trataba siempre de imitar el de alguna DLL legítima de Windows, como en contenido)
• La clave del registro (Barbicas en el primer especímen analizado), variaba en cada dropper
• El tiempo de unpacking también variaba para cada adjunto, observando tiempos desde 8 minutos hasta más de 15 minutos (en cualquier caso, el proceso mantenía una de las CPU al 100%)
• El servidor WebDAV era el mismo para todos los especímenes, así como el nombre de usuario y la contraseña utilizados para iniciar sesión en el mismo (lo cuál no significa que, para otras posibles organizaciones víctima o campañas, los atacantes no puedan generar ejemplares que utilicen otras credenciales)
• Sin embargo, la clave de 256 bits para AES, así como los directorios de subida (exfiltración) y bajada (comando y control) de información, eran diferentes para cada ejemplar analizado (en todos los casos, iban hardcodeadas en el propio código)
• Las extensiones utilizadas en los ficheros subidos al WebDAV (.TAR, .TIF, .TXT, etc. en el primer adjunto) variaban en cada ejemplar

Queda claro por lo tanto que lo que observamos fue probablemente una posible campaña, utilizando malware desconocido hasta el momento y seleccionando a las víctimas de un modo altamente dirigido.

Los atacantes emplearon alguna clase de generador de especímenes; una vez un ejemplar es generado, identifica unívocamente a la víctima, así como su información exfiltrada en el WebDAV, al utilizar cuentas, directorios, extensiones de fichero y claves AES diferentes en cada mutación. Además, queda claro que esto se trataba muy seguramente de la primera fase en lo que podría haber sido una persistencia más duradera en la organización víctima.

¿Qué habríamos encontrado tras unas cuantas semanas, o meses, de compromiso?

Actualización: en 8 de diciembre de 2014, Symantec (re)bautiza el malware del que les hemos hablado (o al menos alguna de sus mutaciones) como Infostealer.Rodagose (Number of infections: 0 – 49, Number of Sites: 0 – 2).

Seguimos prefiriendo el nombre Barbicas :-) Han pasado más de 4 meses desde que observamos por primera vez el malware y el primer producto AV lo empieza a detectar (y de momento no tenemos constancia de más presencia pública, además del sitio de esta compañía AV), reportando “pocos” sitios infectados (¿se tratará pues de una campaña que ha afectado a varias organizaciones?); esto, junto al carácter altamente dirigido de las víctimas seleccionadas en el caso de nuestro cliente mantiene el interrogante por el momento.

Trataremos de mantenerles informados a medida que vaya surgiendo más información.

Actualización 2: en 9 de diciembre de 2014, Blue Coat libera un informe, (re-re)bautizando el malware como Inception. Toda la información presente en el informe es coherente con lo observado por nuestro equipo en agosto de 2014. Confirmado: es una campaña APT :-)

Actualización 3: en 10 de diciembre de 2014, Kaspersky lo ha apodado Cloud Atlas.