En esta parte de la serie de artículos de creación de herramientas trataremos el montaje de una dropbox que podremos dejar abandonada en una red a la que queramos tener acceso.

SWORD es un portal web instalado en un pequeño dispositivo, normalmente un router, en el que puedes hacer un pivote y hacer ataques desde él mientras el equipo principal se puede dedicar a otras cosas.

Su funcionamiento puede recordar a la herramienta Packet Squirrel de Hak5 en cuanto al tamaño y finalidad, aunque difiere un poco en su forma de trabajar. Mientras que Packet Squirrel  se conecta entre un host y el hub de red y selecciona 1 de entre 3 payloads que tiene precargados vía switch físico, SWORD se conecta de la misma manera pero tiene todo lo necesario precargado de forma que es necesaria una conexión hacia él, ya sea vía red física o por un punto de acceso que creemos desde el dispositivo, aunque si usamos este último, no podremos utilizar algunos ataques Wifi como por ejemplo los destinados a WEP y WPA.

Siempre y cuando se instale el software necesario, con unos pequeños cambios en la instalación adaptados al dispositivo en el que lo estemos metiendo y según en qué casos, algún cambio en los archivos PHP del portal, SWORD es potencialmente instalable en cualquier cosa. En este artículo se tratará la instalación en un NEXX WT3020F, uno de los router para el que fue creado SWORD.

La herramienta no está libre de errores y alguna que otra vez suele colgarse, pero es un buen comienzo para alguien que quiera crearse un dispositivo de ataque barato, modificable para alojar nuevos programas, permite configurarlo al gusto y fácilmente modificable y actualizable.

Hardware necesario:

• NEXX WT3020F
• Memoria USB 8/16/32GB

Software necesario:

• OpenWRT
• Fdisk
• Soporte para USB y ext4
• Ettercap-ng
• Reaver
• TCPDump
• DSNiff (URLSnarff)
• Nmap
• Mdk3

El WT3020F es un router con memoria interna de 8MB y RAM de 16MB de pequeño tamaño (6,40 x 4,50 x 1,80 cm) que si bien se supone que debería ser suficiente para alojar SWORD y todas sus dependencias, pronto descubrimos que no lo es (quizás lo fuera en versiones beta), por suerte podemos arreglar ese inconveniente con la memoria USB. Como vamos a usar la memoria, los modelos H y AD también valen para crearnos nuestra dropbox.

Instalación:
Con OpenWRT instalado en nuestro dispositivo, y configurada su contraseña de root, conectamos el pendrive en el puerto USB y conectamos un cable de red desde nuestro router hasta el puerto WAN del NEXX para que tenga conexión a Internet, nos conectamos por ssh a su IP (normalmente 192.168.1.1) con permisos de root y ejecutaremos “opkg update” para actualizar nuestro NEXX y “opkg install bash –force-depends” (aunque esto último ya debería  estar instalado).
Muchos de los paquetes que necesita la herramienta no están disponibles porque son antiguos, así que hay que instalarlos a mano.

Con las órdenes:

Ahora al hacer “fdisk –l” en un apartado se nos debería listar la memoria USB que conectamos al principio de la guía, normalmente aparece bajo la ruta de montaje /dev/sda1

Para eliminar posibles problemas borraremos la partición antigua y crearemos una nueva y para eso seguiremos usando fdisk, dejo un par de capturas de pantalla con las órdenes y lo que muestra por pantalla.

Primero borraremos la partición:

Después crearemos una nueva:

Ahora formateamos en ext4:

Habiendo conseguido esto, el último paso para empezar a trabajar con el USB será crear un punto de montaje y montar la unidad.

Ahora podemos copiar el sistema de ficheros actual a la memoria USB, si hubiéramos usado el almacenamiento interno éste por sí solo no sería suficiente para almacenar todos los archivos de SWORD. Así tendremos más almacenamiento y obtendremos la ventaja de tenerlo todo en una memoria aparte, podremos extraerla sin más complicaciones y nuestro NEXX volverá a ser un router aparentemente normal, tanto a nivel físico como software.

Órdenes para la copia del sistema de ficheros:

mkdir -p /tmp/cproot
mount --bind / /tmp/cproot
tar -C /tmp/cproot -cvf - . | tar -C /mnt/sda1 -xf -- 
umount /tmp/cproot

Con esto ya tendremos copiado todo el sistema en el pendrive, y en el siguiente artículo procederemos a configurar nuestro router para que en el caso en el que detecte nuestra memoria externa, la monte y arranque desde ella y terminaremos la instalación del SWORD.

Para que sea más fácil, yo usaré “nano”, si sois más de “vi”, este paso os lo podéis saltar.

opkg install nano

Crearemos el fichero fstab para montar la memoria USB cuando arranque y usarla como root y lo guardaremos.

nano /etc/config/fstab

Crearemos la configuración inicial usando:

block detect > /etc/config/fstab

Editaremos el fichero, para que nos quede de esta manera:

Fe de erratas: no es “rw.sync”, es “rw,sync”

Una vez modificado el fichero, guardamos, y reiniciamos el dispositivo.

Una vez que arranque (si no lo hemos hecho bien, siempre podemos reinstalar OpenWRT de nuevo y empezar otra vez) veremos si nuestro trabajo tiene recompensa con:

mount

Y si usamos la orden “df” podremos ver de cuanto espacio disponemos

(Nota: Recordad que se ha instalado nano después del volcado del sistema de ficheros, así que nuestra memoria USB no tendrá ese programa)

Terminada esta parte, ya podremos empezar a trabajar en la instalación del SWORD.

Como no todos los programas son fácilmente instalables porque son válidos para versiones antiguas pero aún no se han probado o no se tiene interés en usarlos en las nuevas versiones, hay que ir al repositorio de OpenWRT e instalar los paquetes “.ipk”

No tiene mucho misterio la verdad, basta con ejecutar “opkg install http://archive.openwrt.org/barrier_breaker/14.07/ramips/mt7620n/packages/oldpackages/(PaqueteAInstalar.ipk) –force-depends”

Baste una imagen como ejemplo:

Usaremos –force-depends para forzar que si tenemos dependencias de otro software también lo instale, aunque hay que estar atentos ya que a veces falla y eso habrá que solucionarlo manualmente buscando nosotros el paquete en el repositorio e instalándolo.

De esta forma instalaremos ettercap-ng, reaver, tcpdump, url snarf, nmap, aircrack-ng y mdk3

Es posible que mucho software no lo encontremos, por que haya otro que ocupe su lugar como creo que es el caso de urlsnarf (yo instalé dsniff). En ese caso, SWORD no nos funcionará correctamente y habrá que modificarlo tocando su código para que llame adecuadamente al software.

De cualquier manera, aunque al final del todo tengamos una herramienta nueva, el fin de esta guía no es saber usarla, sino más bien montar unas bases para que en un futuro el usuario pueda montarse sus propias herramientas y arreglar los problemas que pueda tener en su creación.

Instalado todo lo necesario, solo queda descargarnos SWORD y vía scp copiar el fichero comprimido a nuestro router, conectarnos por ssh y una vez dentro, descomprimir los archivos y dar permisos.

Una vez que tenemos todo descomprimido, se nos habrá creado un directorio dentro de www llamado SWORD en el que tendremos toda la GUI que maneja gráficamente a la herramienta, ahora hay que dar los permisos necesarios a la carpeta para que no tengamos problemas en su uso. Borraremos el archivo comprimido para que no nos moleste.

Hecho esto, podremos ya podemos acceder tanto de forma interna como de forma externa.

Con la IP Interna, accediendo directamente desde la red que proporciona el NEXX.

Y accediendo a la IP que proporciona la red donde conectemos el NEXX.

En este punto ya tenemos una dropbox funcional que dejar conectada a cualquier puerto RJ-45.

Este es el final de la guía, pero no de nuestra dropbox, ya que tenemos almacenamiento que aprovechar podemos complementar nuestro SWORD con RESPONDER (https://github.com/SpiderLabs/Responder) de SpiderLabs o cualquier cosa que se nos ocurra.

Os esperamos en el próximo de la serie.

La entrada Laboratorio de hacking III: Nexx WT3020F SWORD aparece primero en Security Art Work.

Día típico de otoño, por la ventana solo se aprecia un cielo gris. Es el típico día en el que crees que no va a suceder nada extraño. De repente nuestro sistema de vigilancia alerta de unas conexiones anómalas: un equipo ha intentado conectarse contra unas direcciones IP de origen desconocido. Estas direcciones IP son públicas y, según la configuración establecida en la organización, toda conexión HTTP hacia el exterior debe pasar a través de un proxy.

Las conexiones se buscan en los registros del proxy y no se encuentran, por lo tanto este equipo ha intentado conectarse directamente, haciendo caso omiso a la configuración del sistema.

El horario en el que se producen las conexiones es desde las 06:52 am hasta las 07:09 am.

Además, se ve que no solo ha intentado comunicarse por el puerto 80 sino que lo ha intentado por otros puertos como el 139, 445 y el 97.

Surgen muchas dudas. ¿Habrá llegado a su buzón un correo con un adjunto capaz de evadir todas las barreras de la organización? ¿Habrá visitado una Web con un watering hole? ¿Habrá conectado un pendrive infectado?

El antivirus local de su equipo no ha detectado nada extraño.

En las investigaciones sobre esas direcciones IP no se encuentra gran cosa salvo que pertenecen a o Akamai,  o a una supuesta empresa de telecomunicaciones china:

Analizando la captura de tráfico se ve que no se ha producido una conexión efectiva:

Ahora toca averiguar porque se han producido esos intentos de conexión. Para ello se prepara una imagen de la memoria RAM del equipo y un triage con la herramienta CyLR.

Se comienza analizando la captura de memoria. Normalmente suelo consultar algún cheat sheet de Volatility, pero me he automatizado los comandos básicos para futuras ocasiones:

No se encuentra ni rastro de las conexiones ni evidencias que relacionen esos intentos de conexión en la imagen de la memoria.

Se procede a analizar la MFT con mftdump, exportando la información a formato CSV para una mejor lectura.

Acotando  por el día y las horas de las conexiones se ve la modificación de un fichero que llama la atención:

\Windows\System32\winevt\Logs\Microsoft-Windows-WPD-MTPClassDriver%4Operational.evtx

 Este log hace referencia a un driver MTP (Media Transfer Protocol). Con el visor de eventos de Windows se procede a analizar dicho Event Log:

Es entonces cuando entra en juego una nueva dirección IP que nada tiene que ver con el rango asignado por DHCP en la organización. Se vuelve a investigar en el volcado de la memoria ese rango de red.

Al buscar en los strings generados con Volatility el rango de red anterior:

Se puede ver un identificador. Parece ser que el usuario ha conectado un dispositivo usb.

En una búsqueda rápida en Google, en el primer link de la Web de Microsoft, especifica que se trata de un dispositivo de red por usb:

Una información con la que poder contrastar en los log DLP (Data Loss Prevention) del endpoint y ver qué tipo de dispositivo ha conectado:

Se trata de un dispositivo móvil de la marca Xiaomi, concretamente el modelo Mi 5.

Además, si se tiene activada la opción Usb Tethering, el dispositivo automáticamente se instala en el equipo y hace de punto de acceso para conectarse a Internet:

Como prueba trato de conectar este mismo modelo en un equipo con Windows y viendo la configuración de red se ve que el rango asignado por el terminal es familiar:

Esta práctica es bastante habitual cuando el usuario quiere saltarse las restricciones de un proxy en una organización, haciendo Tethering  y usando por ejemplo un navegador portable.

Una medida rápida para evitar este tipo de comportamiento sería deshabilitar la posibilidad de instalar automáticamente los drivers cada vez que se conecta un nuevo dispositivo:

Pero en un entorno corporativo muy grande puede dar problemas (incapacidad de conectar y usar impresoras, pendrives, etc.)

Por lo tanto existe una opción mucho más acertada que es imposibilitar el uso de dispositivos de red por usb. Para ello hay que modificar la entrada de registro:

Y modificar el valor “start” a 4.

Existe un problema, ya que si en el equipo nunca se ha conectado un dispositivo de red usb,  esta entrada de registro no existirá. La solución viene por crear de forma manual la entrada de registro:

Se crea un fichero.reg que contenga:

Y Ejecutar fichero.reg

Nota: El driver C:\Windows\system32\DRIVERS\usb8023x.sys no existe, pero en las pruebas que he hecho, no hace falta copiar tal fichero ya que con la sola entrada de registro de forma manual es suficiente.

La entrada Mi5terio resuelto aparece primero en Security Art Work.

Durante la gestión de casos forenses, hay veces que nos encontramos en un callejón sin salida, donde tras la detección de un indicador de compromiso de carácter crítico, nos toca abordar un análisis con evidencias poco sólidas.

Es por ello, que decidí llevar a cabo el desarrollo de una herramienta de carving que se basara en la detección con reglas Yara. Dicha herramienta también debía de manejar archivos en raw y ser capaz de llevar a cabo una gran variedad de opciones sobre estos datos de manera flexible, por lo que decidí utilizar Radare2.

De esta combinación nació YaraRET, una herramienta de carving de ficheros desarrollada en Go, cuya versión estable está disponible en el repositorio de YaraRules: https://github.com/Yara-Rules/YaraRET

La versión de desarrollo puede ser encontrada en el siguiente repositorio: https://github.com/wolfvan/YaraRET

Así pues, durante el siguiente artículo se va a exponer la resolución de un caso forense ficticio con YaraRET, el cual está basado en la combinación de varios casos que me he ido encontrando desde hace unos cuantos meses.

El caso

Imaginemos que se nos remite un equipo que, según nos informan, ha realizado una petición contra un dominio de APT33. La gestión del incidente parece no haber sido la más idónea, por lo que no puede descartarse que un posible atacante haya borrado sus huellas.

En cuanto al equipo, se trata de un sistema industrial que utiliza una versión de Windows XP para dispositivos embebidos, el cual trata información muy sensible y, es por esto mismo, por lo que el cliente nos solicita que extraigamos la mayor cantidad de información sobre el posible malware existente en el equipo, de cara a poder llevar a cabo una fase de erradicación total de la amenaza.

Tras un primer vistazo, encontramos un malware, el cual es de carácter genérico y no parece estar relacionado con la petición objeto del análisis forense. Los logs de la máquina han rotado y no tenemos pistas sólidas a las que agarrarnos.

Dado que en el repositorio de Yara Rules existe una gran variedad de firmas, desesperado, decido lanzar el set de reglas de APT33 contra todo el raw del disco.

Encontramos un match.

Breve inciso:

En el momento de la redacción del caso y su presentación en la r2con2018, la hipótesis principal era que el actor detrás de TRISIS era APT33. Ahora, en el momento de la redacción del artículo, nuevas fuentes apuntan a que pudiera haber sido APT28. Para mostraros YaraRET y su funcionamiento, es indiferente que haya sido uno u otro. Además, seguro que ha sido USA ;P

La herramienta

En este punto decido crear una herramienta muy sencilla que, utilizando los match reglas de malware de Yara y, utilizando otro set de reglas de magic numbers creadas ad hoc, lleve a cabo la detección y extracción de ficheros.

Así pues, al ejecutar la herramienta, ésta llevara a cabo la ejecución del ruleset de Yara indicado, y en caso de encontrar algún resultado, ejecutará el ruleset de magic numbers integrado en la herramienta, definiendo estructuras de datos, para, posteriormente dumpear el archivo.

Para optimizar la ejecución de la herramienta, se ha definido un intervalo de búsqueda de magic numbers, por lo que se incluye el parámetro de tamaño máximo.

El resultado es el siguiente:

Perfecto, hemos obtenido un fichero de tipo pyc, el cual, efectivamente, es malware asociado a APT33.

Sin embargo, tras indagar en su análisis, únicamente obtenemos que se trata de un módulo del malware.

Otro dato que podemos utilizar son los diferentes indicadores de compromiso que existen sobre TRISIS. Para ello, YaraRET incorpora la posibilidad de parsear direcciones IP y dominios para crear reglas Yara que posteriormente ejecutará contra el raw, del mismo modo que en el caso anterior.

De nuevo, únicamente hemos obtenido un resultado, y se trata del mismo archivo detectado con anterioridad.

Utilizando esta pista, podríamos tirar del hilo en una investigación con otras herramientas forenses más “al uso”. Sin embargo, el software de comunicación del sistema industrial está basado en librerías pyc, por lo que el número de archivos pyc se cuentan por centenares.

Era necesario que descartara, de algún modo, aquellos archivos legítimos, cosa que suponía llevar a cabo, no sólo la extracción “tonta” de ficheros, si no aplicar una correlación.

Hasta este punto, la prioridad de la herramienta era ser rápida, sin embargo, dado que era necesario mejorar la herramienta, decidí apostar por perder algo de tiempo en el inicio del análisis, de cara a definir las estructuras de todos los ficheros deseados y poder llevar acciones en dichas estructuras.

Es por ello que decidí desarrollar un modo shell.

 Cosa que veremos en el próximo capítulo ;)

La entrada YaraRET (I): Carving con Radare2 y Yara aparece primero en Security Art Work.

El equipo de S2 Grupo quiere compartir con todos los lectores de Security Art Work que el pasado lunes dio comienzo la 5ª edición del programa formativo insignia de S2 Grupo, ENIGMA.

El programa ENIGMA complementa la formación universitaria, focalizándose en la ciberseguridad, desde un punto de vista eminentemente práctico. Con unos cuantos años a sus espaldas, ENIGMA representa uno de los proyectos de referencia para los estudiantes universitarios, que tienen la posibilidad de aprender sobre el terreno, distintas disciplinas de la ciberseguridad.

15 jóvenes talentos que cursan sus últimos años, o recién licenciados, de carreras como Ingeniería Informática, de Telecomunicaciones e Industriales han sido seleccionados de entre los más de 150 inscritos.

