La fiebre del hash: Una mirada al ataque de Medusa

Artículo por Andrés Godoy, especialista en ciberseguridad NIVEL4.

Las redes sociales parecen ser una fuente de comunicación más rápida que ciertos canales oficiales y en esta ocasión WhatsApp nos alertó de algo que estaba ocurriendo en la empresa de tecnología llamada Sonda.

Rápidamente surgió la fiebre del hash, esa necesidad imperiosa de querer proteger nuestra organización a toda costa y que nos obliga a conseguir los indicadores de compromiso a como de lugar.

Surgen comunicados y la presión aumenta, tanto interna como externamente, hasta que se liberan los primeros IoC. Prontamente nos llega un mensaje el cual dice ser de buena fuente y nos deja relativamente tranquilos para poder continuar lo que estábamos haciendo. 

Pero recordemos qué son los indicadores de compromiso: tal como su nombre lo indica, son valores clave obtenidos de una manera altamente confiable cuyo origen corresponde a un sistema comprometido (o de una red) desde el cual logramos observar, de primera fuente, el elemento que da luces de una parte del ataque. Generalmente cuando se comparten los IoC, hay información que se omite y que puede ser relevante, tal como el contexto acerca de la forma en que fueron obtenidos. Por ejemplo, un ejecutable volcado desde la memoria RAM será distinto al mismo elemento contenido en disco, sobre todo al momento de realizar cálculos criptográficos sobre ellos para obtener el hash MD5, SHA1, etc.

Imagen 1. Cadena de WhatsApp con reenvío de IOC de Sonda

Del listado que surgió en WhatsApp tomemos por ejemplo el primer hash SHA1. Al menos en Virustotal (VT) podemos ver que el primer envío hacia la plataforma fue el día 03 de febrero del 2023 y recientemente alguien lo volvió a subir a VT para una revisión extra del mismo elemento.

El segundo hash marcado en la imagen data del 20 de enero del 2023 y curiosamente también fue subido recientemente.

Por otra parte pensemos en las APT, Advanced Persistent Threat, amenazas persistentes avanzadas las cuales, algunos autores, sostienen que cada APT es un actor de amenaza, pero cada uno de ellos no es necesariamente avanzado o que utiliza técnicas de persistencia. En el caso presentado, no existen indicadores de compromiso que de forma tan veloz hayan revelado que Sonda fue víctima de un actor avanzado ya que dado el tiempo en que se divulgaron estos IoC difícilmente los espectadores podríamos tener un escenario completo del ataque. Sumemos a esta hipótesis el hecho de que la mayoría de estos elementos ya existían en plataformas como VirusTotal, es decir, ¿cuál sería la probabilidad de que nuestra solución de AV no esté actualizada con dichos indicadores?

El sentido del párrafo anterior no es desconfiar de la organización afectada, sino más bien del indicador que se distribuye por medio de una cadena de WhatsApp, tal como lo han sido los avisos de tsunami, desabastecimiento y otros conocidos en los medios.

Lo que nos debería importar realmente es conocer al menos el actor de amenaza que lograron identificar y que muy bien informaron a través de comunicados públicos de forma expedita.

Medusa Locker

Sabemos que los indicadores de compromiso sin un contexto pueden ser fácilmente manipulables. Los hash de archivos pueden variar y nuestra solución de seguridad podría no detectar una variante o, por otra parte, una dirección IP/dominio podría dejar de hospedar la infraestructura maliciosa, es decir, todos estos elementos podrían cambiar durante las etapas del ataque sobre todo si dicha infraestructura fue levantada para una víctima específica y el objetivo ya fue logrado.

El año 2014 David Bianco, instructor SANS, hizo una propuesta bien interesante en la cual plantea que el lugar donde más podemos dañar al atacante es en conocer sus TTPs, Técnicas, Tácticas y Procedimientos. Luego, más abajo en la pirámide están las herramientas y los indicadores.

