El PDF Inocente que Esconde un JavaScript Malicioso Listo para Atacar

Hace tiempo que quería analizar algún PDF infectado con JavaScript. Para hacerlo, he recurrido a la web virusshare.com, donde se puede encontrar todo un repositorio de virus, entre ellos algunos como el que nos ocupa hoy.

Para el análisis, voy a descargarlo en una OVA de REMnux, que tiene preinstaladas las herramientas que voy a utilizar.

En primer lugar, voy a usar peepdf para hacerme una idea de lo que tengo delante:

root@remnux:/home/remnux/Desktop/virus# peepdf infectado.pdf
Warning: PyV8 is not installed!!

File: infectado.pdf
MD5: 01881d7396b9e0ade93beb53fad0c76f
SHA1: 92eb5e23d05dce678baa20b61d5bd7cd4fd1df3b
SHA256: a1b549e8efaa7d0439ed2edb8f0a0b94a43bbfe773008458583b75855dac10c3
Size: 12966 bytes
Version: 1.6
Binary: True
Linearized: False
Encrypted: False
Updates: 0
Objects: 11
Streams: 2
URIs: 0
Comments: 0
Errors: 0

Version 0:
	Catalog: 23
	Info: No
	Objects (11): [1, 2, 5, 8, 17, 18, 19, 20, 21, 22, 23]
	Streams (2): [8, 17]
		Encoded (0): []
	Objects with JS code (2): [8, 17]
	Suspicious elements:
		/AcroForm (1): [23]
		/OpenAction (1): [23]
		/XFA (1): [21]
		/JS (1): [22]
		/JavaScript (1): [22]

En efecto podemos ver que tenemos algunos objetos JavaScript.

Vamos a ver que info nos da también pdfid.py

root@remnux:/home/remnux/Desktop/virus# pdfid.py infectado.pdf
PDFiD 0.2.8 infectado.pdf
 PDF Header: %PDF-1.6
 obj                   11
 endobj                11
 stream                 2
 endstream              2
 xref                   1
 trailer                1
 startxref              1
 /Page                  2
 /Encrypt               0
 /ObjStm                0
 /JS                    1
 /JavaScript            1
 /AA                    0
 /OpenAction            1
 /AcroForm              1
 /JBIG2Decode           0
 /RichMedia             0
 /Launch                0
 /EmbeddedFile          0
 /XFA                   1
 /URI                   0
 /Colors > 2^24         0

Mas de los mismo.

Veamos los objetos que tenemos con pdf-parser.py

Me llama la atención el objeto numero 8 que peepdf nos dice que contiene codigo JavaScript.

pdf-parser.py -o 8 -c infectado

Esto es lo que guarda en el stream:

Podemos ver un documento xml con el Javascript que buscamos y que obviamente está ofuscado

Lo reduzco para hacerlo asequible.

En este punto, lo que he intentado hacer es aislar el JavaScript y utilizar el interprete de Firefox para tratar de ver que tenemos detrás, pero no ha sido posible. Así que el primer paso ha sido ponerlo bonito y luego revisarlo cambiando cosas para hacerlo funcional.

El problema parece venir de la propia ofuscación de algunas variables. Arreglándolo podemos ver lo que andamos buscando. Una cadena enorme de caracteres– que oculta todo el mal del mundo- y una función «eval» que lo ejecuta. Yo he creado la variable salida para ver que esconde esa cadena. El resultado:

Obtenemos otro código, como no, ofuscado también.

Podemos usar alguna herramienta online para hacerlo legible. Yo lo he hecho, lo he arreglado un poco para hacerlo funcional, se lo he dado a ChatGpt y le he pedido que comente cada una de las lineas. El código es extenso y esta ofuscado, así que no parece razonable pegarlo todo. Voy a comentar solo las partes que me parecen interesantes.

Si nos fijamos bien, podemos encontrar muy fácilmente la carga maligna que luego vamos a analizar. Esta en las variables _l1 y _l2 en hexadecimal.

En la función _I0 es especialmente importante porque nos revela algo más de la naturaleza del ataque.

En la variable dakRote podemos ver el valor %u9090. Esta es una representación en hexadecimal que utiliza la notación unicode (con %u), donde 9090 es el valor en formato hexadecimal. Unescape(‘%u9090’) lo convierte en 0x90 que a bajo nivel es una instrucción NOP. Esto es una técnica ampliamente utilizada en ataques de desbordamiento del buffer o heap spraying. Básicamente una función NOP no hace nada y pasa el flujo del programa a otra instrucción. Si se llena la memoria de NOPs (NOP sled) y el flujo del programa aterriza en cualquier parte de esta secuencia “resbalará” a través de los NOPs hasta llegar al código malicioso.

En la función _ji1 podemos ver el uso de XOR, que es una técnica de ofuscación muy utilizada en malware por su simplicidad.

Visto eso vamos a revisar esas cadenas de _l1 y _l2. En realidad son las mismas con algunas variaciones. Nos vamos a centrar en una y vamos a usar vxHexEditor que viene instalado en Remnux. Para hacérmelo cómodo he usado CyberChef para ver que encuentro ahí…

De primeras podemos ver que hay una url desde la que intenta descargar un recurso. Después lo he guardado como un archivo de datos y se lo he pasado a vxHexEditor.