El programa ENIGMA pretende formarlos en materia de ciberseguridad e inteligencia con la intención de ofrecerles, a posteriori, la posibilidad de incorporarse a nuestra plantilla como empleados.

Los alumnos reciben clases presenciales que imparten los empleados con más experiencia de S2 Grupo, disponen de una sala de formación y laboratorio con todo el material suficiente para que estudien, hagan las tareas que los profesores les asignen y fomenten su creatividad con diferentes actividades en grupo que se les proponen. Durante el proceso, aprenden sobre las distintas áreas de la ciberseguridad, que van desde conocimientos de defensa o ataque, hasta compliance, riesgos o cultura de S2 Grupo.

Adicionalmente, el desarrollo de su Trabajo Final de Enigma (TFE), equivalente a un TFG, les permitirá profundizar en aquellas motivaciones o inquietudes que vayan surgiendo durante su formación. El hecho de tener que presentarlo ante un tribunal, junto con la motivación personal de cada uno, hacen del TFE un proceso de aprendizaje, crecimiento y autosuperación, que refleja la cultura de empresa de S2 Grupo.

Al igual que en ediciones anteriores, el programa tiene una duración de 12 meses, complementando la formación impartida con unas prácticas de campo en los diferentes equipos de trabajo de S2 Grupo.

Con esta 5ª edición, S2 Grupo afianza su apuesta firme y decidida por los jóvenes que serán, en el futuro, auténticos profesionales de la ciberseguridad.

¡Bienvenidos a S2 Grupo y esperamos poder leeros por aquí!

La entrada 5ª edición del programa formativo de S2 Grupo: ENIGMA aparece primero en Security Art Work.

Hace ya un par de meses, el 27 de agosto de 2018, la investigadora de seguridad “SandboxEscaper” liberó un exploit de escalda de privilegios a SYSTEM para entornos Windows 10 64bits y que fue catalogada como CVE-2018-8440, con su consecuente parche en septiembre. Desde entonces sentía curiosidad por darle un vistazo al exploit y probarlo en otras versiones de Windows. Inicialmente, como es normal, no funcionó. Busqué por la red si existía alguna PoC modificada que lo hiciera, pero salvo algunos tweets con alguna pista, no encontré nada realmente funcional, así que me decidí a ver que se podía hacer. Después de echarle algunas horas y de varias broncas con la parienta, a continuación os muestro mi aproximación para portar el exploit a Win7, 8, 10, 2012 32/64bits, haciéndolo más generalista y estable que la versión original.

En primer lugar, vamos a ver en que consiste la vulnerabilidad y posteriormente el exploit. No voy a profundizar en ello ya que numerosos blogs ya han comentado el problema. Por último detallaremos la investigación realizada hasta llegar a hacer el exploit portable.

La vulnerabilidad permite a un usuario con mínimos privilegios (grupo USERS, no GUEST o al menos en win7 no lo he conseguido) invocar a la función _SchRpcSetSecurity publicada por el programador de tareas, a través de ALPC (protocolo utilizado para la intercomunicación entre procesos). Esta función lo que permite es establecer un DACL a un fichero de forma arbitraria, es decir cambiar los permisos. La única limitación es que el usuario SYSTEM debe ser capaz de escribir en él. Esto último es la clave para el exploit, ya que en las últimas versiones de Windows todo archivo (o casi todo) que viene de fábrica con el SO es tan solo el usuario TRUSTED INSTALLER el que tiene estas capacidades. Por lo tanto, tenemos que cambiar los permisos de algunos ficheros del sistema de forma arbitraria (un usuario plano puede), por ejemplo librerías .dll de “c:\windows\system32”.

Con esta “funcionalidad”, para producir el exploit y obtener una Shell de SYSTEM, lo único que hay que encontrar es una casuística donde se den todas estas situaciones al mismo tiempo:

• Encontrar una librería (dll) o un ejecutable (exe) candidato a poder ser sobrescrito donde SYSTEM tenga full Access (F).
• Esa librería no debe estar cargada en ninguno de los procesos actuales del sistema, o si lo está el usuario plano ha de ser capaz de matar el proceso. Esto es debido a que si tratamos de sobrescribir la dll y esta está siendo utilizada el SO, no nos dejará sobrescribirla, por muchos permisos que tengamos.
• Un proceso que arranque en el sistema con privilegios de SYSTEM ha de cargar dicha DLL para poder ejecutar el código que nosotros hayamos desarrollado en nuestra propia dll.
• Ese proceso de SYSTEM anterior ha de poder ser lanzado por el usuario plano, es decir hay que encontrar un “trigger” que haga cargar la dll.

El pseudocódigo del exploit a grandes rasgos será por tanto el siguiente:

1. Localiza la dll a sobrescribir
2. Llama a la función _SchRpcSetSecurity para que cambie los permisos de la dll victima
3. Reemplaza la dll con una arbitraria que nos permita obtener una Shell.
4. Ejecuta el disparador es decir arranca el proceso que cargará la nueva dll como SYSTEM.

Con esto claro, vamos a ver rápidamente el exploit de “SandboxEscaper” para ver como realizó todos estos pasos y porque solo funciona en Windows 10 64bits.

Nos vamos a centrar básicamente en el fichero fuente “ALPC-TaskSched-LPE.cpp” que es donde está “la harina” y más concretamente en la función main().

Paso 1. De lo comentado anteriormente, localizamos la librería a sobrescribir, en este caso PrintConfig.dll en el directorio DriverStore de System32

Aquí encontramos la primera clave por la cual el exploit solo va en Windows 10: “SandboxEscaper” encontró como proceso disparador (Paso 4 del pseudocódigo), el subsistema de colas de impresión (spoolsv.exe) el cual carga la dll PrintConfig.dll cuando se ejecuta la impresión de un trabajo/documento. Esta dll no se encuentra en operativos como Windows 7 u 8 por lo que buscarla en estos no nos funcionaría. Además, como veremos, si encontramos por ejemplo su hermana en Windows 7, esta no la carga el proceso SYSTEM sino el proceso de usuario plano. Hay que encontrar una alternativa…

A continuación crea un hard link en el directorio “C:\windows\Tasks” con el nombre de una tarea cualquiera (en este caso UpdateTask.job) y que apuntará a la dll a sobreescribir.

Paso 2. Ahora llama a la función vulnerable que nos permite modificar los permisos de esa dll.

En este momento el programador de tareas “seteará” el DACL que se ve en amarillo al fichero UpdateTask.job en “C:\windows\Tasks” y que por lo tanto apunta a la dll víctima.

Paso 3. En este punto tenemos que sobrescribir la dll. Para ello, lo que hace en el exploit original es dropear una dll que viene como recurso dentro del propio binario del exploit. Segundo kit de porque solo va en 64bits: si cambiamos la dll a una de 32bits, probablemente funcionaria para esta arquitectura.

De lo anterior, tan solo destacar que como hemos dicho, la dll objetivo puede estar cargada ya en algún proceso y por eso usa un bucle while para comprobar cuando se libera. Buena opción, pero podemos estar años esperando si la dll es utilizada por un proceso que no termine.

Paso 4. Por último se necesita llamar al proceso disparador. En este caso crea un trabajo de impresión (“Print Job 1”) usando una impresora que normalmente está instalada en el sistema como es “Microsoft XPS Document Writer”.

En este punto, si no recuerdo mal ya que no da el código de la dll que “dropea”, ejecuta un calc.exe como SYSTEM, con el cual no se puede interactuar con él. Veremos como lidiar con esto más adelante. Desde el punto de vista del pentester, lanzar un calc.exe no nos aporta mucho en una intrusión.

Hasta aquí el estado del arte, ahora veremos cómo portar el exploit a Windows 7, 8, 2012,10 en arquitecturas 32bits y 64bits.

Necesitamos poder disparar un proceso de SYSTEM desde un usuario plano. Dado esto, el primer impulso obviamente fue buscar tanto en las tareas programadas del sistema, como en los servicios que vengan por defecto en la instalación de Windows. En este caso no nos valen servicios/tareas de terceros tipo Lenovo/Intel/Nvidia, ya que es menos universal y requiere de ese software específico instalado. Comentar que sin este criterio hubiéramos acabado pronto ya que en los Lenovo rápidamente se encontró candidato.

En poco tiempo se identificó una nueva posible alternativa para Windows 7, tal y como encontró algún otro investigador como @wdormann en este tweet. El Servicio disparador en cuestión es “Windows CardSpace” el cual lanza como usuario SYSTEM el proceso .NET

“C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\Infocard.exe”

Este carga la dll siguiente y que como apreciamos en la imagen, es posible sobrescribir por permisos:

64bits

C:\Windows\assembly\NativeImages_v2.0.50727_64\mscorlib\0478aed7fc25ae268474c704fd2a3e0f\mscorlib.ni.dll

32 bits

C:\Windows\assembly\NativeImages_v2.0.50727_32\mscorlib\f8be9e33457f57805b4068f90099e428\mscorlib.ni.dll

El problema de este vector es que: necesita de la plataforma .NET V3.0 instalada, situación que a veces no nos hemos encontrado (Win 8); que el mencionado servicio esté presente (Cardspace), y por último que la dll no esté cargada por ningún otro proceso. Esta casuística hace que el vector no sea totalmente estable, por lo tanto se requiere algo más genérico y nativo.

La aproximación seguida para identificar nuevas dlls o exe candidatos fue utilizar las herramientas de sysinternals: accesschk y procmon. Con la primera establecimos un filtro para obtener todos los archivos con permiso de escritura para el usuario SYSTEM dentro de System32.

AccessChk>accesschk64.exe -w -s system c:\windows\System32 | findstr “.dll”

Tras algunas horas probando e identificando posibles candidatos, se identificó la siguiente dll.

C:\Windows\System32\DriverStore\FileRepository\wpdmtp.inf_x86_neutral_28f06ca2e38e8979\WpdMtp.dll

Como se aprecia en la captura, el usuario SYSTEM tiene permisos de acceso total “F”, por lo que ahora tenemos que ver si somos capaces de hacer que este elemento se cargue como SYSTEM desde usuario plano.

Para ello, primero hay que saber qué objetivo tiene la dll. Como se ve en la imagen, esta librería es la encargada de gestionar la transferencia de ficheros de dispositivos MTP (Multimedia Transfer Protocol) compatibles, cuando se conectan por USB. Es decir, cuando conectamos por ejemplo un terminal móvil al equipo, el proceso encargado de instalar los drivers (Drvinst.exe) carga esta dll y habilita el intercambio de datos multimedia. Este proceso se realiza por parte del usuario SYSTEM. Este vector tiene el hándicap de que se requiere acceso físico a la máquina para conectar el Smartphone. Pero este aspecto se podría evitar emulando vía software el dispositivo USB. Hay un framework de Microsoft que lo permite, no obstante no he llegado a profundizar en ello.

Por lo tanto en este punto tenemos tres formas o vectores diferentes para poder escalar privilegios:

• El servicio cardspace, valido para Windows 7, 8, 2008 (Enterprise R2) que tengan .NET v3 instalado. En Windows 2008 Standard SP1 no lo he conseguido explotar.
• El driver MTP, valido para 7, 8.
• El driver XPS printer original de Sandboxscaper para 8, 2012 y 10 (posiblemente 2016 también pero no lo he probado).

Por lo tanto combinando los tres cubrimos el espectro de soluciones más modernas de Microsoft en 32 y 64 bits, haciendo mucho más portable y estable el exploit. Vamos a comentar ahora un poco por encima los elementos que lo componen y como usarlo.

En el directorio raíz encontramos lo siguiente:

Dos dlls (32 y 64 bits ) que son los payloads que queremos cargar, es decir esta es la dll que sustituirá a la original, el exploit detecta la arquitectura y elige una de las dos. Todas las POCs vistas en este punto ejecutan una bonita calculadora que básicamente no sirve para nada en un pentesting, así que os dejo estas que crean un usuario administrador local con las siguientes credenciales:

• Usuario: mummy
• Pass: Mys3cretPass.

Ojo porque el payload está para la versión inglesa de Windows por lo que el grupo de administradores es “administrators”. En la carpeta cmddll podéis modificaros vosotros mismos la lógica y cambiarlo al español, solo tenéis que renombrarla a cmdll32.dll o cmdll64.dll respectivamente y dejarlas en el mismo path que el tsalpc.exe.

Un único exploit ejecutable de 32 bits (funcional en 64 bits también) encargado de ejecutar en orden los 3 vectores candidatos, en el momento que uno de ellos tiene éxito no procede con el resto.

La captura anterior es por ejemplo de un Windows 8 64 bits donde no presenta instalado el .net v3.0 y por lo tanto el servicio cardspace no está, por lo que el segundo vector (MTP) hace explotable la vulnerabilidad.

Podemos seleccionar un vector concreto pasándole como opción el nombre del candidato tsalpc.exe [cardman/mtp/printer], por ejemplo si solo queremos probar “cardman” sería de la siguiente manera.

> tsalpc.exe cardman

Si queremos que automáticamente realice un autopwn, tan solo llamamos al binario sin parámetros.

> tsalpc.exe

En el caso de que ninguna de las tres opciones fuera explotable, el exploit permite pasarle por parámetro el path del fichero que queremos sobrescribir, abriendo la puerta al lector a que descubra sus propias dlls candidatas o por ejemplo modificar los permisos sobre un fichero a su elección:

Un consejo, cuando ejecutéis el exploit, tratad de tener los menores aplicaciones y ventanas abiertas, esto minimiza la probabilidad de que las dlls candidatas hayan sido cargadas por algún proceso previamente.

Por lo que respecta a la detección antivirus, en los motores que se ha probado son:

• Windows Defender: detectado
• Symantec: no detectado
• Bitdefender: no detectado
• Trend Micro: no detectado

Os dejo adjunto en este post tanto los binarios como el fuente, Happy hacking. – Descargar exploit – (Contraseña: 12345)

La entrada Win7, 8, 10, 2008, 2012 32/64bits exploit programador de tareas vía ALPC (CVE-2018–8440) aparece primero en Security Art Work.

Como bien sabemos todos los que tenemos cierto interés en este sector, la robótica representa uno de los grandes progresos tecnológicos del S.XXI. No obstante, para que este avance se realice con garantías debe ir acompañado de un marco normativo transparente y dinámico que unifique y clarifique todas aquellas incertidumbres que la robótica genera. Sin embargo, nos encontramos con que hoy día no existe un marco normativo de estas características ni a nivel nacional,  ni europeo o internacional.

No obstante, sí hay dos referencias que vale la pena tener en cuenta.

En primer lugar, la recomendación del Parlamento Europeo [1] para el establecimiento de una serie de normas en materia de responsabilidad.  Al encontrarnos ante una posible “nueva revolución industrial” en la que la sociedad se ve abocada a una era de robots, bots, androides y otras formas de IA más avanzadas, resulta imprescindible que el legislador tenga en consideración las consecuencias que pueden originar el uso e implantación de dichos aparatos en nuestra vida cotidiana.

También, partiendo de la base de que no existe regulación alguna para este nicho de mercado, hemos de mencionar la norma ISO 13482, restringida al ámbito de los robots de cuidado personal. No obstante, este estándar no regula ningún tipo de responsabilidad, ni plantea cuestiones sobre el impacto que puede implicar en los derechos fundamentales el uso de los robots de cuidado personal.

Ahora bien, aunque no exista normativa ni en Europa ni en EEUU que regule la responsabilidad jurídica en el caso de error, mal funcionamiento, etc., del robot, siempre deberá existir un responsable de los actos o lesiones que pueda ocasionar éste con motivo de sus actuaciones. De ahí, que cuando se produzca un fallo o error, regirá la misma normativa que existe para otros productos defectuosos. Es decir: será de aplicación la normativa que establece la responsabilidad del fabricante [2].

No obstante, el problema lo encontramos cuando un fabricante lanza un producto cuyo software y programación lo ha llevado a cabo un tercero. En este ámbito, es preciso determinar hasta dónde llega la responsabilidad del fabricante. Si se le exige que el dispositivo desempeñe las tareas para las que ha sido creado con total certidumbre (es decir, que el robot funcione a la perfección y no implique ningún riesgo para la sociedad), se estará desincentivando el progreso tecnológico por exigir unos resultados demasiado precisos y restrictivos sin permitir un cierto margen de error y, por ende, la innovación se verá mermada. Por ello, haciéndonos eco de las palabras de Bertolini necesitamos “reglas alternativas que no castiguen tanto al productor del dispositivo” [3].

Como vemos, la respuesta jurídica ante controversias acaecidas con motivo de las tareas realizadas por un robot “inteligente” no es tan fácil y directa como con los robots “monofunción” puesto que, aunque apliquemos la Ley General para la Defensa de los Consumidores y Usuarios, los robots “inteligentes” probablemente puedan ser personalizados por el usuario con funciones y aplicaciones que a priori no estaban incluidas en el software del robot. Así, dicha personalización hará más complicado determinar la responsabilidad en el supuesto de fallo o error del robot, al ser más difícil identificar el elemento que ocasionó el mal funcionamiento.

Del mismo modo (y aunque a día de hoy no sea viable o próximo), llegará un día en el que los robots puedan aprender del entorno donde están inmersos, interactuar con éste y tomar decisiones no previstas en su configuración inicial; esto es lo que ha venido a llamarse la “teoría de las propiedades emergentes”. En este caso, sería todavía más complejo delimitar la responsabilidad, lo que está llevando a plantear si se debería limitar esa posibilidad de aprendizaje a través de algoritmos inteligentes y, ceñir el funcionamiento únicamente a las tareas o funciones diseñadas en origen, opción conocida como “code as law” o “regulation by design”.

Bajo mi punto de vista, si por prudencia delimitamos las capacidades que puedan tener los robots en el futuro y optamos por la regulación desde el diseño (no confundir con privacidad desde el diseño) estaremos restringiendo la evolución tecnológica y abocando, quizá, a la robótica a un futuro demasiado conservador que nos privará de muchos de los avances que están por llegar.