Poco se conoce del grupo Medusa, salvo que ha causado preocupación por ataques al sector de salud y provoca cierto renombre dentro de los grupos más connotados de las ciber amenazas tipo ransomware.

Lo que sí ha sido estudiado son sus técnicas, tácticas y procedimientos, lo que complementando lo indicado por Bianco, nos podría ayudar enormemente más que un par de hash, direcciones IP y nombres de dominio.

Por ejemplo, una búsqueda por la web sobre TTPs de Medusa Locker nos genera rápidamente una idea acerca de sus tácticas y lo que debemos proteger en nuestra organización.

Acceso Inicial

• El actor realiza técnicas de fuerza bruta sobre servicios RDP públicamente expuestos para identificar cuentas de usuario válidas.
• El actor intenta explotar servicios RDP vulnerables.
• El actor envía correos tipo phishing con adjuntos.

Ejecución

• Ejecución de comandos y scripts basados en Powershell.
• Utilización de WMIC Windows Management Instrumentation para eliminar las “volume shadow copies” y evitar la recuperación de información.
• Crear registros en el host para establecer persistencia.
• Creación de tareas para la ejecución del ransomware.

Escalación de privilegios

• Utilización de Microsoft Profile Installer para bypass de UAC, User Account Control.
• Password guessing sobre RDP dentro de la red.

A este nivel es posible tener una idea clara de que el actor Medusa está enfocado en servicios RDP y en la utilización de Powershell. El resto podrían corresponder a herramientas propias de Windows por lo que un buen diseño de caso de uso generaría las alertas indicadas en el correlacionador de eventos. Si no es prioritario powershell para nuestros colaboradores se puede deshabilitar o al menos activar las características de auditoría y log para esa aplicación.

Los indicadores de compromiso pueden ser útiles cuando son obtenidos de una fuente confiable y necesitamos verificar que dichos elementos no se encuentren replicados dentro de nuestra red o en otros hosts. Complementario a lo anterior, debemos considerar que los grupos de amenazas trabajan generalmente con sectores económicos como objetivos, por lo que si una empresa de tecnología es víctima de un ataque, necesitamos reflexionar acerca de qué elementos podrían tener ambas organizaciones en común y que a su vez puedan convertirnos a nosotros como el siguiente blanco.  

A nivel general nos podemos proteger adoptando las siguientes medidas:

• Restringir o bloquear Powershell si no lo necesitamos.
• Crear caso de uso para la ejecución de de Powershell en especial con la carga de scripts con extensiones .bat o .txt.
• Casos de usos para la ejecución de cmd.exe que levante procesos asociados a bcdedit.exe, reg.exe, sc.exe y shutdown.exe.
• Monitoreo de la herramienta de Windows cmstp.exe (Bypass User Account Control).

MedusaLocker tiende a cerrar los siguientes procesos:

wxServer.exe, wxServerView, sqlservr.exe, sqlmangr.exe, RAgui.exe, supervise.exe, Culture.exe, RTVscan.exe, Defwatch.exe, sqlbrowser.exe, winword.exe, QBW32.exe, QBDBMgr.exe, qbupdate.exe, QBCFMonitorService.exe, axlbridge.exe, QBIDPService.exe, httpd.exe, fdlauncher.exe, MsDtSrvr.exe, tomcat6.exe, java.exe, 360se.exe, 360doctor.exe, wdswfsafe.exe, fdlauncher.exe, fdhost.exe, GDscan.exe, ZhuDongFangYu.exe.

MedusaLocker tiende a terminar los siguientes Servicios:

wrapper, DefWatch, ccEvtMgr, ccSetMgr, SavRoam, sqlservr, sqlagent, sqladhlp, Culserver, RTVscan, sqlbrowser, SQLADHLP, QBIDPService, Intuit.QuickBooks.FCS, QBCFMonitorService, sqlwriter, msmdsrv, tomcat6, zhudongfangyu, SQLADHLP, vmware-usbarbitator64, vmware-converter, dbsrv12,dbeng8.