Pasan los años y los documentos de office siguen siendo los reyes de la fase de acceso inicial. En esta ocasión, encontramos un documento de excel sospechoso en la escena de un cifrado con Lockbit. Para más inri, el documento no se ejecutaba en ninguna máquina virtual y encima se encontraba protegido con contraseña.
El documento que vamos a analizar en esta ocasión fue detectado gracias a la inteligencia de Office 365, lamentablemente lo detectó cuando el daño ya estaba hecho, discos cifrados, copias perdidas, etc. Por tanto, el objetivo es ver como se ha llegado a esa situación y extraer el máximo número de indicadores de compromiso posible.
Este fichero se puede encontrar fácilmente en varias sandbox públicas buscando por el hash SHA1: c42cfc7914aa1b64706ff6f6db062902faa4edf6. En nuestro caso, el nombre del fichero era PO080M2022.xlsx.
Episodio 1: El documento que nunca se ejecuta
Como todo buen analista que se precie, lo primero es intentar ejecutar el malware en una sandbox privada y ver qué información podemos extraer. Para nuestra desgracia, el fichero no hacía absolutamente nada.
No obstante, sí que se podían observar algunos detalles interesantes, que certificarían que se trata de un documento malicioso, así como otros que nos ayudarían a identificar su forma de actuar.
Vista del documento desde any.run
Como puede verse en la imagen el documento de fondo es una factura borrosa, con un mensaje de «Contenido bloqueado» en primer plano. El objetivo de los atacantes era llevar a la víctima a habilitar las macros y el contenido para poder ejecutarse. No obstante, no aparece la famosa “Yellow bar”, así que procedemos a habilitarlo manualmente.
Documento protegido con contraseña
No iba a ser tan fácil, el documento se encuentra protegido con contraseña, por lo que no se puede «Habilitar la edición», probablemente los atacantes hayan incluido dicha contraseña en el correo que acompañaba al documento al cual no tenemos acceso.
Llegados a este punto abandonamos el análisis semiautomático en pro de un análisis dinámico manual.
Para hacer un análisis dinámico manual, utilizamos una máquina virtual windows 7 preparada para estos casos. La máquina cuenta con varias herramientas de análisis de malware, conexión a internet falsificada, así como algunas modificaciones para reducir las detecciones.
Lamentablemente, al igual que en el caso anterior, no se ejecuta.
Episodio 2: El análisis decisivo
Continuando con la máquina de análisis de malware, procedemos a analizar estáticamente el documento.
Primero revisamos si el documento tenía o no macros, sorprendentemente no ejecuta ningún tipo de macro, esto se puede deber a un formato erróneo del documento, a que ejecuta macros de otro tipo como las macros 4.0 o bien porque utiliza CVEs para ejecutarse.
Continuamos explorando el documento en busca de características relevantes, así como de su método de ejecución. De esta forma observamos que el documento aparentemente tiene dos páginas: Sheet 2 y Sheet3.
¿Dónde está la “Sheet1”?
Al tratar de mostrar la hoja que falta, de nuevo nos encontramos con el problema del documento protegido, así que nos ponemos manos a la obra a quitarle dicha protección. Para ello utilizamos un conocido script en VBA para la recuperación de contraseñas de documentos cifrados.
|
Sub PasswordRecovery() ‘ Dim i As Integer, j As Integer, k As Integer Dim l As Integer, m As Integer, n As Integer Dim i1 As Integer, i2 As Integer, i3 As Integer Dim i4 As Integer, i5 As Integer, i6 As Integer On Error Resume Next For i = 65 To 66: For j = 65 To 66: For k = 65 To 66 For l = 65 To 66: For m = 65 To 66: For i1 = 65 To 66 For i2 = 65 To 66: For i3 = 65 To 66: For i4 = 65 To 66 For i5 = 65 To 66: For i6 = 65 To 66: For n = 32 To 126 ActiveSheet.Unprotect Chr(i) & Chr(j) & Chr(k) & _ Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & Chr(i3) & _ Chr(i4) & Chr(i5) & Chr(i6) & Chr(n) If ActiveSheet.ProtectContents = False Then MsgBox «One usable password is » & Chr(i) & Chr(j) & _ Chr(k) & Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & _ Chr(i3) & Chr(i4) & Chr(i5) & Chr(i6) & Chr(n) Exit Sub End If Next: Next: Next: Next: Next: Next Next: Next: Next: Next: Next: Next End Sub |
Más información en: http://excelzoom.com/how-to-recover-lost-excel-passwords/.
Una vez se ha ejecutado, nos aparecerá una ventana con una contraseña que, a pesar de no ser la original, sirve para desproteger el documento y ver que contiene la hoja “Sheet1”:
Password: AABBABAABBBR
El contenido de la hoja no es más que un objeto similar a una fotografía con caracteres extraños. Este objeto está identificado con el id «574». Al tratarse de un objeto OLE, se procede a utilizar la herramienta oledump.py de DiddierStevens para analizar el documento y ver que está escondiendo.
Esta herramienta, nos permite identificar y extraer los objetos de tipo «OLE» que contiene un documento de office. Un objeto «OLE» no es más que un elemento externo al documento de office que ha sido incrustado. Habitualmente se utiliza para insertar documentos en otros documentos, imágenes o gráficos generados dinámicamente, no obstante, los atacantes han encontrado la forma de explotar estos objetos para almacenar código y ejecutarlo.
Previamente a la ejecución de oledump.py se debe guardar el documento descifrado, ya que de lo contrario sus elementos y estructura no podrá ser identificada. Como podemos comprobar, el hash del documento desbloqueado ha cambiado al SHA1: 670808970da87937f46665da9d5febeb2c3a4498, así como el tipo de fichero ha pasado de ser CDFV2 Encrypted a Microsoft Excel 2007+.
Mime type de los ficheros de Excel.
Al ejecutar el comando oledump.py sobre el fichero en cuestión se observa como este únicamente tiene un objeto «OLE» incrustado se trata de oleObject1.bin (SHA1: 9920e6d873421507dc6c7d2e516a068f00d08129). Si seleccionamos dicho objeto y le extraemos las cadenas de caracteres podemos ver lo siguiente:
Contenido del OLE oleObject1.bin
Se comprueban las sospechas de que el objeto 574 era un objeto malicioso, ya que su contenido es una URL contra la que debería haber contactado el documento. Como vemos esta accede a la dirección ip 172.245.142[.]47 y descarga el documento www.doc.
Episodio 3: El último enviado
Habiendo visto cómo actuar en caso de encontrarnos con un documento protegido, solo queda ver el desenlace de este caso. Al no conseguir que el documento se ejecutara, hemos descargado el documento www.doc(SHA1: 71374d2aaf0090b04e33cd3d7dc3c8fbc4a1fa38) directamente desde servidor de los atacantes.
Este es un documento de tipo Rich text format, con lo que a priori parecen ser datos aleatorios. Sin embargo, se puede observar que no se trata de un documento legítimo ya que los atacantes le han introducido una serie de modificaciones que dificultan su análisis. Por suerte para nosotros, este documento sí que se ejecuta correctamente, por lo que no será necesario analizarlo estáticamente.
Por destacar una de las modificaciones que han hecho los atacantes, han editado las cabeceras del fichero de forma que no se pueda identificar fácilmente como fichero RTF. Esto se puede detectar analizando las cabeceras del fichero si después de la palabra RTF se encuentra un número que no coincide con una versión de RTF.
Fichero RFT modificado por los atacantes.
Fichero RTF Legítimo.
Al igual que en la primera parte, procedemos a lanzar el documento any.run y enseguida vemos como este intenta contactar contra una nueva IP (84.38.132[.]25) desde la que descarga un fichero. Segundos después se ejecuta el fichero descargado, el cual resulta ser un cliente de Putty (SHA1: 73016558c8353509b15cd757063816369e9abfa7), al que llaman vbc, el cual no ejecuta nada más.
Comunicación desde eqnedt32.exe.
Tras revisar el árbol de procesos generado, se puede ver como hace uso del CVE-2017-11882 el cual utiliza una vulnerabilidad en la gestión de la pila del proceso EQNEDT32.exe (proceso encargado de la edición de ecuaciones) para ejecutar código directamente en la memoria. De esta forma los atacantes han podido descargar este Putty y automáticamente trabajar con él sin pasar por disco.
Árbol de procesos de www.doc
Dada la falta de información sobre cómo se ejecutaba el primer documento, no podemos tener una total certeza de que hacían los atacantes con el binario de Putty descargado.
Reglas de hunting:
| TTP ID | Descripción | Microsoft ATP | Palo Alto Cortex XDR | SentinelOne |
| T1218 | Contacto contra una dirección IP desde el proceso del editor de equaciones. | DeviceNetworkEvents
| where InitiatingProcessFileName == «eqnedt32.exe» and RemoteUrl matches regex @’\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}’ |
config case_sensitive = false
| dataset = xdr_data | filter event_type = enum.NETWORK and actor_ process_ image_ name = «eqnedt32.exe» and action_ external_ hostname ~= ‘\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}’ |
src.process.name contains («eqnedt32»)
| filter dst.ip.address matches «.+» | columns event.time , endpoint.name , src.process.cmdline, dst.ip.address |
| T1036 | Comunicación contra URL con caracteres “-“, “.” y “_” alternados | DeviceNetworkEvents
| where RemoteUrl matches regex @’\/[\.\_\-]+\/’ |
config case_sensitive = false
| dataset = xdr_data | filter http_req_uri ~= ‘\/[\.\_\-]+\/’ |
event.category = «url»
| filter url.address matches («\/[\.\_\-]+\/») | columns event.time , endpoint.name , src.process.cmdline, tgt.process.cmdline, dst.ip.address, url.address |
Regla yara automática:
| rule ERISCERT_auto_2022_11_09_PO080M2022_xlsx { meta: description = «Automatically generated rule – file PO080M2022.xlsx» author = «SOTHIS SOC – ERISCERT» reference = «https://www.sothis.tech» date = «2022-11-09» hash1 = «786f1e09be7324d3a2a977447cf12770d522b5e1c221aca258d628b212f5f8d8» strings: $s1 = «EncryptedPackage2» fullword wide $s2 = «Root Entry» fullword wide /* Goodware String – occured 46 times */ $s3 = «Microsoft Enhanced RSA and AES Cryptographic Provider» fullword wide /* Goodware String – occured 153 times */ $s4 = «PkNi[B~3{+» fullword ascii $s5 = «HD.xCe*» fullword ascii $s6 = «VOcX;{Q» fullword ascii $s7 = «#HYzppsyO7>`uZ» fullword ascii $s8 = «BUXW2.oQ» fullword ascii $s9 = «xcpcB2~» fullword ascii $s10 = «StrongEncryptionDataSpace» fullword wide /* Goodware String – occured 1 times */ $s11 = «Microsoft.Container.EncryptionTransform» fullword wide /* Goodware String – occured 1 times */ $s12 = «\\!Znbf» fullword ascii $s13 = «j,tw#;,BXP6r» fullword ascii $s14 = «%$r}]{» fullword ascii $s15 = «W/wQmuA» fullword ascii $s16 = «Lm`B(x» fullword ascii $s17 = «f8gkbp» fullword ascii $s18 = «0(!I9{» fullword ascii $s19 = «:5h`=w» fullword ascii $s20 = «E_a;pAj2f» fullword ascii condition: uint16(0) == 0xcfd0 and filesize < 200KB and 8 of them } |
IOCs:
| TIPO | IOC |
| SHA1 | c42cfc7914aa1b64706ff6f6db062902faa4edf6 |
| SHA1 | 670808970da87937f46665da9d5febeb2c3a4498 |
| SHA1 | 9920e6d873421507dc6c7d2e516a068f00d08129 |
| IP | 172.245.142[.]47 |
| SHA1 | 71374d2aaf0090b04e33cd3d7dc3c8fbc4a1fa38 |
| IP | 84.38.132[.]25 |
| SHA1 | 73016558c8353509b15cd757063816369e9abfa7 |