Referencias

• [1] Proyecto de Informe con recomendaciones destinadas a la Comisión sobre normas de Derecho Civil sobre robótica, 2015/2103 INL.
• [2] SÁNCHEZ, C., “Autómatas y ciborgs, territorio sin ley: ¿Quién paga si un robot comete un delito?”, El Diario.es, Hoja de Router, 2015
• [3] SÁNCHEZ DEL CAMPO REDONET, A., “¿Qué ocurre cuando un robot causa daños?“, Replicante Legal, 2016.

La entrada ¿Quién asume las responsabilidades ante errores cometidos por robots inteligentes? aparece primero en Security Art Work.

(Esta entrada ha sido elaborada por Juan Carlos Muria y Samuel Segarra.)

Y finalmente llegó: El Plan Estratégico Sectorial (PES) para el sector de la salud fue publicado a finales de octubre, y ahora llega el momento, para los operadores elegidos, de redactar el Plan de Seguridad del Operador (PSO) en menos de seis meses, sin olvidar que a continuación sólo habrá cuatro meses para detallar los Planes de Protección Específicos (PPE) para cada una de las infraestructuras críticas, y finalmente los Planes de Apoyo Operativo (PAO).

Esto es lo mínimo requerido por el Centro Nacional de Protección de Infraestructuras Críticas (CNPIC), como respuesta a las reuniones mantenidas y los correos intercambiados con los distintos operadores.

La estructura de estos planes viene definida por el propio CNPIC, con lo que hemos preferido poner el foco en las cosas que un operador del ámbito sanitario debe tener en cuenta, y ya que estamos en un blog y el contenido debe ser breve y concreto, hemos decidido destacar las 5 cosas más importantes, las que no deben faltar en un PSO ¿Comenzamos?

Lo primero es que el sector salud es muy amplio, y el propio CNPIC identifica 4 subsectores: Asistencia sanitaria, Salud pública, Medicamentos y Productos sanitarios, y Sanidad animal.

Lo segundo es que, como venimos diciendo hace tiempo, la protección de las infraestructuras sanitarias tiene una repercusión muy directa en la seguridad del paciente, por tanto, además de que el impacto de los riesgos que debemos evaluar resulta muy atractivo para los atacantes, para identificar bien las amenazas y cuantificar su impacto y probabilidad son necesarios unos conocimientos profundos del sector de la salud.

1. Debemos identificar infraestructuras y tecnología. La tecnología está cada vez más presente en el diagnóstico, el tratamiento y el seguimiento de los pacientes y por tanto el impacto de su indisponibilidad es grande, por lo que nuestro PSO debe enfocarse no solamente a las infraestructuras (seguridad física) sino también a la tecnología (seguridad de la información y seguridad operacional).
2. Los operadores sanitarios están ya hiperconectados. Las infraestructuras de salud no son un elemento aislado, intercambia datos y procesos con aseguradoras y mutuas, sanidad privada, fabricantes de tecnología sanitaria, telemedicina, colaboración entre hospitales, entre hospital y universidades, redes de farmacias, Seguridad Social, Hacienda, servicios sociales, dispositivos implantados en pacientes, etc. Esto incrementa la superficie de ataque y los vectores de contagio, con lo que es importante complementar el análisis de riesgos con esta visión de procesos.
3. Ningún plan es estático. Pero un PSO en un operador de salud lo es menos todavía. El impacto de la transformación digital en la atención sanitaria está sólo al principio, queda mucho camino por recorrer, y al mismo tiempo la atención sanitaria es un entorno VUCA (volátil, incierto, complejo y ambiguo), por lo que nuestro PSO debe estar preparado para que todas las piezas encajen. Como sabéis, debemos revisarlo cada dos años, pero en los próximos 2 años van a pasar muchas cosas que pueden obligar a revisarlo antes de tiempo… Y sí, seguramente también en los 2 siguientes ;-).
4. El papel del RSE (Responsable de Seguridad y Enlace) y el Delegado de Seguridad. Debemos tener en cuenta que el RSE representa al operador crítico, no a una infraestructura crítica en concreto. ¿Qué quiere decir esto? Que será el interlocutor ante la Secretaria de Estado de Seguridad para tratar las cuestiones relativas a la seguridad de las distintas infraestructuras del operador y los propios planes que se desarrollen. Asimismo, también será el punto de contacto para canalizar las necesidades informativas (y operativas) que puedan surgir. Por otro lado, el Delegado de Seguridad constituirá el enlace operativo y el canal de información con las autoridades competentes, sin embargo, en este caso su ámbito de actuaciones se ciñe a una infraestructura crítica particular. Naturalmente, deberá existir en todo momento una comunicación y coordinación fluida entre ambas figuras, para que la gestión de la seguridad se realice eficazmente.
5. La cultura se come a la estrategia para desayunar. Peter Drucker ya lo decía, y eso no quiere decir que la estrategia de seguridad no sea importante, sino que si falta cultura de seguridad (concienciación), la estrategia puede verse comprometida por la falta de concienciación de los usuarios. De la misma manera, el objetivo del PSO y los PPE no es quedarse en un cajón, por lo que es fundamental que los implicados (no sólo el RSE o el Delegado de Seguridad) estén familiarizados con los métodos y sistemáticas que se establecen para garantizar unos niveles de protección adecuados a este tipo de infraestructuras.

Sí, es verdad, existen otras cosas importantes, como la metodología de análisis de riesgos que vas a utilizar, la identificación de los servicios esenciales, la estimación del impacto que podría tener cada amenaza, etc., pero en esta entrada de Security Art Work queríamos destacar los aspectos más reseñables, que a menudo subestimamos a la hora de cuidar nuestras infraestructuras críticas y que, en el caso de la salud, son especialmente importantes.

Ahora que has llegado hasta el final, ¿cuál es el más importante para ti de todos ellos?

Enlaces relacionados

• LPIC y el RD que la desarrolla:
  • https://www.boe.es/buscar/pdf/2011/BOE-A-2011-7630-consolidado.pdf
  • https://www.boe.es/buscar/doc.php?id=BOE-A-2011-8849
• Guía de contenidos mínimos del PSO y PPE
  • https://www.boe.es/boe/dias/2015/09/18/pdfs/BOE-A-2015-10060.pdf
• Contenido adicional:
  • Algunos informes sobre Infraestructuras Críticas publicados por S2 Grupo: https://s2grupo.es/es/publicaciones-y-descargas/
  • Nota de prensa sobre la aprobación del PES para el sector salud: http://www.dsn.gob.es/es/actualidad/sala-prensa/comisi%C3%B3n-nacional-para-protecci%C3%B3n-infraestructuras-cr%C3%ADticas

La entrada Las 5 claves de un Plan de Seguridad del Operador para un servicio de salud aparece primero en Security Art Work.

En este artículo se analiza qué cambió en la saga de estándares ISO 27002 respecto de la continuidad de negocio.

Introducción

En este artículo se aborda el posible solape entre 2 disciplinas bastante relacionadas entre sí, aunque cada una con su área específica: la seguridad de la información y la continuidad de negocio. En particular, se analiza el grado en que los 2 estándares de referencia (ISO 27001 e ISO 22301) están, o no, solapados.

En un artículo aparte trataré las áreas de confluencia de ambos mundos y cómo puede llevarse a cabo la implantación de ambos estándares sin caer en redundancias innecesarias.

La razón de escribir este artículo se debe a que, en no pocas ocasiones, me han manifestado cosas como:

• “Si tengo un SGSI certificado, entonces ya tengo continuidad de negocio”
• “Para que una organización cumpla con los controles del capítulo 17 de la ISO 27002, basta con que tenga hecho un BIA y disponga de un DRP”

Las anteriores afirmaciones son, en mi opinión, incorrectas y se deben a diversas razones, entre las cuales, principalmente, se cuentan las siguientes:

1. Entendimiento incorrecto o limitado de en qué consiste realmente la continuidad de negocio.
2. El cambio que han tenido las normas ISO 27001/27002 al respecto.

La primera de estas causas es bastante habitual, ya que, a diferencia de otros países en los que la continuidad de negocio está muy extendida, en España hay muy pocos sectores, el financiero básicamente, que requieran su implantación. No pretendo, ni podría, solucionar esa carencia en un único artículo, aunque sí animo a consultar las excelentes publicaciones que sobre la materia se encuentran en este foro.

En cuanto a la segunda de las causas, analicemos primero el tratamiento que sobre la continuidad de negocio se ha venido haciendo desde las distintas versiones de los estándares ISO 27001 e ISO 27002, y cómo lo ahí plasmado se sigue arrastrando hasta la fecha, aunque lo que se pide ahora haya cambiado bastante.

Primero, retrocedamos unos años.

Antecedentes

La actual norma ISO 27002 data de 2013 en su versión en inglés, pero proviene de una larga estirpe de normas, algunas ya ISO, pero otras eran las venerables BS7799, la primera de 1999.

Pues bien, en todas ellas, llegando hasta la ISO 27002 de 2005, había un conjunto de controles de continuidad de negocio mediante los cuales se venía a requerir que la organización implantase algo parecido a una gestión de la continuidad de negocio. Por ejemplo, se solicitaba que:

• La organización contase con un marco de gestión completo de la continuidad
• Que se llevase a cabo análisis de impacto y también de riesgos
• Que se escribiesen planes de continuidad
• Que éstos se probasen regularmente

Así que los auditores, a la hora de verificar si estos controles estaban aplicados, solicitaban, por ejemplo, los BIAs, un Plan de contingencia y evidencias de que se hubiera probado en alguna ocasión.

No obstante, y es una opinión particular, los requisitos de continuidad de negocio plasmados en la 27002 eran un tanto confusos e incompletos.

Estas carencias venían suplidas por otras normas, en aquel entonces en formato de “British Standard” (las BS 25999-1/2), que sirvieron en gran medida de base para un nuevo estándar internacional de continuidad de negocio, la ISO 22301 de 2012.

Así que cuando tocó revisar la ISO 27002, ya no tenía sentido venir a solicitar lo mismo que ya se pedía en otra norma, por lo que su versión de 2013 introdujo cambios relevantes.

Situación actual

¿Y qué es lo que cambió? Al fin y al cabo, dirán muchos, se sigue pidiendo que haya continuidad de negocio, o eso es lo que parece, ¿no?. Lo cierto es que la cosa ha dado un giro interesante.

Vayamos al requisito de la propia norma: la sección 17.1, establece como objetivo que “la continuidad de la seguridad de la información debería formar parte de los sistemas de gestión de continuidad de negocio de la organización”.

Concretando un poquito más, se indica en el control 17.1.1 que “la organización debería determinar sus necesidades de seguridad de la información y de continuidad para la gestión de seguridad de la información en situaciones adversas, por ejemplo, durante una crisis o desastre”.

Pongamos un ejemplo: imaginemos el caso de un banco que decide abordar la continuidad de negocio, empezando por identificar las funciones de negocio a priori importantes para, a continuación, llevar a cabo los correspondientes BIAs. Supongamos que dentro de esas funciones están las áreas de Inversiones, atención al cliente, gestión hipotecaria, anti-fraude, etc.

Es más, el banco tiene una estrategia de contingencia perfectamente definida y, en caso de indisponibilidad de su sede central, dispone de unas oficinas alternativas a las que mover al personal esencial de esas funciones de negocio, con la infraestructura, comunicaciones y sistemas necesarios para recuperar la operativa en cuestión de unas pocas horas.

Sin embargo, este banco tiene desplegado un SIEM que monitoriza constantemente su infraestructura y operaciones, y un equipo de personas que atienden incidentes de seguridad internos y externos en régimen de 24×7, aparte de administrar y operar la infraestructura de seguridad (cortafuegos, AV, IPS, etc.). Este personal no tiene una ubicación alternativa asignada en las oficinas de contingencia, por no mencionar que tampoco están redundados algunos de los elementos de seguridad.

Como a veces pasa, estas tareas “TIC” no se han considerado, a priori, importantes, y no han sido analizadas, aunque lo cierto es que, de haberse hecho habrían visto que eran imprescindibles y que, por cuestiones operativas y de cumplimiento, el banco no puede funcionar sin el SIEM y sin el servicio de gestión de incidentes y gestión de la seguridad, ya que podrían dispararse los niveles de fraude, entre otras consecuencias indeseables.

Pues bien, esta organización no estaría cumpliendo con lo estipulado en la ISO 27002, porque no se ha hecho la pregunta elemental: “¿Qué impacto tendría que se interrumpieran las tareas del área de seguridad de la información?”.

No estamos diciendo que, necesariamente, haya que poner a la función de la seguridad de la información a la misma altura que la más crítica de las actividades de la organización, sino que debe ser incluida en el análisis, se deben definir estrategias capaces de cumplir con el RTO y RPO de dicha función, debe haber planes que aborden su recuperación, y debe formar parte del programa de pruebas de los preparativos de contingencia.

Así que, la cosa es bastante sencilla: para ver si una empresa cumple con los controles de la sección 17.1 de la ISO 27002:2013, miremos si se incluye la función de seguridad de la información dentro del listado de áreas organizativas a las que aplica la continuidad de negocio, aunque sólo sea para que lleguen a la conclusión de que, en caso de contingencia, pueden estar varios días sin el personal o sin las actividades y servicios que presta (que ya me resultaría extraño).

La entrada ¿Continuidad de negocio en un SGSI? aparece primero en Security Art Work.

Como ya adelantamos en el post donde se hablaba de él, dentro de la serie sobre la Comunidad de Ciberinteligencia rusa, el GRU (GU) es el más opaco de los servicios rusos, manteniendo casi intacta su herencia soviética frente a los “occidentalizados” FSB o SVR: de hecho, la estructura y funcionamiento del Servicio no ha sido especialmente conocida, siendo la principal referencia [1] hasta hace más bien poco. Más allá de datos puntuales de operaciones sin una atribución clara, o de las identidades de su Director y Directores Adjuntos -nada secreto-, poco o nada se sabía del Servicio. Sin embargo, y seguramente muy a pesar del GRU, en 2018 hay -hasta ahora- tres hechos que dan un giro radical a esta opacidad:

• El trece de julio el Departamento de Justicia estadounidense publica un documento donde se detalla la presunta implicación del GRU en las operaciones de interferencia durante las elecciones presidenciales estadounidenses en 2016.
• Por si esto fuera poco, el cuatro de marzo se produce el envenenamiento de Sergey Skripal y su hija Yulia en Salisbury (UK); el cinco de septiembre la propia Theresa May acusa formalmente ([2]) a dos supuestos miembros del GRU de dicha acción, en una declaración en la que se acaba hablando de Litvinkenko y del derribo del MH17 y en la que se incluye una frase muy significativa: It was almost certainly also approved outside the GRU at a senior level of the Russian state.
• Para rematar el annus horribilis del servicio, el cuatro de octubre el NCSC británico acusa públicamente al GRU de actividades de ciberespionaje contra la agencia WADA (World Anti-Doping Agency) o contra el DNC, entre otros objetivos [3]; además, con “high confidence”, que significa lo que significa… mientras que, casi en paralelo, el MIVD holandés acusa al GRU ([4]) de atacar, además de a diferentes organismos oficiales británicos, a la OPCW (Organisation for the Prohibition of Chemical Weapons) -que casualmente investigaba el envenenamiento de Skripal- en abril; citan a la unidad 26165 del servicio y la identifican directamente con APT28. El DoJ estadounidense no se queda atrás en las acusaciones contra el GRU, como veremos, y también se apunta a estas acusaciones oficiales el gobierno canadiense. En resumen, cuatro países “occidentales” -que además reciben el apoyo público de los socios australianos y neozelandeses, completando así los Five Eyes– acusan al GRU de ciberespionaje.

Sin duda, este protagonismo no debe haber gustado nada en el GRU, ya que ha llevado al Servicio a las portadas de diarios generalistas de todo el mundo; tanto es así que el 22 de noviembre se anuncia la muerte del General Igor KOROBOV, el mando del GRU, después de una “larga y seria enfermedad” (quizás agravada, que no causada, por alguna reprimenda de instancias superiores por todos los errores cometidos). Se habla inicialmente del General Sergey ALEKSANDROVICH GIZUNOV, Director Adjunto del GRU y persona de confianza del Presidente Putin, como posible sucesor al frente del Servicio, pero ese mismo día el Vicealmirante Igor KOSTYUKOV, hasta ese momento Director Adjunto Primero, asume las funciones de Dirección. El General GIZUNOV, además de Director Adjunto del GRU, es Doctor en Ciencias Técnicas, posiblemente informática o matemáticas, y proviene del aparato SIGINT del servicio ([5]); de hecho había sido hace unos años el Jefe de la Unidad 26165. Tras la muerte de Igor SERGUN, anterior Director del GRU, en enero de 2016, su nombre ya se barajaba entre los candidatos a sucesor (GIZUNOV ya era Director Adjunto), aunque finalmente se optó por KOROBOV: tal vez el GRU consideraba SIGINT como un aspecto puramente operativo, de apoyo a la estrategia del servicio y a la inteligencia global. En 2018, tras la muerte de KOBOROV, quizás siga opinando lo mismo… o quizás no.

A la vista de lo que ha sucedido este año, en 2018 el GRU ha pasado de ser considerado por muchos analistas uno de los mejores servicios del mundo a ver cómo se publican datos sensibles de sus operaciones, de sus oficiales, de sus intereses y capacidades… y que además ponen al descubierto unas medidas OPSEC más que pobres en sus acciones. De ser la élite de la inteligencia rusa, el GRU ha pasado en unos meses a centrar las críticas del Kremlin, de la oposición política y de los demás servicios de inteligencia rusos.

