Zen y el arte de pescar APTs (II)

En el capítulo anterior habíamos dejado la investigación en un punto candente: teníamos pendiente un análisis forense del equipo del director de marketing, ya que todo apuntaba a que podía ser la fuente de la filtración de la información.

Hablando con María, la CIO de la Empresa, tomamos la decisión de ser extremadamente cautos a la hora de hacer una imagen forense del portátil del director de marketing, ya que la paranoia campa a sus anchas por la Empresa y no es posible fiarse de nadie.

Esperamos a que salga a una reunión en otra empresa para entrar en su oficina y abalanzarnos con nuestro bloqueador de escritura de discos para obtener una copia bit a bit (las únicas válidas ya que capturan el estado del disco tal y como está, copiando tanto ficheros borrados como espacio libre del disco duro).

Todo en la oficina es moderno y huele a nuevo. Sillones de cuero blanco, vistas esplendorosas de Madrid, un mini acuario en la mesa del despacho. El portátil es sin duda alguna ultra: ultramoderno, ultraligero y ultracaro, con disco duro SSD de última generación de 128Gb. El que sea pequeño es genial, ya que la imagen se podrá hacer en un suspiro. Sin embargo, que el portátil sea de una sola pieza hace que no sea posible extraerlo, lo cual nos complica la tarea ya que no podemos usar un bloqueador de escritura de disco (que nos aseguraría al 100% que no alteramos el disco original).

Lo primero es lo primero: respetar el orden de volatilidad de la información. María entra con la contraseña de administrador local en el equipo, lo que nos permite en realizar un volcado de memoria RAM del equipo a una memoria USB usando DumpIT.

Con el disco duro al final optamos por una solución de compromiso: pinchamos nuestro disco duro USB 3.0 y arrancamos con un CD live de SIFT (SANS Forensic Investigative Toolkit), una distro orientada al análisis forense que nunca automonta ningún disco en modo lectura/escritura. Cinco minutos de pánico porque el ultraportátil no tiene lector de CD y María tiene que ir corriendo a por un lector USB, medio minuto de lanzar dcfldd y la imagen empieza a crearse en un tiempo record: 23min 38seg.

Por ahora nos interesa ver lo que sigue haciendo el equipo del director de marketing, así que María habla con redes y nos dejan pinchar un equipo en la VLAN de dirección con el port mirroring (puerto espejo, o SPAN) activado. El port mirroring es una característica de los switches de gama media-alta que permite redirigir el tráfico que pasa por uno o varios puertos a un puerto específico. Se usa en muchos casos para diagnóstico pero a nosotros nos vendrá de maravilla ya que podemos capturar de forma pasiva el tráfico desde y hacia el equipo del director de marketing. Dejamos corriendo un Wireshark capturando todo el tráfico del equipo y nos llevamos la imagen al laboratorio para analizarla.

El primer paso suele ser el recuperar toda la información borrada del disco duro, así como del espacio libre para poder tener todos los ficheros que han estado activos en el equipo. Sin embargo, estamos tratando con una imagen de un disco duro SSD, de la que nos podemos fiar hasta cierto punto ya que los discos SSD suponen un reto en su análisis forense debido a la forma en la que almacenan y destruyen información.

Vamos a ser expeditivos, y a buscar en primer lugar lo que más nos interesa: la imagen logo.jpg en las caches de los navegadores. Encontramos 11 ocurrencias, que filtramos rápidamente hasta que nos quedamos con la imagen sospechosa:

No parece gran cosa, ¿verdad? Pero es suficientemente sospechosa como para darle un par de vueltas, porque puede ocultar más de lo que ofrece a simple vista. Sospechamos que entre sus bits puede haber un mensaje ocultado empleando esteganografía, el arte de esconder información empleando un canal encubierto en un portador aparentemente inocuo.

Hay infinidad de técnicas esteganográficas, pero la más sencilla es esconder la información en el LSB (Least Significant Bit), basada en alterar el último bit ya que es el que menos va a modificar el portador original. Lanzamos XStegSecret, nuestra herramienta favorita de detección de esteganografía y cargamos la imagen.

¡Tenemos premio! XStegSecret detecta que hay datos ocultos, y nos muestra un chorro de caracteres a priori ininteligibles. Al parecer los malos han sido listos y además de ocultar la información han aplicado una capa de cifrado sobre los datos, por lo que tendremos que bien recuperar la clave de cifrado, bien pasar a la fuerza bruta (algo poco recomendable si ni siquiera conocemos el algoritmo de cifrado). Dejamos esta línea de investigación aparcada y vamos a centrarnos en lo obtenido del equipo.

