(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte técnica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo. Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XI Jornadas STIC del CCN-CERT aquí).
Otro día más en la oficina, con una lista de tareas pendientes a planificar más larga que la barba de Richard Stallman y ninguna de ellas entretenida: informes, documentación de un par de proyectos y la preparación de una reunión es lo que depara el menú del día para casi toda la semana.
Por suerte, el dicho de que “ningún plan sobrevive al contacto con el enemigo” en este caso juega a nuestro favor. Suena el teléfono, y mi jefe va directo al turrón: “Ha saltado una regla YARA del grupo ATD en la CARMEN de [Redacted] (entidad cuya identidad vamos a dejar en el anonimato denominándola a partir de ahora “la Organización”). Coge tus cosas y ve para allí a la carrera”.
El subidón ante la emoción de la caza es instantáneo: ATD es nuestra denominación interna de un grupo de atacantes que cazamos hace unos meses en otro cliente, y nuestros reverser destriparon el malware de arriba a abajo sin piedad. El análisis permitió detectar una serie de “irregularidades” particulares en su forma de actuar, lo que nos permitió generar una serie de reglas de YARA de alta fidelidad (es decir, falsos positivos prácticamente nulos). Si ha saltado en CARMEN (nuestra herramienta de detección avanzada de intrusos), es que tenemos “trufa” al 99%.
Portátil, disco duro de 4Tb para las capturas forenses, bloqueador de escritura, memorias USB con herramientas de análisis en caliente y live CD, lanzallamas… la mochila de respuesta ante incidentes está lista. Un puñado de caramelos del bote (los incidentes sabes cuándo los empiezas pero no cuándo los terminas) y nos montamos en un taxi derechos a [Redacted].
María (la técnico de seguridad de la Organización) ha hecho un excelente trabajo obteniendo más información sobre el posible ataque, y nos ofrece estos datos preliminares:
- La alerta de YARA ha saltado en un adjunto de correo, y hacía referencia a un evento internacional que ocurre dentro de dos semanas (una técnica muy habitual en ataques de spear-phishing avanzados).
- El correo ha sido enviado a un directivo de la Organización, que con las dos líneas de cargo que tiene se asume que es muy probable que tenga acceso a información sensible.
La suerte nos sonríe de nuevo ya que el directivo está de viaje por el extranjero y solo lee el correo en el móvil (donde las posibilidades de infección son mucho más reducidas). Localizamos al directivo, le contamos a grandes rasgos lo sucedido y obtenemos su autorización para solicitar a Sistemas la recuperación del correo de su buzón de usuario (mucho cuidado con hacer estas cosas sin los consentimientos adecuados o la ira de la LOPD/RGPD caerá sobre vosotros, avisados estáis).
El adjunto (un documento de Word) no tiene nada nuevo: información sobre una reunión comercial internacional sobre bla bla bla… y un adjunto a todas luces malicioso. Medio segundo de YARA sobre el adjunto confirma la regla, y otros cinco con las oletools permite identificar que el correo contiene una macro maliciosa. El Word es prontamente explotado en una máquina virtual de Windows 7 con dnschef para emular la conectividad a Internet, y nos escupe sin ofrecer resistencia una URL (según lo que sabemos de este grupo a día de hoy, la macro actúa como un dropper, descargándose el malware real de esta URL).
Capturamos la URL, y falseando el User-Agent de la petición (por si las moscas) nos descargamos el ejecutable desde la Wifi de la Organización (para intentar parecer que el directivo ha abierto el correo, por si los atacantes están monitorizando los logs de su servidor).
Comprimimos con contraseña, ciframos con PGP y enviamos a nuestro reverser de guardia con asunto “ATD – Revisar ASAP”. Mientras tanto proseguimos con las tareas de contención buscando la URL en los logs (para comprobar que no han mandado más correos con malware apuntando a esa URL). A continuación revisamos los logs de la pasarela de correo, con el fin de identificar la dirección falsa desde la que ha venido el correo electrónico y sobre todo el servidor.
Este paso es muy importante porque realimenta nuestra operativa de inteligencia de amenazas (los atacantes suelen reutilizar infraestructura, por lo que siempre es bueno conocerla), y sobre todo porque son muy buenos IOC (Indicators of Compromise o Indicadores de Compromiso). Esta información puede (y debería) ser compartida con otras entidades (CCN-CERT o INCIBE/CNPIC), para que avisen a otras organizaciones que puedan ser a su vez víctimas del mismo ataque.
Rebuscamos en los logs de la pasarela de correo mientras rumiamos “con SPF esto no habría pasado”… y nos sorprende no encontrarlo. Extraño. Revisamos los datos del correo por si nos hemos equivocado en la fecha, pero es la correcta. Repetimos la búsqueda (los grep a veces los carga el diablo), y seguimos sin encontrar el correo de marras.
Toca empezar a revisar otras alternativas. Pedimos a María que localice a la persona que supuestamente ha enviado el correo (al parecer, del área de administración del departamento del directivo). Ésta asegura rotundamente que “por supuesto que no lo ha mandado”, pero en cuanto le leemos el asunto y una parte del adjunto lo reconoce como suyo. Afirma con seguridad que corresponde a un evento que tienen que organizar… pero que el correo es un borrador que todavía no ha sido enviado a la lista de usuarios en la que se tratan estos asuntos.
La conclusión a la que llegamos es que es un correo interno de la Organización. Este hecho aclara dos cosas: en primer lugar, explica que no aparezca en los logs de la pasarela de correo externa, ya que es un correo puramente interno. Y en segundo lugar, que nuestros atacantes han comprometido al menos dicho equipo, lo que indica que el incidente no va a ser tan fácil de resolver como parece…
Volvemos a la fase de identificación del incidente (no sin antes compartir los IOC que ya hemos obtenido del incidente para agilizar la respuesta en otras organizaciones), y lo primero que hacemos es localizar el equipo del usuario que ha enviado el correo. Por suerte para nosotros (es un decir) son casi las 18.00h, por lo que podemos aprovechar que el usuario termina su jornada laboral para caer sobre su equipo cual fox-terrier hambrientos.
Aplicamos el procedimiento estándar: desconexión de la red, captura de RAM con DumpIt, obtención de datos de triage con Bambiraptor (el nombre puede sonar a chiste, pero la herramienta es magnífica) y apagado del equipo tirando del cable para una sesión de dc3dd del disco duro bloqueador de escritura mediante. A efectos de los atacantes, el usuario ha apagado el equipo y se ha ido a su casa (regla nº7 de la respuesta ante incidentes: no dejar nunca que los atacantes sepan que sabemos que están ahí).
La copia forense está comenzando cuando una compañera entra por la puerta (en incidentes serios, cuanta más gente puedas poner sobre el terreno lo más pronto posible, mejor), así que hacemos consejo de guerra frente a la máquina de café y la pongo al día del incidente. Hacemos el (tradicional) piedra-papel-tijera para ver cómo nos repartimos el trabajo, y yo me quedo con la captura de RAM mientras ella empieza a rebuscar en los logs de eventos, registros de Windows y MFT en busca de rastros de los atacantes.
Volatility, ahí vamos. Lo primero que hacemos es tirar nuestro conjunto de reglas de YARA para ATD sobre la RAM con yarascan, porque deberíamos identificar rápidamente el proceso infectado por el malware. Cinco minutos más tarde nos devuelve parcos resultados: cero. Vaya, nuestros “amigos” han debido evolucionar su malware. Toca remangarse la camisa.
El siguiente quick win suele ser malfind: lo lanzamos sobre la RAM para que detecte código oculto o inyectado en la memoria, pero tampoco nos devuelve nada interesante. Toca lanzar toda la artillería: pslist, pstree, psscan, cmdscan, netscan, handles, etc… Un buen rato después, no hemos podido encontrar nada malicioso en el equipo.
Miro de reojo a mi compañera, que está rebuscando furiosamente en los ficheros de log en busca de alguna pista, algún rastro que hayan dejado los atacantes, pero tampoco tiene éxito. Si la RAM o el triage no nos han dado resultado, nos va a tocar ir a por el disco duro.
Podemos tirar de Autopsy para la recuperación de datos, o hacer una línea temporal con Plaso, pero antes queremos comprobar una cosa: necesitamos ver el correo malicioso enviado con nuestros propios ojos. Localizamos el fichero .ost que almacena el buzón del usuario (la Organización tiene un Exchange corporativo sincronizado por MAPI con los clientes, por lo que en lugar de .pst tenemos .ost como almacenamiento de los correos).
Abrimos el fichero .ost con la utilidad Kernel OST Viewer y buscamos por el correo malicioso… de nuevo sin encontrarlo. Bueno, puede haber sido borrado. Al final un fichero .ost acaba siendo una especie de base de datos, y si no ha sido compactado podemos recuperar información con herramientas del estilo de OST Recovery Tool. Lanzamos la herramienta sobre el .ost extraído y el correo sigue sin aparecer.
“En igualdad de condiciones, la explicación más sencilla suele ser la más probable”, dice el principio de la navaja de Ockham. El correo no parece haber salido de este equipo (dejamos Autopsy corriendo para que nos busque otros ficheros borrados por si acaso), por lo que la siguiente opción es comprobar si ha sido enviado por otros medios.
María nos confirma que la Organización dispone de un OWA (Outlook Web App, un webmail corporativo), así como de un acceso de correo para los móviles corporativos vía ActiveSync. Sin embargo, el usuario afectado es de nivel administrativo y no tiene acceso a ninguno de los dos recursos (el OWA está detrás de una VPN para la que no tiene credenciales, y no tiene teléfono corporativo).
La investigación nos deja un único camino para investigar: el propio servidor de correo, un Microsoft Exchange 2010. El análisis, lo que encontremos (y lo que no), lo veremos en el siguiente artículo…
