Se ha escrito mucho sobre los ataques del troyano bancario RTM contra contadores y directores financieros, incluidos los
expertos del Grupo IB, pero hasta ahora no ha habido un solo estudio de caso de dispositivos infectados con RTM en el ámbito público. Para corregir esta injusticia, uno de los principales expertos en informática forense del Grupo IB,
Oleg Skulkin , habló en detalle sobre cómo llevar a cabo una investigación forense de una computadora infectada con un troyano bancario como parte de una respuesta / investigación de incidente.
Como empezó todo
Los investigadores se enteraron de las actividades del grupo criminal RTM en diciembre de 2015. Desde entonces, los correos de phishing que distribuyen este troyano se han enviado a los buzones electrónicos de las víctimas potenciales con una constancia envidiable.
Como ya sabe, de septiembre a diciembre, el grupo RTM envió más de 11,000 correos electrónicos maliciosos. Los ciberdelincuentes no se detendrán ante lo que se ha logrado, como lo demuestran todos los nuevos correos que registramos tanto en los sensores que protegen a nuestros clientes como en el marco de la recopilación de datos sobre las amenazas actuales.
En este artículo, le diré cómo realizar una investigación forense, o simplemente forense, de la imagen de una unidad de computadora infectada con un troyano RTM bancario.
Introductorio necesario
Imagine que no sabemos acerca de la infección de la computadora RTM, sino solo el hecho del compromiso, cuyo resultado fue el robo de dinero; esto nos permitirá construir el proceso de investigación de manera más interesante y también hacer que sea aplicable a otros casos. También quiero llamar la atención sobre el hecho de que en el marco de este artículo no me detendré en la ingeniería inversa del troyano: en primer lugar, esto no es competencia del científico forense, y en segundo lugar, mi colega, Semyon Rogachev, ya escribió sobre esto en detalle en
Habré .
Entonces, todo lo que tenemos es la imagen del disco de la computadora en el formato "E01" (Encase Image File Format). Para empezar, sería bueno saber qué hay dentro. Como mínimo, el sistema operativo, porque es de él y de su versión, por supuesto, de la que depende la presencia de ciertos artefactos forenses que tenemos que investigar.
1. Utilizaremos la utilidad mmls del paquete del kit de detective de Brian Carrier:
Que tenemos Varias particiones NTFS similares a Windows. Debemos asegurarnos de que trataremos de encontrar archivos de registro, por ejemplo, SOFTWARE.
2. Utilizaremos las utilidades fls (el Kit de Detección) y findtr para encontrar el número de registro correspondiente en la tabla de archivos principal (MFT):
Ok, ahora podemos copiar el archivo que necesitamos para un análisis posterior usando icat (el Kit de Detección):
icat -o 718848 E: \ RTM.E01 234782> SOFTWARE
Entonces, tenemos un archivo de registro de SOFTWARE, podemos extraer la información más importante de la cual, por ejemplo, usando RegRipper Harlan Carvey. Actualmente estamos interesados en el contenido de la sección Microsoft \ Windows NT \ CurrentVersion:
Ahora sabemos que la computadora en estudio ejecutaba Windows 7 Professional con Service Pack SP1, lo que significa que sabemos qué artefactos forenses podemos encontrar y cuáles podemos necesitar.
¿Dónde comenzar nuestras búsquedas? Recordemos la paradoja de Jesse Kornblum: "El malware puede esconderse, pero debe ejecutarse". Un buen comienzo puede ser la búsqueda de posibles mecanismos de bloqueo en el sistema que permitan que los programas maliciosos se reinicien después del reinicio de una computadora.
Comencemos con uno simple: tome el
archivo de registro
NTUSER.DAT del directorio del usuario (C: \ Users \% username% \) con la fecha de modificación más reciente y extraiga los datos del mismo utilizando el mismo RegRipper. Si queremos obtener el número de registro del archivo que necesitamos usando fls y findtr nuevamente, necesitamos agregar la opción –p a fls - esto permitirá que la utilidad muestre las rutas completas a los archivos. ¿Por qué se necesita esto? El hecho es que cada usuario tiene un archivo NTUSER.DAT en el directorio, y SOFTWARE es el único para todo el sistema, por lo que en este caso es importante obtener el número de registro de un archivo específico. En general, no es necesario usar el Kit Sleuth, existen herramientas más convenientes, por ejemplo,
FTK Imager , una herramienta de desarrollo gratuita de AccessData que puede usarse no solo para crear copias forenses, sino también para examinar su contenido:
Comencemos con las frutas bajas, las llamadas
"teclas de ejecución" :
Entonces, ¿qué tenemos? La sección se modificó por última vez el 7 de noviembre y vemos que cuando el usuario inicia sesión, el archivo apg.exe se inicia desde una ubicación no estándar. Veamos qué más se puede encontrar en el directorio b7mg81:
TeamViewer? Interesante Echemos un vistazo más de cerca a apg.exe: use
PPEE :
Parece TeamViewer, registrado como TeamViewer, entonces, ¿es TeamViewer? Parece asi. Pero no es tan simple. Veamos la tabla de importación:
Entonces, msi.dll, en algún lugar ya vimos este archivo, y no es C: \ Windows \ System32, sino el mismo directorio b7mg81. A juzgar por el tamaño, no tiene nada que ver con el msi.dll original, lo que significa que está disponible -
Secuestro de órdenes de búsqueda de DLL : el sistema operativo comienza a buscar las bibliotecas necesarias del directorio actual, lo que significa que en lugar del msi.dll legítimo, se cargará el que se encuentra. en b7mg81.
Otro archivo interesante es
TeamViewer.ini :
Y aquí está la contra forense: a juzgar por el archivo de configuración, nuestro TeamViewer no mantuvo ningún registro y, aparentemente, se usó como una RAT. Bueno, no esta mal. Es hora de averiguar si comenzó en absoluto.
Hay bastantes artefactos en Windows que indican que se están ejecutando archivos ejecutables. Continuemos trabajando con el registro, esta vez con el
archivo SYSTEM . Para extraer datos de él, puede volver a usar RegRipper.
Estamos interesados en ControlSet001 \ Control \ Session Manager \ AppCompatCache. Aquí encontraremos una lista de archivos ejecutables con rutas a ellos, fechas de la última modificación (de acuerdo con el atributo $ STANDARD_INFORMATION), así como un indicador que indica si el archivo se inició o no:
Genial, nuestro archivo se lanzó al menos una vez. Entonces, tenemos algún "punto de pivote", sabemos que el 7 de noviembre TeamViewer apareció en la unidad de la computadora, que no guardaba registros, y probablemente no era visible para el usuario, ya que en lugar de la biblioteca legítima cargó la que está en uno con ella catálogo
Es hora de comenzar a construir una línea de tiempo. Creo que eso es suficiente de lo que se puede construir con el Kit Sleuth. Comencemos con la utilidad fls que ya conocemos:
fls.exe -m "C: /" -o 718848 -r -z GMT D: \ RTM.E01> bodyfile.txt
Ahora use mactime para convertir el archivo resultante en una línea de tiempo:
mactime.pl -d -b bodyfile.txt> timeline.csv
Las líneas de tiempo son muy convenientes para analizar en el
Timeline Explorer de Eric Zimmerman . Nuestra línea de tiempo incluirá solo eventos del sistema de archivos. Si desea que incluya cambios en el registro, revistas, etc., puede usar plaso. Personalmente, lo uso extremadamente raramente, ya que el procesamiento de datos lleva mucho tiempo, y el resultado es a menudo bastante redundante.
De vuelta a la línea de tiempo. El catálogo b7mg81 fue creado el 7 de noviembre de 2018 a las 13:59:37:
Y dos segundos antes de esto, se crea el archivo 21DA.tmp:
Si busca su suma de comprobación, por ejemplo, en VirusTotal, obtendremos resultados bastante interesantes:
Obviamente, nuestro RAT fue desempaquetado de este archivo. Adelante
Incluso antes, el directorio LocalDataNT se crea con archivos bastante interesantes en su interior. Eche un vistazo a WinPrintSvc.exe, por ejemplo:
Remote Utilities es otra herramienta de administración remota. Y aquí hay otro archivo sospechoso creado unos segundos antes:
Comprueba su suma de comprobación:
Varios productos antivirus lo detectan inmediatamente como "
RemoteAdmin ". Aparentemente, él es la fuente de Remote Utilities. Compruebe si se inició la RAT detectada. Esta vez utilizaremos el archivo de registro AmCache.hve de C: \ Windows \ AppCompat \ Programs (el mismo RegRipper permitirá obtener datos de él en forma digerible):
Como puede ver en la ilustración, AmCache nos permite obtener no solo la fecha del primer lanzamiento, sino también la suma de comprobación del archivo.
Entonces, tenemos dos RAT, pero ¿de dónde vienen? Buena pregunta! Si todavía desplaza la línea de tiempo, veremos rastros de la creación de un directorio y archivo bastante sospechoso:
A pesar de la extraña extensión, fnbfdnja.hej tiene un título familiar:
¿Qué nos mostrará la búsqueda de suma de comprobación de VirusTotal? Y aquí está lo que:
Como puede ver en la ilustración, algunos programas antivirus detectan nuestro archivo definitivamente: estamos tratando con
RTM . VT puede ayudarnos un poco más. Si miramos la pestaña "Relaciones", veremos esto:
Parece que encontramos al héroe de la ocasión: se trata de "Documentos para October.exe". O tal vez no, el nombre asociado con nuestro archivo es diferente, aunque la suma de verificación es la misma. Entonces, nuevamente .exe, lo que significa que nuevamente debemos buscar rastros de inicio. Personalmente, me gusta mucho trabajar con el registro, así que nuevamente usaré la ayuda del ya conocido archivo NTUSER.DAT y RegRipper. Esta vez eche un vistazo a
UserAssist : de él obtenemos los nombres y las rutas a los archivos, las fechas de su último lanzamiento, así como el número de estos lanzamientos. El archivo "Documentos para October.exe" no está visible, pero sí otro archivo:
C: \ Users \% username% \ Desktop \ Documents environment.exe
Bueno, eso parece ser lo que necesitamos. Es cierto, hay un pequeño problema: no hay ningún archivo en el lugar correcto. De vuelta a la línea de tiempo. Después de crear el archivo fnbfdnja.hej, esto es lo que sucede:
Los archivos en el directorio Temp probablemente pertenecen a RTM, pero no estamos interesados en ellos. Estamos interesados en los archivos $ R6K21RQ.exe y $ I6K21RQ.exe. Esto es exactamente lo que parecen los archivos colocados en la "Papelera de reciclaje": el primero contiene los datos en sí, el segundo contiene los metadatos. Si observamos el contenido de $ I6K21RQ.exe, inmediatamente vemos la ruta al archivo deseado: "Documents environment.exe".
Es hora de echar un vistazo a lo que VT nos ofrecerá para su suma de comprobación:
Vemos detecciones que ya nos son familiares: "RTM". Al final resultó que, la suma de comprobación de nuestro archivo coincidió con la suma de comprobación "Documentos para October.exe". Además, VT conoce algunos archivos más con la misma suma de comprobación:
Sería bueno obtener algún tipo de indicadores de compromiso de la red. No tenemos un volcado de memoria, volcado de tráfico de red también, ¿qué debo hacer? Intercambiar archivo! ¿Pero cómo encontrar una aguja en un pajar? Y aquí VT también nos ayudará un poco, esta vez
la pestaña
Comportamiento :
Suena como C2, ¿verdad? Veamos si hay algo como esto en nuestro archivo de intercambio (pagefile.sys). Por supuesto, hay:
Entonces, confirmamos que nuestro archivo interactuaba con 185.141.61 [.] 246. Intentemos encontrar más indicadores de red. Una de las RAT fue TeamViewer, intentaremos encontrar algo similar a su ID. Para esto, puede, por ejemplo, usar expresiones regulares:
Genial, tenemos otro indicador de red: 195.123.219 [.] 87. Por supuesto, los archivos de intercambio no solo son adecuados para encontrar indicadores de red. Si volvemos a la pestaña Comportamiento en VT, veremos que nuestro archivo crea tareas en el programador. Si miramos la línea "fnbfdnja.hej", encontramos esto:
La tarea creada inicia fnbfdnja.hej a través de rundll32.exe.
Bueno, es hora de redondear. Es hora de determinar de dónde proviene el archivo "Documents environment.exe". Ya sabemos que esto es RTM, y dado que es RTM, el vector más probable de infección es un correo electrónico de phishing. En este caso, la víctima usó Microsoft Outlook, por lo que encontramos el archivo .ost con el correo en el lugar habitual, y en él el mismo correo electrónico de phishing:
Sin embargo, no quiero terminar nuestra publicación sobre esto, sino sobre otro artefacto interesante. Si volvemos al archivo NTUSER.DAT y observamos el valor del parámetro "Shell" en la sección Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon, en lugar del habitual "explorer.exe" veremos esto:
Y esto significa que después de que el usuario inicie sesión en lugar de iniciar Explorer, el sistema se apagará y, con ello, completará este artículo.