Antes de nada, hacemos una copia de la imagen para poder trabajar con ella (manipular nuestra única copia es muy peligroso porque si la modificamos sin querer contaminamos nuestra investigación), y la conectamos a un equipo con Windows para probar la táctica del antivirus: pasarlo por un antivirus distinto al instalado en la Empresa para ver si tenemos suerte. Tenemos muy poca fe en ser capaces de detectar una APT con un antivirus (actualmente es demasiado fácil el modificar un malware para que no sea detectado), pero como lo podemos hacer en paralelo lo dejamos corriendo mientras nos centramos en la imagen de la memoria RAM del portátil.

Si tenemos que hacer un análisis de memoria Volatility es sin duda nuestro mejor amigo. Empezamos con pslist y psscan para ver si el malware es tan educado como para tener un nombre fácilmente reconocible, pero no tenemos tanta suerte.

Afortunadamente Volatility tiene un arsenal de armamento para luchar contra el mal. Como el malware estará residente en memoria de forma semipermanente, es muy posible que las conexiones que haya realizado aún estén en la memoria, así que lanzamos un connscan:

 Offset(P)  Local Address             Remote Address            Pid   
---------- ------------------------- ------------------------- ------ 
0x0ea7a610  192.168.39.134:49260      XXX.XXX.XXX.XXX:80        2136

Pillado con las manos en la masa. Si volvemos al pslist, el PID 2136 corresponde a un svchost.exe, un proceso de Windows que alberga otros procesos y servicios… y muy usado por el malware ya que al ser habitual que otros procesos se “enganchen” al mismo es fácil que pase desapercibido. Pero no hoy.

Para ver qué tiene enganchado ese svchost.exe lanzamos un dlllist y encontramos de nuevo algo interesante:

Base                             Size Path
------------------ ------------------ ----
0x00000000ff530000            0x23000 C:\Windows\kernel32.dll

Extraño. Kernel32.dll es una de las dll base del sistema, pero la última vez que la investigamos estaba en C:\Windows\system32, no en C:\Windows. Vamos a volcar esa dll con dlldump y a analizarla.

Una vez detectado el malware, hay que ver si está extendido por la empresa. Generamos un IOC (Indicator of Compromise) a toda prisa con IOCEditor, y hablamos con María para que ejecuten inmediatamente la detección con IOCFinder a través de una GPO en el dominio de toda la Empresa (a lo bruto, con un gpupdate /force). La detección da como único equipo afectado el del director de marketing. Al menos no es una epidemia…

Un strings nos da poca información de que aquí pasan cosas raras, pero para saber qué hace exactamente la .dll tenemos que aplicar un poco de reversing. Llamamos a nuestro experto y le contamos lo que suponemos que hace la librería y le pedimos que haga un poco de magia.

Mientras se lanza cual fox-terrier hambriento sobre el malware llamamos a María para que nos cuente cómo va el Wireshark que teníamos corriendo en la Empresa. María tiene noticias frescas: una captura completa de una nueva comunicación del equipo del director de márketing con la URL sospechosa. El contenido es francamente curioso, ya que mezcla palabras al azar con un contenido extraño de este estilo:

Lorem ,ZGwg ipsum ,dGV4f ad ,G8ZX his ,MgbG scripta ,EgY2 blandit

Al parecer están siendo especialmente listos, y están ocultando texto codificado dentro de un texto normal para intentar evadir a los sistemas de DLP (Data Loss Prevention) intentando parecer un texto inofensivo. Un par expresiones regulares con sed/awk más tarde obtenemos algo similar a:

ZWwgdGV4dG8gZXMg bGEgY29udHJhc2XDsWENCg ….  ==

Que es sin duda alguna codificación Base64 (delatado por los “==” del padding al final de la cadena). Sin embargo, al decodificar volvemos a encontrarnos un texto ininteligible. Los malos han vuelto a emplear cifrado.

Tenemos varias posibilidades para seguir nuestra investigación, pero lo más importante es descifrar las comunicaciones entre el malware y los dominios de C2 y exfiltración. Pero para ello tendremos que esperar al siguiente artículo…