Vamos a tratar en la presente serie estos hechos que en los últimos meses han dado la vuelta a la percepción que muchos analistas tenían del GRU para, una vez vistos, determinar qué nueva información relativa a estructuras, personas, objetivos, tácticas, técnicas… han aportado directa o indirectamente a todos los que nos interesa conocer el ámbito ciber de los servicios rusos, en especial de la inteligencia militar.

Referencias
[1] Viktor Suvorov. Inside Soviet Military Intelligence. MacMillan Publishing Company, 1984.

[2] UK. https://www.gov.uk/government/speeches/pm-statement-on-the-salisbury-investigation-5-september-2018

[3] NCSC. https://www.ncsc.gov.uk/news/reckless-campaign-cyber-attacks-russian-military-intelligence-service-exposed

[4] MIVD. https://www.government.nl/latest/news/2018/10/04/netherlands-defence-intelligence-and-security-service-disrupts-russian-cyber-operation-targeting-opcw

[5] Russian Defense Policy. Still Awaiting New GRU Chief. Enero, 206. https://russiandefpolicy.blog/2016/01/23/still-awaiting-new-gru-chief/

La entrada (Ciber) GRU (I): Introducción aparece primero en Security Art Work.

El GRU, la Unidad Militar 44388, obtiene y procesa inteligencia de múltiples disciplinas, incluyendo IMINT, SATINT y por supuesto OSINT, con necesidades de información ligadas al ámbito militar, político, tecnológico, económico y ecológico/energético ([1]). Ya se indicó en el artículo dedicado al GRU, dentro de la serie relativa a la Comunidad de Ciberinteligencia Rusa, que la Sexta Dirección del GRU ha tenido históricamente las atribuciones SIGINT (COMINT y ELINT) del Servicio; una excelente descripción de estas atribuciones se encuentra en [2]; en la imagen, la estructura histórica  del GRU: 

La Sexta Dirección, directamente dependiente del Director Adjunto para Asuntos Técnicos del Servicio, se estructuraba en cuatro divisiones: 

• COMINT, coordinando todas las actividades COMINT del GRU y sus Regimientos de Transmisiones y responsable también de la red de interceptación del Servicio.
• ELINT, similar a la anterior pero para inteligencia de señales NO COMINT (ELINT y quizás TELINT).
• Apoyo Técnico, rama responsable de la operación y mantenimiento de las capacidades de interceptación del GRU alrededor del mundo, desde las ubicadas en embajadas o consulados hasta las grandes estaciones como Lourdes (Cuba).
• Monitorización SIGINT, operando y reportando al Puesto de Mando del Servicio, en 24×7, para monitorizar la situación militar en todo el mundo, en especial en USA.

Adicionalmente a la estructura de la Sexta Dirección, el GRU dispone de otras capacidades relacionadas con la inteligencia de señales, desde el Puesto de Mando del Servicio hasta el Departamento de Inteligencia Espacial; incluso podríamos hablar del robo de material criptográfico vía HUMINT, pero de todas estas capacidades adicionales son especialmente relevantes -por su cercanía al ámbito ciber- las siguientes:

• Servicio de Descifrado, que recibe y descifra comunicaciones adquiridas por el GRU en todo el mundo -en especial, de la rama de Apoyo Técnico- y que se ubica en Komsomolskiy Prospekt (Moscú) ([3]). Al contrario de lo que aparece en algunas publicaciones, este servicio no depende de la Sexta Dirección, sino que está directamente subordinado al Director del GRU.
• Centro Especial de Procesamiento del GRU (Spetsialniy Tsentr), que desde su sede en las afueras de Moscú procesa informáticamente -análisis, descifrado…- mediante sistemas soviéticos el enorme volumen de comunicaciones aportadas por la Sexta Dirección ([4]).
• Central Scientific Research Institute, en Moscú, responsable del diseño de equipamiento SIGINT para el GRU ([5]).
• Dirección Técnica Operacional, de la Dirección General de Asuntos Técnicos, independiente de la Sexta Dirección desde 1968 y que es responsable de investigación, desarrollo y obtención del hardware SIGINT del GRU.

Por último, y ya fuera de la estructura del GRU pero coordinados y apoyados por éste, cada una de las zonas militares terrestres o navales de la antigua URSS disponía de una Dirección de Inteligencia (RU) propia, y a su vez dentro de cada una de ellas se establecía un departamento -el Quinto Departamento-, responsable del reconocimiento radioelectrónico. Este Quinto Departamento se encargaba del análisis de la inteligencia de señales recogida por los Regimientos de Transmisiones y sus estaciones en cada una de estas zonas militares. En estos RU se elaboraba inteligencia operacional, por lo que su coordinación dependía tanto de la Sexta Dirección del GRU como de la Quinta Dirección del Servicio.

Referencias

[1] Roland Heickerö. Emerging Cyber Threats and Russian Views on Information Warfare and Information Operations. FOI. Swedish Defence Research Agency. Marzo, 2010.

[2] Desmond Ball. Soviet Signals Intelligence (SIGINT). Canberra papers on strategy and defence, no. 47. Strategic and Defense Studies Centre. Research School of Pacific Studies. The Australian National University. Canberra, 1989.

[3] Desmond Ball, Robert Windrem. Soviet signals intelligence (Sigint): Organization and management. Intelligence and National Security. Volumen 4, Issue 4. 1989.

[4] Karl Maria Michal de Leew, Jan Bergstra (Ed.). The History of Information Security: A Comprehensive Handbook. Elsevier. Agosto, 2007.

[5] Jeffrey Carr. Inside Cyber Warfare: Mapping the Cyber Underworld. 2nd edition. Ed. O’Reilly, 2011).

La entrada Ciber (GRU) (II): SIGINT histórica aparece primero en Security Art Work.

Como hemos dicho, si hasta este año el GRU era uno de los servicios más opacos del mundo, en 2018 todo cambia. Tres hechos destacan en la cronografía, que concluyen con la muerte del Teniente General KOROBOV en noviembre; vamos a ver en este apartado el primero de ellos -y en los sucesivos los dos siguientes-, ocurrido en el mes de julio.

El trece de julio el Departamento de Justicia (DoJ) estadounidense publica [1], un documento de acusación contra doce agentes del GRU -citados directamente con nombre y apellidos- a los que relaciona con una posible injerencia rusa en las elecciones presidenciales de 2016. Quien firma el documento es nada más y nada menos que Robert Mueller, asesor del DoJ que coordina las investigaciones sobre este ámbito -el de la relación de Rusia con la selecciones presidenciales estadounidenses- y que, entre otras cosas, fue director del FBI durante más de diez años. Tras esta acusación, el FBI incluye entre sus “Cyber most wanted” a los doce agentes del servicio, resaltando que pueden ir armados y son peligrosos; hasta ese momento, el único servicio ruso que tenía el privilegio de contar con agentes entre los más buscados por el FBI era el FSB.

La inteligencia estadounidense había señalado públicamente a sus homólogos rusos de  injerencias en el proceso electoral de 2016 ([2]), incluso ligando al GRU a los ataques directos y  a la publicación de la información exfiltrada. No obstante, en el documento del DoJ se entra al detalle y se señala a dos unidades del GRU -la 26165 y la 74455- como responsables directas de las actividades en el ámbito ciber dirigidas a la interferencia en dichas elecciones, marcando a la unidad 26165 como la operativa directa (ataques contra actores relevantes, por ejemplo vía spear phishing, robo de documentos, etc.) y a la unidad 74455 como actor significativo en las operaciones de desinformación asociadas, como la diseminación de documentos o correos electrónicos o el manejo del sockpuppet Guccifer 2.0. Los acusados por el DoJ son doce oficiales de inteligencia rusos, nueve pertenecientes a la unidad 26165 y tres pertenecientes a la unidad 74455, según se resume en la siguiente tabla:

Se identifica con detalle al personal de la unidad 26165, localizada en el número 20 de Komsomolskiy Prospekt, y de la unidad 74455, localizada en el número 22 de la calle Kirova, en el barrio de Khimki, en ambos casos en Moscú; también se dan detalles de cada una de estas unidades: están mandadas por un Coronel, cuentan con diferentes departamentos con tareas específicas (desarrollo de malware, operación de los zombies…) El documento de acusación del DoJ describe también las TTP de los atacantes con un nivel de detalle asombroso, así como fechas de acciones tan concretas como el implante de X-Agent en una víctima o el nombre de la persona que ejecuta dicha acción, en el marco de en operaciones del GRU contra el DCCC (Democratic Congressional Campaign Committee, Comité de Campaña Demócrata del Congreso) y el DNC (Democratic National Committee, Comité Nacional Demócrata). Igualmente, analiza con el mismo nivel de detalle los esfuerzos del actor hostil para persistir en la víctima o el manejo de la información robada y su difusión a través del entramado DCLeaks (sockpuppet, sitio web, redes sociales…) y Guccifer 2.0., así como la relación entre ambos. 

Tal y como hemos dicho, en todo momento, tanto en el ámbito técnico de la intrusión y persistencia como en el ámbito menos técnico del uso de la información robada, el nivel de detalle proporcionado por el DoJ es impresionante; sin entrar en si este nivel es habitual en las acusaciones del DoJ relativas a Seguridad Nacional -no tengo criterio-, desde luego desde un punto de vista de inteligencia dar tanta información del conocimiento sobre un adversario ni es habitual ni es bueno… También se dan, especialmente en octubre como veremos más adelante, niveles de detalle no habituales en fuentes públicas sobre tácticas, técnicas, identidades… de los agentes del GRU y de sus operaciones; veremos, al final del trabajo, algunas preguntas que nos hacemos en relación al por qué de este nivel de detalle -y sus posibles respuestas-.

Referencias

[1] DoJ. Julio 2018. https://www.justice.gov/file/1080281/download 

[2] ODNI. Assessing Russian Activities and Intentions in Recent US Elections. Enero, 2017.

La entrada (Ciber) GRU (III): julio 2018 aparece primero en Security Art Work.

Serguei Skripal era un agente del GRU que había sido detenido en el año 2004, acusado de colaborar con el MI6 británico y condenado por alta traición hasta que en 2010 fue canjeado por agentes rusos detenidos en el marco de la Operación Ilegales. Desde entonces vivía en Reino Unido, aparentemente alejado de cualquier actividad “molesta” ligada a su pasado como miembro del Servicio. Sin embargo, en marzo de 2018 aparece inconsciente junto a su hija Yulia -de visita en Reino Unido- en un banco de Salisbury, supuestamente víctima de un ataque con Novichok, un agente nervioso soviético, del que Reino Unido acusa a Rusia sin muchos más detalles.

A finales de junio dos británicos, un hombre y una mujer, son ingresados en el hospital del distrito de Salisbury; los había traído una ambulancia desde Amesbury, a pocos kilómetros de donde fueron envenenados el ex agente del GRU y su hija. La investigación confirma que han sido envenenados también con Novichok, aparentemente por accidente: ninguno de ellos tenía relación previa con lo sucedido en marzo y, posiblemente, encontraron por casualidad el agente nervioso en lo que parecía ser una botella de perfume abandonada en un parque. Al rociarse, se contaminaron; la mujer murió a principios de julio a consecuencia de los efectos de la contaminación.
El cinco de septiembre, como ya hemos indicado con anterioridad, Theresa May acusa a dos ciudadanos rusos, miembros del GRU, del envenenamiento de los Skripal ([1]); públicamente se indica que Alexander PETROV y Ruslan BOSHIROV (aliases según la propia policía británica) viajaron a Reino Unido desde Rusia, impregnaron Novichok en un tirador de puerta, se deshicieron del veneno y regresaron a Moscú, aportando como pruebas numerosas capturas de cámaras de seguridad. Se les acusa de conspiración, intentos de asesinato, posesión y uso del agente nervioso… pero la propia Theresa May es consciente de la dificultad de la extradición de estos ciudadanos -quizás por la experiencia adquirida durante el caso Litvinenko-.

La reacción y negación rusas no tardan en llegar, e incluso RT realiza una entrevista a los dos acusados en la que se identifican como profesores de fitness que habían ido a Salisbury a disfrutar de su catedral, y por supuesto niegan toda relación el con GRU. No obstante, investigaciones independientes, en este caso de Bellingcat, defienden con material gráfico, hechos supuestamente contrastados y datos concretos que los dos individuos acusados por Reino Unido no son dos inocentes profesores llamados Ruslan y Alexander, sino que se trata en realidad del Coronel Anatoly CHEPIGA, miembro de las Fuerzas Especiales del GRU, y del Doctor Alexander YEVGENIYEVICH MISHKIN, Coronel o Teniente Coronel del Servicio. Ambos ostentan el título de Héroe de la Federación Rusa, el más alto de los que se pueden recibir en Rusia y que es otorgado directamente por el Presidente de la Federación Rusa.

Anatoly VLADIMIROVICH CHEPIGA

Alexander YEVGENIYEVICH MISHKIN

Por supuesto, estas acusaciones particulares -no confirmadas por el gobierno británico- han sido rebatidas por Rusia, que ha intentado desprestigiar a organizaciones como Bellingcat acusándoles de estar al servicio -y al sueldo- de los enemigos de la Madre Rusia; sea esta acusación cierta o no, la realidad es que los parecidos físicos son asombrosos y no se ha visto nunca a Alexander PETROV y Ruslan BOSHIROV junto a Anatoly VLADIMIROVICH CHEPIGA y Alexander YEVGENIYEVICH MISHKIN. Como también es cierto que el 19 de diciembre de 2018 el Departamento del Tesoro estadounidense emite un comunicado oficial ([2]) sancionando a varias personas, algunas de ellas ligadas al GRU, entre las que se encuentran los nombres de Anatoly VLADIMIROVICH CHEPIGA (asociado a la identidad Ruslan BOSHIROV) y de Alexander YEVGENIYEVICH MISHKIN (asociado a la identidad Alexander PETROV)… una notificación oficial que parece confirmar las investigaciones de Bellingcat.

Referencias

[1] Gobierno UK. Septiembre 2018. https://www.gov.uk/government/speeches/pm-statement-on-the-salisbury-investigation-5-september-2018

[2] US Department of the Treasury. Notice of Intended Removals; Ukraine-/Russia-related Designations; Cyber-related Designations. Diciembre 2018. https://www.treasury.gov/resource-center/sanctions/OFAC-Enforcement/Pages/20181219_33.aspx

La entrada (Ciber) GRU (IV): septiembre 2018 aparece primero en Security Art Work.

Si 2018 ya era un mal año para el GRU, el día cuatro de octubre diferentes países occidentales dan la puntilla final al Servicio publicando información de sus operaciones y agentes: se trata de Holanda, Reino Unido, Canadá y Estados Unidos -e inmediatamente Australia y Nueva Zelanda apoyan, como es normal, a sus aliados-; resumiendo: Holanda y FVEY rematan el annus horribilis del Servicio, como vamos a ver en este post.

Holanda

El día cuatro de octubre la inteligencia militar holandesa, el MIVD (Militaire Inlichtingen- en Veiligheidsdienst) publica en rueda de prensa ([1]) la operación ejecutada en abril en la que se identifica y expulsa del país a cuatro miembros del GRU acusados de atacar a la Organización para la Prohibición de las Armas Químicas (OPCW); al igual que hizo el Departamento de Justicia estadounidense en julio, proporciona todo lujo de detalles sobre las identidades, técnicas, medidas de seguridad, objetivos… de los agentes del GRU actuando en suelo holandés con pasaporte diplomático. Según esta información, cuatro agentes del Servicio (dos adscritos a la Unidad 26165, Aleksei SERGEYEVICH MORENETS y Evgenii MIKHAYLOVICH SEREBRIAKOV, y dos adscritos posiblemente a la Unidad 22177, Alexey VALEREVICH MININ y Oleg MIKHAYLOVICH SOTNIKOV) aterrizan el 10 de abril en Holanda y son recibidos por personal de la Embajada Rusa en este país, alquilan un coche y ejecutan una operación de proximidad (close access) para intentar comprometer la seguridad de la OPCW. Son identificados, se les incauta dinero en metálico y equipamiento técnico (que por supuesto es analizado al detalle, mostrando datos de otras operaciones) que incluye dispositivos para atacar redes inalámbricas y son acompañados a un avión de Aeroflot que los devuelve a Rusia. Ante las graves acusaciones holandesas, Rusia defiende que sus agentes simplemente realizaban una inspección de seguridad en la embajada del país en Holanda.

Reino Unido

El NCSC (National Cyber Security Center), dependiente del GCHQ británico, propina también el cuatro de octubre un nuevo y duro golpe al GRU [2]: como hemos dicho con anterioridad acusa al servicio ruso, directa y abiertamente, de diferentes ciberataques, entre ellos contra la agencia anti dopaje WADA o el DNC estadounidense; sin el despliegue de pruebas de los holandeses, los británicos acusan al GRU -y lo identifican directamente con APT28- de ataques contra la Agencia Internacional Anti Dopaje (World Anti Doping Agency, WADA), el DNC, infraestructuras críticas de Ucrania o la Organización para la Prohibición de Armas Químicas (Organization for the Prohibition of Chemical Weapons, OPCW). En todos los casos se explicita “NCSC assess with high confidence that the GRU was almost certainly responsible”: esta elevada confianza en sus afirmaciones hace que el gobierno británico acuse directamente al Kremlin de estos ataques; se indica además que el NCSC seguirá trabajando con sus aliados para sacar a la luz las actividades y los métodos del GRU (frase especialmente significativa).

USA

Ese mismo día el Departamento de Justicia publica una nueva acusación contra agentes del GRU; en esta ocasión se identifica a siete agentes del Servicio, cuatro de los cuales son los expulsados de Holanda en abril y los tres restantes habían sido identificados en julio por el mismo Departamento. En la siguiente tabla se muestra el resumen de estas identidades:

El Departamento de Justicia acusa ([3]) a todos ellos de ataques, además de a empresas como WestingHouse Electric Company, a organizaciones anti doping como la WADA, de la que ya hemos hablado, la USADA (US Anti Doping Agency) o el CCES (Canadian Centre for Ethics in Sport), entre otros; en especial, y de ahí el asunto de la orden de detención emitida por el FBI que se muestra en la imagen, el GRU aparentemente se focalizaba en el ataque a este tipo de organizaciones ligadas al deporte, quizás a raíz de las acusaciones contra Rusia de dopaje sistemático de sus atletas y su impacto en las olimpiadas de Rio de Janeiro de 2016.

Canadá

Por último, en la misma jornada Canadá también se suma a las acusaciones oficiales contra el GRU manifestando de forma pública ([4]), aunque de manera más escueta que el resto de países, que el Servicio ruso, de nuevo identificado con APT28, ha atacado a la WADA -con sede central en Canadá- y al Canadian Centre for Ethics in Sport, y responsabiliza también al GRU de los ataques a la OPCW en Holanda, apoyando así a sus aliados. Todo ello, como en casos anteriores, con high confidence, Por este motivo, el gobierno canadiense considera al gobierno ruso directamente responsable de una violación de las leyes internacionales y de las normas establecidas.

Referencias

[1] Ministerio de Defensa de Holanda. GRU close access cyber operation against OPCW. Octubre, 2018. https://english.defensie.nl/binaries/defence/documents/publications/2018/10/04/gru-close-access-cyber-operation-against-opcw/ppt+pressconference+ENGLISH+DEF.pdf

[2] NCSC. Octubre 2018. https://www.ncsc.gov.uk/news/reckless-campaign-cyber-attacks-russian-military-intelligence-service-exposed

[3] DoJ. U.S. Charges Russian GRU Officers with International Hacking and Related Influence and Disinformation Operations. Octubre, 2018. https://www.justice.gov/opa/pr/us-charges-russian-gru-officers-international-hacking-and-related-influence-and

[4] Gobierno de Canadá. Canada identifies malicious cyber-activity by Russia. Octubre, 2018. https://www.canada.ca/en/global-affairs/news/2018/10/canada-identifies-malicious-cyber-activity-by-russia.html

La entrada (Ciber) GRU (V): octubre 2018 aparece primero en Security Art Work.

La información que ha visto la luz durante 2018, tanto la oficial de los gobiernos de Reino Unido, Estados Unidos, Holanda y Canadá, como la no oficial de investigaciones adicionales, tanto particulares como de diferentes organizaciones (destacando a Bellingcat y RFE/RL, Radio Free Europe/RadioLiberty) ha expuesto mucha información interesante del GRU. Nos ha facilitado datos de sus unidades (identificación, estructura, funciones, ubicación física…), de personas que forman parte del servicio (identidades, empleos, funciones, aliases, relaciones, ámbito personal…) y de sus operaciones (objetivos, TTP, software, artefactos, IOC…). Adicionalmente, han puesto de manifiesto unas medidas deficientes de seguridad operacional, medidas que han permitido ampliar más si cabe las investigaciones iniciales y han sacado a la luz identidades, domicilios particulares, relaciona familiares… de miembros -o antiguos miembros- del GRU.

De todas las investigaciones realizadas a partir de los datos publicados por diferentes gobiernos, destacan las realizadas por Bellingcat, organización que investiga temas basándose principalmente en fuentes abiertas. Estamos hablando ahora de investigaciones privadas, no refrendadas por gobiernos y basadas sobre todo en OSINT, algo radicalmente diferente a las declaraciones de un gobierno con material probatorio que, por supuesto, no ha sido obtenido de fuentes públicas -ya hablaremos de dónde puede provenir esta información-. Incluso podemos dudar de la credibilidad de estas fuentes, ya que hay muchas voces que defienden que todo lo que publican es mentira, un montaje de Occidente, etc. Quién lo sabe… Estas investigaciones están basadas en fuentes abiertas e insistimos en que Bellingcat es una organización privada y por tanto sus investigaciones también lo son; pero el 19 de diciembre de 2018, como hemos adelantado anteriormente, el gobierno estadounidense ([1]) parece refrendar de manera oficial una de las principales investigaciones de Bellingcat, la que identifica como dos miembros del GRU, Héroes de la Federación Rusa, a las personas que intentaron asesinar a los Skripal en marzo: a partir de los detalles publicados por el gobierno británico sobre las identidades falsas de los agentes del GRU que envenenaron a los Skripal (Alexander PETROV y Ruslan BOSHIROV), Bellincat publicó en el mismo mes de septiembre y principios de octubre diferentes artículos, como [2], que mostraban las identidades reales de los sospechosos y confirmaba su relación con el GRU. 

En cualquier caso, mucho más interesante para nosotros es la relación de miembros o antiguos miembros de la Unidad 26165 del Servicio ([3]), publicada el mismo día cuatro de octubre, en el que diferentes gobiernos remataron el mal año del GRU; ese mismo día, a partir de las identidades de los miembros de la Unidad sacadas a la luz por la inteligencia holandesa, Bellingcat realiza un rastreo en fuentes públicas y semipúblicas e identifica a más de 300 miembros de la Unidad gracias a las direcciones de registro de sus automóviles, que coincidían con la sede del Servicio. En la RuNET existe información privada de ciudadanos rusos -domicilios, matrículas, números de teléfono- a disposición de cualquier usuario de Internet (no entramos a comprar bases de datos en el mercado negro, que también sería posible); a partir de una identidad (por ejemplo un nombre, ligado a una fecha de nacimiento o a la dirección de la Unidad) y con un poco de tiempo es posible obtener datos personales, e igualmente posible identificar, por ejemplo, a personas que han registrado un vehículo en una determinada dirección. De esta manera, Bellingcat asocia a esos potenciales miembros de la Unidad 26165 -o antiguos miembros, o personas que han tenido relación con la Unidad- y extrae nombres, matrículas, direcciones personales, perfiles de redes sociales, en lo que se considera una de las más importantes fugas de información de la historia.

Sin ser Bellingcat, con un poco de tiempo y usando Google Translate para los que no sabemos ruso, cualquier usuario de Internet puede llegar a esos mismos datos personales, encontrando relaciones más que interesantes; por supuesto, es necesario considerar la fiabilidad de las fuentes, aunque los datos que directamente hemos podido contrastar apuntan a que, al menos en su mayor parte, la información extraída es cierta. Hablaremos en otro momento del rastreo OSINT en la RuNET, pero en los siguientes apartados abordaremos lo que hemos aprendido del GRU durante 2018: parte de su estructura ciber, algunos de sus objetivos, diferentes TTP de sus operaciones y ciertas consideraciones OPSEC que quizás debían haberse tenido en cuenta antes de abordar una operación close access.

Referencias

[1] US Department of the Treasury. Notice of Intended Removals; Ukraine-/Russia-related Designations; Cyber-related Designations. Diciembre 2018. https://www.treasury.gov/resource-center/sanctions/OFAC-Enforcement/Pages/20181219_33.aspx

[2] Bellingcat. Skripal Suspects Confirmed as GRU Operatives: Prior European Operations Disclosed. Septiembre, 2018. https://www.bellingcat.com/news/uk-and-europe/2018/09/20/skripal-suspects-confirmed-gru-operatives-prior-european-operations-disclosed/

[3] Bellingcat. 305 Car Registrations May Point to Massive GRU Security Breach. Octubre, 2018. https://www.bellingcat.com/news/2018/10/04/305-car-registrations-may-point-massive-gru-security-breach/

La entrada (Ciber) GRU (VI): y ahora, ¿qué? aparece primero en Security Art Work.

La Unidad 26165 (85th Special Service Center) se ubica en el número 20 de Komsomolskiy Prospekt; en esta misma dirección se ubica la Unidad Militar 06410 (152nd Training Center), con Koval NIKOLAY NESTEROVICH al mando y creada el 27/08/1943; aparentemente esta segunda unidad no está relacionada con el ámbito ciber desde un punto de vista técnico, encontrado información disponible en fuentes públicas de artículos o tesis relacionadas con la enseñanza militar, psicología, etc.

En la época soviética, en el número 20 de la Avenida Komsomolskiy de Moscú se localizaba al Servicio de Descifrado del GRU, al que ya hemos hecho referencia, íntimamente relacionado con la Sexta Dirección (SIGINT) pero no dependiente de él; de hecho, ese histórico Servicio de Descifrado es aparentemente la propia Unidad 26165, creada el 23 de mayo de 1953 según fuentes abiertas. Existe información pública que aparentemente confirma su existencia al menos en 1958, como la medalla conmemorativa del 60 aniversario de la Unidad que se muestra a continuación: 

La “propuesta de racionalización” adjunta también muestra actividad de esta unidad en los años 70 del siglo pasado: 

El concepto de “Rationalization Proposal” en la antigua Unión Soviética hacía referencia a conceptos técnicos que son innovadores y útiles para una organización porque suponen un cambio en diseños, tecnologías, maquinarias, materiales… Si la propuesta era aceptada tras una evaluación, al autor se le facilitaba un certificado como el anexo a efectos de propiedad intelectual.