Comments

  1. Si coincidimos en que tal y como esta orquestada la APT, para la exfiltración, no es cosa de aficionados, deducimos que vale una pasta. De lo cual de deduzco que por dinero no va a quedar, con lo cual es completamente lógico pensar que se ha “untado” a alguien. (yo sigo apostando por el director de Marketing).

    Ahora bien, ahí va mi solución “diabólica”:
    1.- Si tienes la certeza de quien ha sido, busca un cabeza de turco que no sea el.
    2.- Extiende el rumor de que lo habéis pillado, y es mas de que lo sabíais.
    3.- Más importante, haz creer al culpable que esta a salvo.
    4.- Ahora dado que lo “sabíais”, convoca una reunión en la que darás a conocer el plan de marketing de la empresa, “el bueno”, que en realidad es malo (os lo habéis inventado). El culpable seguro que no puede resistirse a pedir más dinero por la información que cree que ahora es buena.
    5.-….
    6.-….
    7.-….
    ….

    En la próxima entrega de tu articulo, prometo desvelar el fin de mi malvado plan…..

  2. “El tio Tonet”
    No creo que una empresa que esté investigando este tipo de cosas, haga sociales con empleados del lugar al que esté escudriñando :)
    Tal vez le pueda servir a otro actor hacer esta escena, pero no creo que ellos puedan ni les sirva hacer teatro :D

  3. Antonio Sanz says

    Muy buenas tardes a ambos,

    Lo que comenta “El tio Tonet” es una técnica que se denomina en contrainteligencia “papilla de bario” – http://en.wikipedia.org/wiki/Canary_trap , muy usada para descubrir topos.

    Si lo trasladamos a temas técnicos, lo más parecido serían los “honeydocs”, documentos a los que no debería de acceder nadie más que curiosos, y que son capaces de generar alertas cuando un usuario lo abre (tengo otra entrada preparada a ese respecto).

    Y lo de hacer teatro … si se tiene que hacer se hace, pero como dice @MrFloydARG nos suelen contratar para las cosas técnicas ;)

    Un saludo,

    Antonio Sanz
    S2 Grupo

  4. Mis mas sinceras disculpas a los dos si os he liado.

    1.- Antonio, en ningun momento he dicho que lo tuvierais que hacer vosotros, lo decia por la empresa, como una forma de “salvar los muebles”

    2.- Evidentemente, si se decide ha hacer esto, no sería en plan tan secillo, evidentemente, el montaje que habria que hacer dependerá del valor de la información robada. No es lo mismo, mi hija que esta en un grupo de baile, y que tienen una chica que esta pasando sus montajes a otro grupo, que el plan estrategico de una empresa que vale XXXXX millones de euros y además compromete el trabajo de miles de trabajadores.

    En el caso de las niñas del grupo de baile, basta con pasar a la “presunta” topo, un montaje malísimo, asegurandole que ese era el bueno y que a la que pasaba la información la han pillado.
    Con esto consiguen dos cosas, desacreditar al presunto topo, y que las rivales si hacen caso hagan el más completo ridículo.

    Supongo que en el caso de la empresa, el montaje, si hiciese falta para salvar la empresa, sería un “pelin” más complicado.

    Por cierto no sabia que la tecnica tuviese un nombre. Gracias a los dos.

  5. Por cierto:

    ZWwgdGV4dG8gZXMg bGEgY29udHJhc2XDsWENCg …. ==

    al decodificarlo me sale:

    el texto es la contraseña

    que sentido tiene, con lo que supongo que esta inventado, no?

  6. Un artículo muy interesante. Y gracias por las referencias.

    Me ha sorprendido lo de la entrada a urtadillas en el despacho del director. ¿Eso se puede hacer? Quiero decir: imagina que le colais pruebas falsas. Ya sé que vosotros no, pero es una posibilidad. ¿No debería estar él delante? ¿O alguien de los sindicatos o así?

  7. Muy buenos días, María

    Todo al final depende de las políticas de seguridad que estén implantadas en la empresa (y por supuesto, difundidas y aceptadas).

    En muchas grandes empresas el tema de la monitorización está más que trillado, y los empleados saben que el correo y/o la navegación son susceptibles de ser revisados (esto daría para un post entero, pero con más legalidad que otras cosas).

    Aquí hay que tener en cuenta que sabíamos muy poco de lo que estaba pasando. Era muy posible que el propio director de marketing estuviera implicado, o que de forma indirecta pudiera alertar a los “malos” que estábamos investigando. El manter un perfil lo más bajo posible era imprescindible. Cuantas menos personas supieran que estábamos investigando, mejor.

    Y luego hay que pensar en otro factor muy importante: en más de un caso, las empresas no quieren buscar culpables a los que demandar. Lo único que quieren es resolver el problema lo antes posible (y a ser posible, sin que nadie se entere). En esa tesitura, algunas operaciones se pueden relajar sensiblemente.

    Pero como tú bien dices, para hacerlo al pie de la letra (como se ha hecho en otros casos), se debería de contar con la propia persona, alguien de TI, un representante de los sindicatos… y en algunas ocasiones, alguien de seguridad física.

    En este caso en particular se contó con la colaboración de María, que es la que autorizó la operación y estuvo con nosotros en todo momento.

    Un saludo,

    Antonio Sanz
    S2 Grupo

  8. Buenas tardes,

    Sí, el tema de los correos, la navegación (e, incluso, en otros países, los certificados “falsos” para poder examinar la navegación cifrada) está bastante trillado. Pero, si el director fue un poquito avispado, tendría contraseña en la BIOS. ;)