El Coronel Jefe de la Unidad era, hasta principios de 2018, Viktor BORISOVICH NETYKSHO. Parte de la información sobre unidades militares es pública en Rusia; por ejemplo, en RusProfile (http://www.rusprofile.ru/), una página donde se recoge información sobre entidades jurídicas y empresarios rusos, podemos llegar a la información abierta de la Unidad 26165, como su fecha de fundación a la que ya hemos hecho referencia; según esta página su actual Comandante es el Coronel Dmitry ALEXANDROVICH MIKHAILOV, desde enero de 2018.

La Unidad 26165 se encarga de las actividades CNE y CNA en las acciones identificadas durante 2018; es una unidad técnica, de ataque y explotación, que desarrolla herramientas y capacidades ofensivas y que además ejecuta operaciones usando estas mismas capacidades, con dos grupos diferenciados: la acusación de Robert Mueller identifica, en relación a la Unidad 26165, a un grupo operativo, mandado por ANTONOV y que se encarga de ejecutar los ataques -intrusión, persistencia, etc.-, y un grupo de soporte y desarrollo, mandado por MORGACHEV y que es el responsable de facilitar infraestructura y herramientas al primero; la estructura definida en la acusación es la siguiente: 

Las acusaciones holandesas añaden como miembros de la Unidad a Aleksei SERGEYEVICH MORENETS y a Evgenii MIKHAYLOVICH SEREBRIAKOV, quienes junto a los agentes de la Unidad 22177 fueron interceptados en La Haya, sin estar definido a cuáles de los grupos anteriores pertenecen aunque aparentemente, por el tipo de actividad que estaban desarrollando, estarían bajo el mando de ANTONOV.

Con las informaciones que hemos conocido durante este año 2018 podemos ponerle cara -y nombre, y empleo…- a supuestos miembros de APT28; cuando diferentes informes han hablado de las horas de compilación del malware, en horario laboral de Moscú y San Petersburgo, podemos imaginarnos a MORGACHEV y su grupo, mientras que cuando se han identificado campañas contra diferentes objetivos entran en juego ANTONOV y los suyos; por supuesto, la estructura y las identidades anteriores son parciales: la Unidad 26165 es mucho más compleja y amplia de lo que hemos conocido en 2018.

La entrada (Ciber) GRU (VII): estructura. Unidad 26165 aparece primero en Security Art Work.

Aparentemente la Unidad 74455 está ligada a operaciones de desinformación, influencia, propaganda… lo que volvería a confirmar el amplio concepto de information warfare de la doctrina militar rusa, al que ya hemos hecho referencia en repetidas ocasiones y la mezcla del ámbito puramente técnico con el ámbito psicológico (dezinformatsiya, spetspropaganda, kompromat…). De hecho, la DIA estadounidense habla de la confrontación de información rusa (informatsionnoye protivoborstvo, IPb) como el término usado por el gobierno para el conflicto de la guerra de información, con dos grandes medidas: técnica, como una CNO clásica, y psicológica, como el intento de manipular a la población a favor de los intereses rusos ([1]), hablando abiertamente de PSYOP “ciber”; la primera de estas medidas correspondería a la Unidad 26165 y la segunda a la Unidad 74455.

Existe muy poca información disponible en fuentes abiertas en relación a la Unidad 74455; su relación con el ámbito tecnológico puede confirmarse con algunas referencias científicas (artículos y libros). Por ejemplo, en la revista “Sistemas de control y medición de información”, aparece el nombre de E.E. Nazarov, como científico y empleado de la Unidad Militar 74455; esta identidad ha participado en dos artículos: “Algoritmo para generar interferencia tipo basada en la evaluación rápida de parámetros de señal” y “Métodos para estimar los errores en la determinación de las coordenadas del portador de radar aerotransportado por un sistema RTR distribuido espacialmente”. Aunque ambos títulos hayan sido traducidos del ruso mediante sistemas de traducción automática (gracias, Google ;) y quizás no sean correctos en su totalidad, podemos intuir que personas de esta Unidad trabajan en temas como el jamming (y el anti jamming) de señales; dicho de otra forma, guerra electrónica. También se referencia a esta unidad, en concreto a Mikhail Alekseevich Eremeev como Director de Departamento en la Unidad y Doctor en Ciencias Técnicas, coautor de varios libros y artículos científicos sobre criptografía; sin saber si son o no comunes el nombre y los apellidos, alguien con esta misma identificación es además -o ha sido- profesor en el Departamento de Tecnologías de Instrumentos Especiales de la Universidad Tecnológica de Moscú y miembro de la Junta Editorial de la publicación “Actas de la Academia Espacial Militar A.F. Mozhaisky”.

La unidad se ubica, como hemos dicho antes y según la acusación de Mueller, en el número 22 de la calle Kirova, en el barrio de Khimki, Moscú, en el edificio conocido como “La Torre”, aunque en alguna referencia -muy posiblemente a efectos administrativos- se cita directamente a Khoroshevskoe, 76, la dirección del GRU (el famoso “Acuario”). Mueller identifica únicamente a tres miembros de la Unidad, según el siguiente organigrama:

La Unidad 74455 utilizaba en beneficio de los intereses rusos la información robada por la Unidad 26165, según la acusación de Mueller. En otras palabras, se encarga de las operaciones psicológicas “ciber”, según la nomenclatura de la DIA citada con anterioridad: maneja la información que la Unidad 26165 roba de sus objetivos, para lo que establece y mantiene una infraestructura tecnológica (perfiles en redes sociales, sitios web…) con la que explotar esta información. Por ejemplo, es responsabilidad de esta Unidad el manejo de los sockpuppets Guccifer 2.0 o DCLeaks mediante identidades falsas, conexiones anonimizadas, puesta en marcha y operación de sitios web, etc.

Referencias

[1] DIA. Russia Military Power. Building a Military to Support Great Power Aspirations. 2017.

La entrada (Ciber) GRU (VIII): estructura. Unidad 74455 aparece primero en Security Art Work.

Comentaban unos alumnos del curso de análisis forense hace unas cuantas semanas la dificultad de conseguir experiencia en forense y respuesta ante incidentes, no sin parte de razón. En muchas ocasiones yo comparo, salvando las obvias distancias, el trabajo de DFIR (Digital Forensics and Incident Response) con el de un bombero: gran parte del tiempo de relajación mezclado con una pequeña parte de tiempo de intensidad y stress máximos.

Aquí estamos, sin embargo, no siendo del todo exactos: ¿qué hacen los bomberos cuando no se deslizan por el tubo y salen corriendo a salvar gente? La respuesta es muy sencilla: ENTRENAN.

En el mundo DFIR el entrenamiento es fundamental, ya que en muy pocos trabajos se está el 100% del tiempo “en harina” (hay que tener en cuenta que estar en un incidente a máxima capacidad de trabajo durante un periodo largo de tiempo cuesta, y mucho). El entrenamiento, además, permite detectar carencias y áreas de mejora, así como afianzar conceptos y aprender nuevas formas de hacer las cosas.

Una forma sencilla de entrenarse en DFIR es jugando retos forenses (tenéis una buena pila en http://aboutdfir.com/challenges-ctfs/). Aprovechando que tenía un fin de semana entero disponible, decidí sacar del cajón de retos; uno al que le tenía echado el ojo desde hace un par de meses: el reto DFIR de la DEFCON 2018.

El reto consta de tres imágenes de equipos, cada uno con tres niveles de preguntas (básico, avanzado y experto). Aquí tenéis los datos básicos por si queréis jugarlo:

• URL del reto : https://defcon2018.ctfd.io/
• Imágenes: https://www.hecfblog.com/2018/08/daily-blog-451-defcon-dfir-ctf-2018.html
• Passwords: HR:tacoproblems; File Server:tacotunities; Desktop: viviaalpastortacos

A lo largo de tres artículos vamos a ir contando mi solución al reto. En algunos casos existen varias formas de resolver las preguntas, así que siéntete libre de aportar tu visión en los comentarios ¡Vamos al lío!

Servidor de RRHH – Nivel básico

1. ¿Qué software se empleó para crear la imagen del servidor de RRHH?

Dos pulgares oponibles, saber leer y abrir un fichero comprimido nos dan la respuesta. Dentro del .zip nos encontramos con el fichero HRServer_Disk0.txt, en el que podemos leer tal cual la respuesta:

* Respuesta: X-Ways Forensics

2. ¿Qué versión de software ha sido usada para crear la imagen del servidor de RRHH? (Respuesta en formato n:n)

Sí que llevan tiempo en el tema del forense estos de X-Ways que les ha dado para hacer una pila de versiones…

* Respuesta: 19.6

3. ¿Cuál es el nombre de fichero de la entrada de la MFT 168043?

Empezamos a meternos un poco en harina. La extensión .e01 parece indicar que estamos en una imagen en formato de Encase, así que vamos a tirar de FTK Imager para montarlo en nuestro Windows.

Una vez montado podemos acceder a la carpeta [root] donde encontraremos el sistema de ficheros, y copiamos el fichero $MFT que contiene (oh, sorpresa) la MFT (Master File Table, una especie de índice de todos los ficheros del disco duro).

La MFT está en formato binario, así que tenemos que parsearla a un formato más comprensible, algo que podemos hacer con la herramienta mftdump.exe.

Como nos piden un dato muy concreto, podemos tirar de grep (sí, hay Powershell en Linux, y grep en Windows. Corren tiempos extraños, gente) para sacar el flag.

* Respuesta: pip3.7.exe

4. ¿Cuál es el número de la entrada de la MFT del fichero: \xampp\mysql\bin\mysql.exe [respuesta en formato de entero]

Grep sigue siendo nuestro amigo. Sin embargo, la salida es un poco confusa:

La forma más sencilla de tener la respuesta es volcar la salida del grep a un .csv y abrirlo con LibreOffice, donde las cosas se ven mucho más claras.

* Respuesta: 115322

5. ¿Cuál es el Attibute ID de la MFT del atributo de datos $J para la entrada de la MFT con el nombre de fichero $UsnJrnl?

What is the MFT Attribute ID of the named $J data attribute for the MFT Entry with a file name of $UsnJrnl?

Me niego a meterme en semejante berenjenal por tan solo 2 puntos. Cuando termine con todas las preguntas “del rosco” (que son 63, ojo al dato), si me apetece vuelvo.

[UPDATE: No, no me ha apetecido volver xDDDD]

[UPDATE: Mierda, es la única pregunta que me falta para completar el reto y ya que hemos llegado hasta aquí, vamos a terminar el reto joer]

Después de investigar un rato sobre la estructura interna de NTFS (yuhu), descubrimos que Sleuth Kit es maravilloso ya que te muestra el Attribute ID como parte de su salida:

Según fls, los tres valores se interpretan de esta forma: ADDR-TYPE-ID.

• ADDR is the metadata address,
• TYPE is the attribute type
• ID is the attribute id

¿Has visto qué 3 tannnn bonito? Son solo dos puntos pero saben a gloria …

* Respuesta: 3

6. ¿Cuál era la dirección IP del cliente que intentó acceder a través de SMB mediante un anonymous logon a las 2018-08-08 18:10:38.554(UTC)?

Esa información debería residir en un log de eventos del sistema, así que nos vamos a la carpeta de logs de Windows (C:\Windows\system32\winevt\logs). Ahí encontramos una buena pila de logs, pero uno que nos suena interesante:

Podemos abrir el fichero con el Visor de Eventos de nuestro equipo sin problemas, pero cuando buscamos la fecha exacta, no encontramos un mojón ¿Qué es lo que está pasando? Que estamos buscando en el sitio oportuno… pero no en el momento adecuado.

El Visor de Eventos de Windows muestra siempre los logs en la Timezone del equipo (en nuestro caso, España peninsular). Pero vete tú a saber dónde estaba el que hizo el reto cuando se puso a ello, así que se lo vamos a tener que preguntar al registro de Windows (situado en C:\Windows\system32\config). La clave que guarda la timezone es:

por lo que podemos abrir el SYSTEM con Registry Explorer y obtener la timezone, que en este caso es Pacific Standard Time (UTC-8).

Pero como es viernes y no me apetece trabajar, no me estoy leyendo bien la pregunta: te están especificando el acceso YA en UTC, por lo que únicamente tendríamos que sumar una hora y buscar por las 19:10:38…. pero no hay nada. Dándole una vuelta más nos damos cuenta de que, aunque el reto lo estemos haciendo en Noviembre, se publicó en Agosto, lo que significa una cosa: horario de verano, en el que España hay una hora más, lo que significa que estamos en UTC+2.

Está claro que toca abrir una cerveza para despejarnos. Buscamos en nuestro Visor de Eventos a las 20:10:38 y ahí tenemos nuestro evento:

* Respuesta: 80.81.110.50

7. ¿Qué nombre tiene el fichero .bat guardado por el usuario mpowers? [la respuesta es el path completo empezando por c:****]

Ya que tenemos la MFT, vamos a lanzar un grep en busca de los ficheros de mpowers que terminen en .bat. Algo tan simple como:

grep mpowers mft_parseada.csv |grep bat

nos devuelve un resultado igual de simple: cero. Vamos a tener que currárnoslo un poco más. Si buscamos únicamente por los .bat nos encontramos con que tenemos 174 resultados, así que vamos a tener que afinar un poco más.

Una vía alternativa es la de buscar los últimos documentos abiertos por el usuario mpowers, información que se guarda en los MRU (Most Recent Used) y que en el disco está en el fichero NTUSER.dat, localizado en el directorio raíz del usuario.

En este caso podemos usar RegRipper con el plugin runmru… pero no nos da resultados (raro raro). Podemos sin embargo buscar la información tirando de los UserAssist, que guardan las últimas aplicaciones, accesos directos y documentos abiertos por el usuario. Un poquito de grep y… ¡bingo!

* Respuesta: C:\Production\update_app.bat

8. ¿Cuál es el nombre de la aplicación de gestión de RRHH que tiene un servidor web?

Antes hemos visto un xampp en C:\ (xampp es un conocido combo de Apache+MySQL+PHP+Perl open source que funciona estupendamente bajo Windows), así que vamos a ver si tenemos algo en la configuración de Apache. No tenemos suerte, así que vamos a buscar qué programas tenemos instalados en el equipo.

Para ello visitamos tanto “C:\Archivos de Programa” como “Program Files (x86)”, y lo único que destaca es el OrangeHRM. Ahora que lo pensamos, si estamos en el servidor de Recursos Humanos, tiene su lógica encontrar un HRM (Human Resources Management). Tantos años en el mundo TIC te dan canas, experiencia y la capacidad de adivinar ATL (Acrónimos de Tres Letras) al vuelo. Si abrimos la carpeta comprobamos que tiene dentro otro xampp, lo que nos da la respuesta que queremos.

* Respuesta: OrangeHRM

9. ¿Cuál es la URL pública para el portal de RRHH? [formato: http://****]

Si tenemos un Apache soportando la aplicación, lo lógico es que estuviera en el httpd.conf, situado en xampp\apache\conf. Ahí tenemos como valor una IP… que no es el correcto. Buscamos en toda la carpeta por si tenemos otros valores de configuración, y encontramos un orangehrm.localhost en el fichero orangehrlm-4.1\symfony\config\vhost.sample, que tampoco es válido.

Después de un par de intentos queda claro que lo que quieren no es el servername (lee bien la maldita pregunta, Antonio) sino la URL real sobre la que se accede, que será la IP + el resto de la URI. Nos toca tirarnos a los logs y ver qué podemos sacar en claro. Un poquito de observación permite identificar que hay peticiones que siempre redirigen a una URL, que además es la de login:

Sumando ambos valores obtenemos la respuesta.

* Respuesta: http://74.118.139.108/orangehrm-4.1/symfony/web/index.php/auth/login

10. ¿Cuál es el nombre del fichero que tuvo un cambio guardado con un USN (Updated Sequence Number) de 368701440?

Los cambios en ficheros se quedan guardados en el USN Journal (Update Sequence Number Journal), que guarda un log de los cambios que se hacen en un volumen NTFS. En nuestro caso lo tenemos en C:\$Extend\$UsrJrnl, del que podemos extraer el log con FTK Imager:

Este journal lo podemos parsear con la herramienta NTFS Log Tracker (y puedes encontrar más info sobre el forense de $UsnJrnl en esta presentación), obteniendo nuestra respuesta.

* Respuesta: Microsoft-Windows-SMBServer%4Security.evtx

11. ¿Cuál es el nombre del fichero borrado con un reference number de 12947848928752043?

Esta pregunta te deja así como torcido, pero la experiencia te enseña que “no hay que saberlo todo, solo hay que saber dónde encontrarlo”, así que tiro del libro “Filesystem Forensics Analysis”… pero solo nos dice que el número de referencia pertenece a cada fichero de la MFT, nada de cómo calcularlo.

Por lo menos nos sirve para acotar la búsqueda en Google, ya que encontramos este breve pero ilustrativo artículo: https://jmharkness.wordpress.com/2011/01/27/mft-file-reference-number/

Al parecer todas las entradas de la MFT tienen un reference number, compuesto por el número de la entrada MFT (6 bytes) y el número de secuencia (2 bytes) en hexadecimal.

Usando un convertidor online de entero a hexadecimal obtenemos el valor:

12947848928752043 (int)  --> 2E00000000F1AB (hex)

Como el valor son 8 bytes, tenemos que añadir un 0x00 al valor: 0x002E00000000F1AB, que ya podemos dividir en sus dos partes:

Entrada MFT: 00000000F1AB
Número de secuencia: 0x002E

Con el convertidor anterior pasamos de hexadecimal a entero, obteniendo el valor 61867 que corresponde a la entrada de la MFT, que ya tenemos de preguntas anteriores.

* Respuesta: _MEI78882

Servidor de RRHH – Nivel avanzado

12. Qué usuario inició sesión en el equipo a las 2018-07-30 22:31:33 UTC, qué tipo de inicio de sesión usó, y cuál es el nombre del proceso empleado? [formato: {TargetUserName} – {LogonType} – {LogonProcessName} – {IpAddress}]

Esta pregunta está chupada, porque es justo la información que tendría que estar en el log de Security de Windows (recuerda que toca mirar 2h más tarde). Por desgracia el log ha sido deleznablemente borrado por los atacantes el 8 de Julio (eliminando los registros anteriores) así que no podemos obtener fácilmente esa información. Y tiene que estar ahí porque por lo que solicitan es el único lugar del que se puede obtener con esos campos.

La teoría es que el atacante puede haber entrado en el equipo y luego borrado los logs. Si tuviéramos una máquina del tiempo lo podríamos resolver con facilidad, pero el Delorean está en el taller, así que poco podemos hacer.

Si existiera alguna forma de que Windows de vez en cuando guardara una copia de los ficheros que nos interesaran cada vez que se hiciera algo y los copiara en un lugar fresquito y seco, bien a la sombra por si acaso nos hiciera falta recuperarlos… estás pensando lo mismo que yo, ¿verdad? Las shadow copies nos van a dar la respuesta.

Comenzamos arrancando nuestro fiel SIFT y copiando la imagen en un .e01. Con mmls identificamos el inicio de la partición y con ewfmount montamos la imagen en raw.

SIFT viene con varias utilidades para trabajar con shadow copies, de las que nos interesan vshadowinfo y vshadowmount (para obtener información y montar shadow copies respectivamente). Empezamos por ver si tenemos shadow copies en el equipo con vshadowinfo (recordad que hay que poner el offset del inicio de partición, 1026048*512 = 525336576):

Tenemos una copia, así que podemos montarla con vshadowmount y extraer el event log de Security sin problemas:

Si recuperamos el fichero comprobamos con alegría que tenemos los resultados en la hora indicada (recuerda que el Visor de Eventos está en hora local):

El evento se ve un poco descarajado porque nos falta información para presentarlo correctamente (posiblemente porque el equipo origen esté en inglés). Sin embargo, si nos quedamos con los detalles del evento lo veremos mucho más claro:

Referencias:

• https://digital-forensics.sans.org/blog/2011/11/28/digital-forensic-sifting-mounting-ewf-or-e01-evidence-image-files
• https://www.andreafortuna.org/dfir/volume-shadow-copies-in-forensic-analysis/
• https://medium.com/@mbromileyDFIR/windows-wednesday-volume-shadow-copies-d20b60997c22
• https://www.forensicswiki.org/wiki/Windows_Shadow_Volumes
• https://www.andreafortuna.org/dfir/accessing-volume-shadow-copies-within-a-forensic-image/

* Respuesta: mpowers – 10 – User32 – 74.118.138.195

13. ¿Qué tarea se inició a las 2018-07-27 02:42:43 (UTC)?

Después de la currada de la pregunta anterior, esta supone un respiro. La ejecución de una tarea programada deja un registro en el log de eventos, en el Task Scheduler. Tan simple como abrirlo en el Visor de Eventos (recuerda que estamos en UTC+2) y localizar la fecha y hora concretas:

* Respuesta: “Throw Taco”

14. ¿Qué dirección IP estuvo accediendo al portal de OrangeHRM usando 68.0.3440.84?

Tenemos los logs localizados gracias a una pregunta anterior, así que es cuestión de tirar de nuevo de grep:

grep 68.0.3440.84 logs\* > chrome.csv

*Respuesta: 74.118.139.108

15. ¿Qué version de Apache se está usando? [format: n.n]5

Tenemos el Apache en la carpeta C:\Archivos de Programa\OrangeHRM\4.1\apache, así que es cuestión de buscar la versión. Pero es tarde y estoy vago, así que puedo permitirme el lujo de subir el httpd.exe a VirusTotal y que me diga la versión (niños, niñas, recordad: nunca hagáis esto con vuestras muestras de APT).

Bueno, venga, por vergüenza torera vamos a buscarlo como $deity manda. En 2 min de rebuscar encontramos el CHANGES.txt que nos muestra el changelog de Apache, y lo primero que indica es la versión actual.

* Respuesta: 2.4

16. ¿Cuál es el valor entero del reason code que ofrece un registro USN v2 cuando los flags del registro tienen los siguientes motivos: USN_REASON_CLOSE | USN_REASON_DATA_EXTEND | USN_REASON_FILE_CREATE?

Aquí el reto nos tiende una emboscada con otra pregunta árida de teoría. Bueno, no estamos en un examen, así que podemos hacer una búsqueda rápida de Google y aprender un poco de paso. Aquí tenéis un documento estupendo en el que cuentan más acerca de la estructura del USN_JOURNAL_DATA:

https://msdn.microsoft.com/en-us/library/windows/desktop/hh802706(v=vs.85).aspx

Los flags de un registro de USN se acumulan para crear una máscara, por lo que tenemos:

USN_REASON_CLOSE = 0x80000000
USN_REASON_DATA_EXTEND = 0x00000002
USN_REASON_FILE_CREATE = 0x00000100
Total: 0x80000102

Lo convertimos de hexadecimal a entero con un convertidor online: y listo para responder.

* Respuesta: 2147483906

Servidor de RRHH – Nivel experto

17. ¿Qué dirección IP se comunicó en más ocasiones con el servidor web?

Con los logs de Apache localizados, cuesta más arrancar de nuevo la VM de SIFT que responder a la pregunta:

$ cut -d" " -f1 /media/sansforensics/7C4604634604208E/access.log |sort |uniq -c |sort -nr|less

* Respuesta: 74.118.138.195

18. ¿Cuántas peticiones HTTP se hicieron al servidor web en las que la URL solicitada contenía un comando de wget embebido?

Si me dieran un € por cada vez que he tirado un cut/grep/awk…

$ grep wget  /media/sansforensics/7C4604634604208E/access.log |wc

* Respuesta: 101

Ya es la una y pico de la mañana, pero hemos cumplido el objetivo de un nivel al día. Al catre a descansar las neuronas, que al día siguiente toca el nivel 2…

La entrada DEFCON 2018 DFIR CTF – Reto forense (Intro + Nivel 1) aparece primero en Security Art Work.

Servidor de ficheros – Nivel básico

1. ¿Cuál es el número de serie del volumen de la única partición de la imagen de disco del servidor de ficheros?

El número de serie del volumen es un valor hexadecimal que se genera cuando se crea el sistema de ficheros. La documentación de Microsoft nos dice que para sistemas de ficheros NTFS lo tenemos en la posición 0x48 del BPB (Bios Parameter Block), que es parte del sector de arranque. Este sector lo tenemos en el disco en el $boot (en el raiz del disco). Montamos el disco con FTK Imager y accedemos al valor hexadecimal:

Ahí tenemos el valor: 652496C0. Sin embargo, al introducirlo en la web del reto no acepta la solución como válida, así que algo estamos haciendo mal. Después de darle muchas vueltas, pensé: “Esta es una pregunta básica, no me jodas. Tiene que haber una forma muy sencilla de obtener la respuesta”. Y tanto. Si tenemos la imagen montada con FTK Imager, se ve como otra unidad cualquiera del sistema, así que nada nos impide usar el método live de saber el VSN de un sistema de ficheros: el comando vol.

He perdid… digo invertido cerca de una hora de mi vida aprendiendo la estructura interna de NTFS (miremos las cosas por el lado bueno :D). Lo curioso es que el valor era el correcto solo que estaba al revés (y he buscado un buen rato el motivo hasta que he caído en lo de los Little Endian/Big Endian).

Referencias:

• https://www.digital-detective.net/documents/Volume%20Serial%20Numbers.pdf
• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc781134(v=ws.10)

* Respuesta: C0962465

2. ¿Cuál es el nombre del examinador que realizó la imagen forense?

Para esas cosas están los logs de adquisición (el sitio donde se ponen los hashes y esas cosas que nadie piensa que necesita hasta que un día alguien se olvida de calcularlos y ocurren desgracias).

* Respuesta: Professor Frink

3. ¿Quién borró todos los eventos del log de seguridad?

Volvemos a la carga con los logs. En este caso parece que el log de Security no ha sido borrado (no encontramos el EventID de “Log cleared”), pero sí que vemos una barbaridad de eventos con EventID 4625 (37989 para ser exactos), que indican un error al intentar iniciar sesión.

Parece que alguien ha intentado llenar el log para que se sobreescriban los eventos más antiguos (la configuración por defecto en Windows), porque si filtramos ese EventID tan solo nos quedan 117 eventos, siendo el más antiguo del 07/08/2018. Y por lo que se puede entrever de algunas preguntas anteriores el incidente de seguridad pudo empezar a finales de Julio.

Sin embargo, no esperaban a la Inquisic… digo a nuestra astucia como forenses. Cada vez que se inicia una sesión, independientemente de si es en local o en remoto, se carga el perfil de usuario del mismo. Esta acción deja un registro en el log Microsoft-Windows-User Profile Service%4Operational.evtx, que podemos consultar con facilidad ya que el número de eventos es siempre muchísimo más reducido (y los atacantes cuando se dedican a cubrir sus huellas siempre atacan los logs de Security y de Terminal Services, pero nadie hace caso al pobrecito User Profile … para nuestra fortuna).

Este resultado tiene definitivamente mejor pinta, porque el 31/Jul tenemos un log del usuario mpowers a hora intempestivas. No lograríamos una condena a muerte con una evidencia tan circunstancial, pero es la respuesta correcta.

* Respuesta: mpowers

4. ¿Qué hostname tiene el equipo?

Esta no tiene mucho misterio. Toda la configuración de Windows está guardada en el registro, así que es algo tan simple como acceder a:

Esta vez lo vamos a hacer más sencillo todavía con el truco de “Cargar Subarbol”. Abrimos RegEdit, pinchamos en HKEY_LOCAL_MACHINE y seleccionamos “Archivo–>Cargar subarbol”. Buscamos el SYSTEM del servidor HR y lo cargamos como SYS_HR… y ya podemos navegar sin problemas.

* Respuesta: WIN-M5327EF98B9

5. ¿Cuándo se apagó el equipo por última vez? [formato: Month/Day/Year Hour:Minute:Second in 24 hour timr 1/1/2018 14:01:01]

Otra pregunta de registro. Si no has cerrado todavía el RegEdit, es tan sencillo como ir a:

El problema es que es un dato binario, y hay que interpretarlo. Como lo del RegEdit lo habíamos hecho para enseñar nuevas formas de hacer las cosas, vamos a volvernos al RegistryExplorer, que tiene una característica maravillosa llamada “Data Interpreter”. Accedemos a la clave y activamos el intérprete de datos y obtenemos el resultado sin problemas… F***! !¿Cómo que incorrecta?! Espera, que es un reto hecho por americanos, y hacen las cosas a su manera, incluyendo las fechas. Colocamos los meses y los días como a ELLOS les gusta, y obtenemos la respuesta correcta.

* Respuesta: 7/26/2018 10:16:16

6. ¿Cuál es el Current Build number de Windows del servidor de ficheros?

Seguimos con el registro de Windows. Una búsqueda rápida nos indica la clave del registro donde se esconde nuestra información:

Referencia:

• https://tommynation.com/how-to-determine-windows-edition/

* Respuesta: 7601

7. ¿Qué user id tenia mpowers?

Los identificadores de usuario (UserID) se guardan en la SAM del equipo, otra clave de registro (recuerda: toda la configuración está en el registro). 30 segundos de RegRipper nos dan el resultado:

* Respuesta: 1000

8. ¿Cuál fue el último programa que ejecutó Max Powers a través del interface gráfico?

Aquí lo más sencillo sería mirar el Prefetch, pero este equipo no gasta de eso porque es un Server (lo comprobamos en la captura de pantalla de la respuesta anterior, es un Windows Server 2008 R2 Enterprise). Nos va a tocar tirar del UserAssist (que guarda el registro de los últimos ejecutables lanzados por el usuario).

Un poco de RegRipper con el NTUSER.dat del usuario, y aquí tenemos el resultado:

* Respuesta: sub-win-x64_104.148.109.124_5682_3262.exe

9. ¿Cuánto fue la última vez que Max Powers abrió el fichero projections.zip? [format: UTC TIme Day/Month/year Hour:Minute:Sec in 24 hour time 1/1/2018 15:20:11]

Esta parecía sencilla pero vamos a comprobar con rapidez que tiene su mordiente. En un caso normal sería cuestión de recuperar la MFT, convertirla a .csv y tirar un grep para encontrar los tiempos MAC del fichero projections.zip.

Sin embargo, no hay rastro del projections.zip en la MFT. Analizamos los MRU del usuario y tampoco hay nada. Si recordamos la pregunta 19, alguien está cubriendo deliberadamente sus huellas, así que es posible que nos encontremos con temas de anti-forense.

Nos toca de nuevo trabajar con las shadow copies. Levantamos de nuevo la VM con SIFT y copiamos el fichero con la imagen en formato .e01, para luego identificar la partición NTFS y buscar las posibles shadow copies.

Calculamos el offset con el principio de la partición y el tamaño en bytes de cada sector:

206848 * 512 = 105906176

Y buscamos las shadow copies con vshadowinfo, encontrando premio:

Ahora es cuestión de montar la shadow copy con vshadowmount (recuerda que hay que montar primero el VSS para luego montar el sistema de ficheros):

Lo más sencillo es buscar directamente el projections.zip… pero no tenemos suerte:

Así que nos tocará volver a sacar los MRU del usuario de la shadow copy y analizarlos. Copiamos el NTUSER.dat y lo montamos en Windows para poder lanzar el plugin recentdocs de RegRipper:

Ya tenemos al parecer nuestra fecha. Pero como hay dos .zip, y no tengo del todo claro si esa fecha de última escritura es la correcta o no. Para convencerme del todo vamos a abrir el NTUSER.dat con Registry Explorer y de esta forma acceder a los valores en bruto, localizados en:

Confirmamos la respuesta, convertimos al formato deseado por el CTF, y recogemos nuestros merecidos puntos.

* Respuesta: 8/7/2018 20:09:15

10. ¿Cuántos clusters tiene la partición?

Rebuscando un poco por Internet encontramos el comando fsutil, que lanzado desde un terminal elevado (o sea, con privilegios de administrador, no subidos en una escalera) nos da la respuesta

La convertimos de binario a entero con la web que hemos usado en otras preguntas, y a correr.

* Respuesta: 13081343

Servidor de ficheros – Nivel avanzado

11. ¿A dónde nos lleva el directorio \VSS?
Si lo buscamos en nuestra unidad montada, encontramos que C:\vss es un acceso directo. Si hacemos uso de la imagen montada con FTK Imager encontramos el directorio correcto al que accede.

Si lo adecentamos un poco obtenemos la respuesta.

* Respuesta: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

12. ¿Cuándo fue creado el Volume Shadow Copy 1? [formato UTC TIme 1/1/2018 13:11:11 Month/Day/Year 24 Hour Time]

Esta respuesta nos la da vshadowinfo, que como lo habíamos usado en una pregunta anterior nos da la respuesta automática:

Y que la plataforma no acepta. WTF? Revisamos correctamente el puñetero formato de fechas y comprobamos que es el correcto. Parece que o bien la herramienta nos ha traicionado vilmente o que el reto no está correctamente ejecutado.

Necesitamos una segunda opinión, así que nos descargamos una versión de prueba de ForensicsExplorer, que tiene una funcionalidad de análisis de shadow copies:

Forensic Explorer también nos da la razón, por lo que tiene que ser un problema de los creadores del reto. Nuestro trabajo aquí está hecho (aunque nos quedemos sin puntos)

* Respuesta: 8/7/2018 20:13:26

13. ¿Desde dónde inició sesion Max Powers?

La respuesta está en los logs de Terminal Server (Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx). Por ahora parece que el incidente ha debido de tener lugar el 7 de Agosto sobre las 20:00h, por lo que nos centramos en lo que ocurre en nuestro Visor de Eventos sobre las 22:00h (recuerda el UTC+2). Y nos cuesta muy poco encontrar un inicio de sesión sospechoso:

* Respuesta: 74.118.138.195

14. ¿Qué programa fue usado para borrar los artefactos forenses?

En este caso volvemos a los resultados del UserAssist, que nos dan las últimas ejecuciones del usuario mpowers. Repasándolas con cuidado encontramos una que suena bastante sospechosa:

Una búsqueda rápida en Google nos confirma que Privazer es una herramienta para eliminar las acciones de un usuario en un sistema. No del todo perfecta al parecer.

* Respuesta: PrivaZer.exe

15. ¿Cuál es el nombre del fichero .zip que contiene el directorio M4Projects?

Por ahora parece que la cuenta del usuario mpowers es la responsable del incidente, así que nos centramos en buscar en sus alrededores sin éxito. Probamos a buscar en los UserAssist sin fortuna, y la MFT no nos da información adicional. Parece que el Privazer.exe nos ha jorobado pero bien, así que vamos a tener que volver a las shadow copies.

Sin embargo, en una pregunta anterior teníamos un listado de los .zip que nos va a venir estupendamente:

Si contrastamos con la imagen de disco montada en el FTK, ninguno de los .zip que encontramos en el directorio del usuario mpowers. Si hacemos un listado del contenido de los .zip con el comando “unzip –l”, encontramos que ambos tienen el mismo contenido:

Podemos contrastar con FTK el contenido encontrado de la carpeta M4Projects y confirmar que en efecto ambos contienen el resultado deseado:

Pito, pito gorgorito… probamos FileServerShare.zip y nos da el resultado deseado.

* Respuesta: FileServerShare.zip

16. ¿Qué host ha sido empleado para exfiltrar los datos?

Antes de encontrar el destino tenemos que encontrar el programa empleado para la exfiltración. Seguimos con la teoría de que el atacante solo ha tenido acceso a la cuenta del usuario mpowers, así que solamente tiene privilegios de usuario. Esta hipótesis nos dice que el atacante solo ha podido emplear lo que hay en la cuenta de usuario y lo que hay instalado en el sistema, lo que nos ayuda a acotar el análisis.

En el directorio del usuario mpowers tenemos estas aplicaciones sospechosas:

El segundo fichero es F-Response (firmado digitalmente), por lo que lo podemos descartar. El primero es muy interesante, en primer lugar porque aparece en VT (aunque mirando las fechas posiblemente sea algún otro participante el que lo haya subido):

https://www.virustotal.com/#/file/4fa28f3eb0eedd737ee63190bcfea53c8095b480e82d895ff0cd4ab4f24f5ae2/detection

y que hasta tenemos ejecución en Hybrid-Analysis:

https://www.hybrid-analysis.com/sample/4fa28f3eb0eedd737ee63190bcfea53c8095b480e82d895ff0cd4ab4f24f5ae2?environmentId=120

Pero si lo miramos con más detalle, este ejecutable estaba entre la info que parece que el atacante se ha llevado, así que lo lógico es que este ejecutable estuviera ya en el equipo y fuera el objetivo (por lo que lo podemos descartar)

Descartando ambos programas, vamos a ver lo que tenemos instalado en el sistema: Google Chrome e Internet Explorer. Es momento de un poquito de BrowsingHistoryView… que también nos falla. Privazer nos está complicando la existencia lo suyo, pero ya que tenemos montadas las shadow copies vamos a extraer el historial de navegación del usuario mpowers.

Si abrimos el historial con (recuerda que es una BD SQLite) con un visor adecuado y rebuscamos un poco, encontramos nuestro premio:

* Respuesta: www.dropbox.com

17. ¿Cuál es la URL a la que se exfiltraron los datos?

¡Combo 2×1! Con la resolución de la pregunta anterior tenemos gratis esta.

* Respuesta: https://www.dropbox.com/request/51bpm0D7zHjRbfvuqGzt

18. ¿Qué hives del registro se llevó el atacante? (por favor, lístalas en orden alfabético con un espacio entre cada nombre)

Vamos a permitirnos un pequeño salto hacia delante en el tiempo. En una pregunta del nivel siguiente tenemos que recuperar unos ficheros del equipo, y resultan ser SAM y SYSTEM. Dado que esos ficheros son parte del modus operandi del atacante, es más que probable que haya repetido en este equipo lo que ha hecho en el anterior… y tenemos razón.

* Respuesta: SAM SYSTEM

19. ¿Qué herramienta ha sido empleada para borrar el Journal USN?

Seamos vagos por una vez. Si tenemos una herramienta de limpieza de rastros ejecutada en el sistema y culpable de una cosa, echémosle la culpa de todo. Posiblemente, también mató a Kennedy y es la culpable del calentamiento global… ¿por qué no?

Sorprendentemente, funciona. Bueno, no tan sorprendentemente porque si revisamos la documentación de Privazer lo pone bien clarito :D

* Respuesta: Privazer.exe

20. ¿Qué servicio empleó el atacante para acceder al sistema?

Si nos vamos a los distintos logs de servicios, lo único que encontramos es que el usuario mpowers cargó su perfil el 31/Jul a las 0:43 horas (UTC+2). El log de conexiones de Terminal Server está frito, pero el que guarda información de las sesiones locales no: Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational, y nos indica que a la misma hora el usuario mpowers se ha conectado de forma remota al equipo.

Terminal Services no es una respuesta válida, ya que nos piden el nombre real del servicio: rdp

* Respuesta: rdp

Servidor de ficheros – Nivel experto

21. ¿Qué programa ha extraído el fichero Mnemosyne.sys?

Más sabe el diablo por viejo que por diablo dice el refrán. Y en este caso, si has trabajado con F-Response sabrás que es el nombre del driver que necesita para acceder a la memoria física del equipo.

* Respuesta: F-Response

22. ¿Qué directorio fue eliminado de forma segura?

Si alguien usó algún programa de borrado, tiene que haber dejado algún resto en el $usrjnl, así que lanzamos de nuevo el NTFS Log Tracker. Ups. Nos hemos olvidado de que PrivaZer.exe se lo había merendado hace 3 preguntas.

Un poco de exploración de los directorios con FTK Imager, y asumiendo que el usuario no tenía privilegios de administrador, nos permite localizar un directorio sospechoso

Parece que alguien le ha dado fuerte a ese directorio. Podemos confirmarlo haciendo un grep de la MFT que ya teníamos convertida y viendo qué nos dice al respecto

Fechas aleatorizadas, tamaño 0, ni rastro de las extensiones… parece un trabajo ruidoso pero concienzudo.

* Respuesta: C:\M4Projects\project_0x02

23. ¿Quién solicitó esta exfiltración de datos?

Esta la sabemos por el gen “vieja del visillo” de mirar todo lo que se pueda en un incidente. En una pregunta anterior nos hemos hecho con una URL de Dropbox. Si accedemos a ella tenemos claro quién ha sido el culpable:

* Respuesta: Sideshow Bob

24. ¿Cuál es la dirección de correo de la persona que subió los datos a Dropbox?

El cuerpo nos pide localizar todas las direcciones de correo existentes en el equipo, algo que podemos hacer con bulk_extractor bajo la imagen cargada en Linux.

Y lo dejamos suelto por todo el disco duro. Un par de horas más tarde tenemos un listado de direcciones de correo encontradas en el sistema: 215854. Va a ser que necesitamos una herramienta un poco más fina.

Abrimos Autopsy y cargamos la imagen con el plugin de búsqueda por palabras (que tiene una específica para encontrar direcciones de correo):

Eso sí, le va a costar lo suyo (concretamente, casi 12h porque tengo el SSD lleno con otras cosas y tirar de SATA es una eternidad). Al día siguiente tenemos café y resultados, por lo que podemos empezar a realizar búsquedas por palabras.

Dado que Dropbox está implicado en la exfiltración de datos, vamos a asumir que si existe una dirección de correo tiene que estar “cerca” en el disco, por lo que vamos a realizar una búsqueda en toda la imagen por www.dropbox.com:

Tan solo 11 hits, esto puede prometer. Y si lo analizamos con un poco más de detalle, nos damos cuenta de que el número 8 tiene exactamente la petición HTTP al Dropbox empleado por el atacante:

Vamos a ver si somos capaces de encontrar alguna dirección de correo dentro de los resultados. El trabajo va a ser un poco farragoso ya que tenemos el fichero tiene 9819 páginas según Autopsy, aunque solo 12 de ellas tienen hits con Dropbox. Dado que no podemos buscar dentro del submenú de Autopsy toca copiar en un fichero de texto y tirar de grep:

• P29: nope
• P30: nope
• P34: nope
• P37: nope
• P38: nope
• P39: nope
• P41: nope
• P43: nope
• P50: nope
• P168: snakepleskin@gmail.com
• P170: nope
• P1018: nope
• P1060: nope

Suena MUY interesante. Realizamos una verificación realizando otra búsqueda por palabras con la cadena “snakepleskin” y comprobamos que tenemos un hit más, justo al lado de la petición de Dropbox:

No es como encontrar el arma del crimen en un asesinato, pero es suficiente como para que la pongamos como solución. Y funciona, así que nos llevamos los puntos y la satisfacción de terminar el reto (esta es la pregunta que más me ha costado, pero sienta BIEN el tener todas las respuestas).

* Respuesta: snakepleskin@gmail.com

Suficiente para una noche de sábado. Poweroff, que nos queda todo el domingo para el tercer nivel del reto.

La entrada DEFCON 2018 DFIR CTF – Reto forense (Nivel 2) aparece primero en Security Art Work.

Puesto de usuario – Nivel básico

1. ¿Qué dirección IP tiene el puesto de usuario?

El registro lo sabe TODO. En este caso, el hive SYSTEM:

Un poco de RegistryExplorer y ya tenemos la respuesta:

* Respuesta: 74.118.138.195

2. ¿Cuál es el SID de la cuenta de Administrador?

El SID (Security Identifier) es un valor único e inmutable que se le da a cada cuenta de usuario en el momento de su creación.

Podemos ser especialmente sucios y tirar de los perfiles de usuario (en los que se guardan datos de cada usuario, y que están referenciados por su SID). Buscamos con RegistryExplorer en:

y de ahí sacamos el valor con rapidez:

* Respuesta: S-1-5-21-1769714682-2803786108-491265710-500

3. ¿Cuál es el offset de la timezone en la que está el equipo? [Ejemplo: -1]

Esta ya la habíamos medio respondido en el primer nivel. Los datos de timezone están (cómo no) en el registro de Windows:

En esta ocasión ya me ha hecho efecto el primer café de la mañana, y he leído la pregunta correctamente. Lo que piden es el desfase en horas de la zona con respecto a UTC. Según lo que indica el valor Bias estamos en 480 min, lo que se traduce en -8 (confirmado al buscar el valor en texto de Pacific Standard Time). Sin embargo, a la hora de crear el reto estaban en horario de verano, por lo que se quita 1h, quedando el offset en un precioso -7.

Que no funciona. Y tendría que hacerlo. Probamos el -8 sin éxito… y decidimos que es domingo, así que vamos a por la fuerza bruta. Los supertacañones aceptan como respuesta válida -4, pero si alguien sabe explicarme porqué, se ganará una birra :D

* Respuesta: -4

4. ¿Qué nombre tiene el directorio borrado de la shadow copy en la papelera?

Toca huronear un poco en la papelera. Si navegamos por la estructura de directorios con FTK comprobamos que hay varios ficheros de interés, pero en este caso FTK Imager no me deja visualizar su contenido (raro raro). Como siempre es bueno poder recurrir a otras herramientas, en este caso vamos a usar wxHexEditor, que nos deja ver el contenido del fichero $IFATB0K y con él nuestra respuesta.

* Respuesta: $IFATB0K

5. ¿A qué directorio copió el atacante los ficheros desde el VSS?

Vamos primero a coger los apuntes de primero de lengua para entender la pregunta. Al parecer el atacante copió los ficheros del VSS a algún directorio, cuyo nombre es lo que nos piden averiguar.

Dado que el VSS está en la papelera, es posible que el otro directorio también haya sido borrado. Rebuscando entre el resto de directorios encontramos que hay dos ficheros: SAM y SYSTEM, y si rebuscamos un poco más encontramos nuestro resultado:

* Respuesta: temp

6. ¿Cuál es el nombre del fichero que exfiltró el atacante?

Seguimos en el entorno de la papelera. El atacante se ha quedado con el SAM y el SYSTEM del equipo (como en el nivel anterior), y justo al lado observamos un Desktop.7z. En muchos casos los atacantes agrupan y comprimen los resultados para facilitar su exfiltración (lo que se denomina staging). Si lo descargamos y lo abrimos comprobamos que tiene esas hives del registro, lo que confirma nuestra teoría.

* Respuesta: Desktop.7z

7. ¿Cuál es la IP del sitio de Magnetic Forensics accedido por el atacante?

Nos toca revisar de nuevo el historial de navegación. En este caso BrowsingHistoryView funciona correctamente y nos da el historial de todos los navegadores. Si buscamos por la cadena “magnetic” no encontramos nada más que accesos a Outlook y Google Docs. Sin embargo, aparece una dirección IP repetidas veces: 74.118.139.108

Si nos damos cuenta, esta IP es muy parecida a la del desktop (74.118.138.195), así que posiblemente sea la que busquemos. Y en este caso, acertamos :D

* Respuesta: 74.118.139.108

8. ¿Cuál es la contraseña del administrador?

Bueno, aquí podemos seguir un poco el hilo del atacante. Si quieres sacar las contraseñas en local tienes que obtener los hashes y luego crackearlos. Los hashes los obtienes (obviamente) del registro, siendo exactos de las hive SAM y SYSTEM (justo las que se ha llevado puestas el atacante, qué coincidencia).

Teniendo los hive solo falta tirar de Mimikatz para que haga nuestro trabajo sucio (no sin antes bajar el AV de nuestro Windows para que no se asuste el pobre)

Nuestro hash NTLM es: 4d55663e41abd66cf17584c9c9f7c86c

Tiramos de Hashcat y nuestra maquinita de password cracking y sacamos el resultado en menos de 1 hora.

* Respuesta: supersecretpassword

Puesto de usuario – Nivel avanzado

9. ¿Cómo entró el atacante en el Sistema?
Pregunta libre, así como aperitivo (se está haciendo un costillar barbacoa a fuego lento, así que todavía tengo dos horas para el reto… aunque tengo HAMBRE). Vamos a empezar a analizar logs y ver qué sacamos:

Aquí tenemos un Powershell malicioso como la copa de un pino. Aunque no tengamos un detalle exacto de cómo ha llegado hasta ahí, nos da un marco temporal del incidente.

Analicemos la MFT en ese día a ver qué encontramos (recordad que para convertir a UTC hay que restar dos horas, por lo que estaremos buscando nuestra actividad maliciosa alrededor de las 18:40h). Y vaya si encontramos cosas ordenando los ficheros por su fecha de acceso (solo ponemos los bocados jugosos):
Ejecución de Powershell:

Descarga de un .hta de Internet y ejecución

Ejecución de ipconfig (comando clásico de reconocimiento)

Conexión por Team Viewer

Este último es que nos da premio. Si os fijáis con cuidado parece que el fichero ha sido creado y accedido al mismo tiempo, lo que nos indica que es la primera vez que ha sido usado. Si recuperamos el fichero de disco y lo examinamos tenemos nuestro resultado:

Todavía no sabemos cómo ha conseguido las credenciales, pero el acceso ha sido mediante un honesto y trabajador TeamViewer

* Respuesta: TeamViewer

10. ¿Cuándo inició sesión el atacante por primera vez en el equipo? [formato UTC TIme Date Format Month/Day/Year 24 Hour Time 1/1/2018 22:00:00]

Qué bien sientan los combos de respuestas, otro 2×1 :D . Salvando de nuevo la maldita costumbre americana de los bailes de días y meses, tenemos la respuesta en nada:

* Respuesta: 08/07/2018 18:34:43

11. ¿Qué cuenta empleó el atacante para iniciar sesión a través de rdp?

Esta parece bastante sencilla porque tan solo tenemos que revisar los logs de Terminal Server. Sabiendo que el ataque se produce sobre las 18.40h (20.40h en los logs), buscamos conexiones:

… pero inexplicablemente no nos la aceptan como correcta. Seguimos buscando:

El segundo intento es Administrator, que es aceptado como correcto (aunque no queda del todo claro el motivo).

* Respuesta: Administrator

12. ¿Cuándo cambió la constraseña por última vez la cuenta que acabas de identificar? [formato UTC Time Format Year-Month-Day 24 Hour Time 2018-01-01 14:01:01]

El último cambio de contraseña se queda guardado en la SAM. Regripper + SAM y salimos corriendo con la respuesta (que ya teníamos de respuestas anteriores):

* Respuesta: 2018-08-07 19:31:56

13. ¿Qué le dio al atacante acceso al resto de cuentas de Max Powers?

Aquí tenemos una respuesta rápida. Como ahora tenemos un puesto de Escritorio deberíamos de tener una carpeta en C:\Windows\Prefetch en la que se quedan guardadas las últimas ejecuciones de programas. Un poco de WinPrefecthView nos debería de dar la respuesta:

KeePass (un conocido gestor de contraseñas) está instalado en el equipo. Y si buscamos por ficheros con la extensión .kdbx comprobamos que el usuario mpowers tiene un fichero de KeePass en “Mis Documentos”. Si lo buscamos en la MFT comprobamos además que el fichero había sido accedido poco antes de la intrusión:

por lo que es posible que, o bien el usuario empleara la misma contraseña para su KeePass … o que estuviera abierto cuando el atacante iniciara sesión por TeamViewer.

* Respuesta: KeePass

14. ¿Cuál es el nombre del fichero que almacena la información que has identificado en la pregunta anterior?

Pin pan pum. Como a Hannibal Smith, “me encanta que los planes salgan bien” … y que las respuestas vengan de dos en dos.

* Respuesta: safeplace.kdbx

15. ¿Cuál es la contraseña del fichero que has identificado que permitió al atacante acceder al resto de sistemas?

Esto suena a más trabajo para nuestro Hashcat. Tan solo es necesario extraer el password cifrado del fichero de Keepass, algo que podemos hacer con el script keepass2john. Una vez convertido podemos usar John the Ripper o Hashcat al gusto

Ya que hemos usado antes hashcat, ahora vamos a usar John the Ripper.Sacamos a pasear el diccionario de varios millones de palabras cuidadosamente construido… y el password resulta ser 123456:

Referencias:

• https://www.rubydevices.com.au/blog/how-to-hack-keepass

* Respuesta: 123456

16. ¿Qué contraseña tiene el usuario max powers en el servidor de ficheros? (la respuesta es sensible a mayúsculas)

Tenemos el fichero de KeePass, y tenemos la contraseña. Tan solo nos hace falta el software, del que podemos descargar una versión portable aquí:

https://sourceforge.net/projects/keepass/files/KeePass%202.x/2.40/KeePass-2.40.zip/download

* Respuesta: DhhZrwRyEOQwbiJl97a4

17. ¿Cuál es la dirección IP del equipo de adquisición de la imagen forense?

Ya sabemos por otras preguntas que el Blue Team está usando F-Response, así que nos cuesta poco localizarlo en el Escritorio del usuario mpowers. Para saber cuándo llegó allí tan solo tenemos que preguntarle a la MFT:

La MFT nos indica que el fichero se creó el 7 de Agosto a las 23:54, y que fue accedido la última vez el día siguiente a las 16:48, por lo que ya tenemos un marco temporal. Vamos a ver qué nos dicen los logs al respecto. Nos dedicamos a revisar el log del cortafuegos de Windows buscando por reglas que permitan el acceso interno al puerto 5682 (el que la documentación de F-Response indica que se usa por defecto) sin éxito.

Sí que encontramos una buena cantidad de reglas que dejan el acceso a este programa:

Ruta de acceso de la aplicación: C:\users\mpowers\desktop\sub-win-x64_104.148.109.107_5682_3262.exe

Que curiosamente en su nombre tiene la cadena “5682”, y que está en la misma carpeta que el fresponse.msi. Si lo extraemos de la imagen ya podemos ver la “F” característica de F-Response. Para asegurarnos calculamos su hash, y preguntamos a VirusTotal

En efecto, el fichero pertenece a F-Response. Si lo ejecutamos en una VM Windows parece ser el cliente de adquisición, en el que aparece la IP como servidor de licencias.

Referencias:

• https://f-response.com/assets/pdfs/F-ResponseManualv7.pdf

* Respuesta: 104.148.109.107

Puesto de usuario – Nivel experto

18. ¿Cuál es la dirección IP y puerto usados para alojar el código malicioso empleado en el primer ataque?
En la pregunta 49 hemos visto en la MFT que se han descargado un .hta, y el sufijo “:Zone.Identifier” implica que ha sido descargada desde Internet.

Toca analizar la navegación del usuario mpowers con BrowsingHistoryView… y encontramos algo muy interesante justo antes de que empiece la actividad maliciosa:

Al parecer el usuario mpowers ha accedido a su correo en Office365 (email – mpowers@magnetic4nsics.com), y justo después se ha cargado una hoja de Google Docs. Si miramos la URL en detalle encontramos algo muy interesante:

Tiene toda la pinta de un phishing en toda la regla. Y el último acceso a “formResponse” parece indicar que el formulario ha sido completado, lo que le da al atacante las credenciales de acceso al sistema. Si accedemos a esa hoja de Google (siempre desde Tor y con muuuuucho cuidado) nos encontramos con que Google ya la ha tirado abajo por ser maliciosa:

Todo esto es muy ilustrativo para ver qué ha pasado en el ataque, pero no nos contesta a la pregunta. Sabemos el nombre del fichero con el código malicioso (out.hta), sabemos que ha sido descargado desde Internet y sabemos el marco temporal. Si no está en los resultados del BrowsingHistoryView hay varias posibilidades:

1. El atacante se ha descargado el código usando “algo” que no es un navegador.
2. El atacante ha limpiado sus huellas.
3. La herramienta BrowsingHistoryView no está funcionando tan bien como debería.

Dado que BrowsingHistoryView ya nos ha dado problemas en este reto (creo que puede ser debido a Windows 10) vamos a acceder a pelo al historial de Chrome como ya hemos hecho anteriormente. Un poco de nuestra herramienta para abrir BD SQLite y ya tenemos nuestra respuesta localizada:

¡Ouch! No parece gustarle la respuesta. Dándole unas cuantas vueltas al coco, a lo mejor se refieren a lo que pueda estar metido dentro del out.hta encontrado en el punto anterior. Si accedemos al fichero en cuestión con FTK Imager comprobamos que es un clásico dropper de Powershell con el código en base64:

Que podemos decodificar con alegría para comprobar el código fuente del Powershell a ejecutar:

Puesto en bonito y formateado ligeramente con Sublime Text tenemos la respuesta:

* Respuesta: 142.93.50.86:80

19. ¿Cuál es el nombre del fichero ejecutado por el atacante desde la IP identificada anteriormente?

¡Otro combo 2×1! La currada de la pregunta anterior nos deja la respuesta hecha.

* Respuesta: out.hta

20. ¿Qué programa es realmente?

Recordar, no se dan de comer a los Gremlin después de medianoche, y no se suben muestras de bichos a VirusTotal en mitad de un incidente. Pero lo que sí que podemos hacer perfectamente es calcular el hash con HashMyFiles:

Y subir el hash a VirusTotal, lo que nos da una coincidencia:

https://www.virustotal.com/#/file/b81d8be8521da1e53427337ca64167672a8bbf5bbc71a568194d901650754585/community

En efecto, es malicioso pero sin tener un nombre concreto. Ya que tenemos el script entero, vamos a buscar alguna cadena característica, por ejemplo la siguiente:

El primer resultado de Google es suficiente:

El culpable es nuestro querido y odiado Empire, post-explotación para Windows a la carta 24×7 con todos los extras que un atacante puede desear para liarla parda en nuestro sistema.

* Respuesta: empire

Conclusiones

Al final han sido unas 40h+ invertidas en conseguir terminal el reto, con preguntas fáciles y complicadas, divertidas y un poco coñazo. Vamos, como casi todos los retos 

Quizás el problema que le podría encontrar es la didáctica final. En muchos CTF de seguridad se trabaja en responder preguntas de diversas categorías, que casi siempre tienen poca o nula relación unas con otras.

Sin embargo, un reto de DFIR tiene una oportunidad única: el hacer que responder las preguntas vaya desgranando poco a poco el incidente. De esta forma se consiguen dos objetivos: por un lado, el aprender a resolver cuestiones individuales y por el otro (y casi más importante) el aprender cómo se resuelve un incidente a través de las preguntas planteadas. En este caso el hilo conductor no está mal, pero una orientación de un tipo más “contar una historia” habría sido mucho más didáctica.

Pros

• He terminado el reto de la DEFCON (eso tiene que dar por lo menos +500 PX, o al menos un poco de satisfacción personal
• He refrescado cosas que tenía medio muertas de la estructura interna de NTFS
• He aprendido a manejar herramientas para gestionar shadow copies

Cons

• El reto era más largo que un día sin pan. Un reto de 63 preguntas es solo para los que hacen ultramaratones.
• Algunas preguntas se han quedado con una respuesta un tanto vaga (pero es algo endémico de muchos retos, dependiente en muchas ocasiones de la plataforma empleada)

En general un buen sabor de boca con el reto. Y a nivel meta, más ideas y experiencias para aprender a cómo hacer mejores retos …

La entrada DEFCON 2018 DFIR CTF – Reto forense (Nivel 3 + Conclusiones) aparece primero en Security Art Work.

Siguiendo con nuestra serie de artículos de seguimiento de botnets IoT, en el siguiente artículo vamos a analizar el malware Sunless, el cual fue detectado en nuestros honeypots entre el 18 y el 19 de diciembre.
Este malware se caracteriza por distanciarse en gran medida de variantes basadas en Mirai, incorporando mecanismos de eliminación de la “competencia” a través de técnicas rudimentarias, vistas anteriormente en mineros.

Infección

Tal y como podemos observar en la imagen inferior, Sunless recicla el método de infección característica del malware IoT, utilizando el famoso script bricker.sh, el cual podemos encontrar en numerosas fuentes abiertas.

En dichos registros, ya podemos encontrar el dominio de descarga de la botnet

http://bot[.]sunless[.]network

Análisis del bot

Si llevamos a cabo el análisis del binario, lo primero que encontramos es la ejecución en pantalla de un bonito mensaje de bienvenida a la botnet:

A continuación, lleva a cabo el escaneo de información del sistema para detectar posibles procesos maliciosos. Dicho escaneo es llevado a cabo a través de la busqueda de strings características en las siguientes rutas:

Las cadenas de texto que busca en cmdline son las siguientes:

Por otra parte, las cadenas que busca en maps, son las siguientes:

Una vez detecta esta información, además de matar el proceso detectado, se transmite al servidor C2, con dirección IP 217.61.6[.]249, a través de las siguientes peticiones:

Tras llevar a cabo la fase de persistencia, comienza el escaneo de dispositivos TELNET, a través de peticiones SYN a puertos 23 y 2323.

En caso de detectar un dispositivo TELNET, éste informa al servidor C2 de dicha disponibilidad, notificando al servidor a través del dominio scanlisten.sunless[.]network.

Detrás de Sunless

Si hacemos caso a la salida por pantalla del binario y accedemos al Instagram, la visualización del perfil es la siguiente:

Únicamente contiene dos publicaciones, ambas relacionadas con el mundo de la denegación de servicio vía IoT. La primera de ellas hace referencia al panel de control cyber-stress[.]us, el cual no parece estar activo en el momento de la redacción del presente artículo.

Otra información adicional, son los precios del alquiler de la botnet:

Esta información nos permite relacionar a la botnet Sunless con la variante LEAN de Mirai, pues el dominio cyber-stress[.] ya fue detectado como parte de su infraestructura, por lo que podríamos deducir que la gente detrás de ambas botnets es la misma.

Así pues, gran parte del formato parece estar alejado a las variantes más características del malware IoT por lo que todo apunta que sí se está trabajando en nuevas aproximaciones en la infección de dispositivos, siendo ésta más compleja a cada día.

IoC

Scanlisten[.]sunless[.]network
bot[.]sunless[.]network
217.61.6[.]249
cyber-stress[.]us

Regla Yara

La entrada Análisis de Linux.Sunless aparece primero en Security Art Work.