Flame: Component nteps32.ocx ... or should we call it Tosy?
Analysis of another Flame component - a DLL file
There is slight difference in the parameters used in the encryption algorithm.
Here is the reconstructed logic of the decryptor:
Passing it an encrypted string below:
results in the following decoded output:
As you can see, this time, 16th byte keeps the 'encrypted' flag (used to be 8th), the string size is now kept in the 18th byte (used to be 9th), and the string itself starts from the byte #20 (used to be #11).
Obviously, these parameters are random. The author of this threat must be keeping all the original strings in a separate file, and then a separately executed script selects random encryption parameters and then encrypts those strings, producing the source files for compilation. This is similar to how ZeuS encrypts its strings.
Decrypting entire file is also possible by using the same tool that was suggested before. A file with the fully decrypted strings reveals interesting details.
First, the DLL contains a list of domain name substrings that are used for filtering out the websites it is interested in monitoring:
Next, it contains a long list of security processes that is it designed to detect:
Now, the final exercise.
Compare the lists above to the ones reported here and try to spot 10 differences.
Look similar, don't they?
Update (31 May 2012): changed Tossy into Tosy.
nteps32.ocx
, reveals that its strings are also encrypted, just like in soapr32.ocx
.There is slight difference in the parameters used in the encryption algorithm.
Here is the reconstructed logic of the decryptor:
void Decrypt2(LPBYTE lpBuffer)
{
if (lpBuffer[16]) // 16th byte is a flag "encrypted"
{
for (BYTE i = 0; i < lpBuffer[18]; i++) // 18th byte is the string size
{
lpBuffer[20 + i] -= GetKey2(i); // encrypted string starts from 20th byte
}
lpBuffer[16] = 0; // clear "encrypted" flag (16th byte)
}
}
Passing it an encrypted string below:
BYTE szTest[] = {0x15,0xEE,0x8A,0x6D,0x13,0xF0,0xD4,0x55,0x5B,0x0A,0x61,0x17,0x70,
0x88,0xDF,0x0A,0x90,0x7D,0x52,0x00,0xCA,0xA2,0x0F,0xE8,0x5B,0x37,
0xAE,0x8D,0x17,0xEB,0x71,0x52,0xD3,0xBC,0x40,0x37,0xC5,0xB1,0x4E,
0x3C,0xBB,0xC2,0x67,0x59,0xF4,0xFF,0xA6,0xA6,0x3B,0x49,0x10,0x0C,
0xDD,0xCA,0x9D,0x81,0x4C,0x5C,0x3C,0x27,0x04,0x06,0xDB,0xFC,0xE4,
0xD3,0xA2,0xDA,0xBE,0xDD,0xA6,0xC8,0xAB,0xF7,0xD2,0xEE,0x0B,0x0E,
0x27,0x55,0x37,0x78,0x84,0xB3,0xBD,0xFA,0x11,0x32,0x39,0x6D,0xA0,
0xD0,0xC3,0x34,0x03,0x8F,0xBC,0xDE,0xE9,0x56,0x48,0xD1,0x00};
Decrypt2(szTest);
results in the following decoded output:
15 EE 8A 6D 13 F0 D4 55 5B 0A 61 17 70 88 DF 0A 00 7D 52 00 48 | ...m...U[.a.p....}R.H
00 4B 00 4C 00 4D 00 5C 00 53 00 4F 00 46 00 54 00 57 00 41 00 | .K.L.M.\.S.O.F.T.W.A.
52 00 45 00 5C 00 4B 00 61 00 73 00 70 00 65 00 72 00 73 00 6B | R.E.\.K.a.s.p.e.r.s.k
00 79 00 4C 00 61 00 62 00 5C 00 70 00 72 00 6F 00 74 00 65 00 | .y.L.a.b.\.p.r.o.t.e.
63 00 74 00 65 00 64 00 5C 00 41 00 56 00 50 00 37 00 | c.t.e.d.\.A.V.P.7.
As you can see, this time, 16th byte keeps the 'encrypted' flag (used to be 8th), the string size is now kept in the 18th byte (used to be 9th), and the string itself starts from the byte #20 (used to be #11).
Obviously, these parameters are random. The author of this threat must be keeping all the original strings in a separate file, and then a separately executed script selects random encryption parameters and then encrypts those strings, producing the source files for compilation. This is similar to how ZeuS encrypts its strings.
Decrypting entire file is also possible by using the same tool that was suggested before. A file with the fully decrypted strings reveals interesting details.
First, the DLL contains a list of domain name substrings that are used for filtering out the websites it is interested in monitoring:
- .hotmail.
- gawab.com
- gmail.com
- live.com
- mail.
- maktoob.com
- rocketmail.com
- yahoo.co
- ymail.com
Next, it contains a long list of security processes that is it designed to detect:
- 4gui.exe
- antihook.exe
- app_firewall.exe
- asr.exe
- authfw.exe
- avgamsvr.exe
- avgcc.exe
- avgemc.exe
- avgfwsrv.exe
- avginet.exe
- avgupsvc.exe
- avp.exe
- avpm.exe
- blink.exe
- blinkrm.exe
- blinksvc.exe
- bootsafe.exe
- cclaw.exe
- cdas17.exe
- cdinstx.exe
- clamd.exe
- cmdagent.exe
- configmgr.exe
- cpf.exe
- dcsuserprot.exe
- dfw.exe
- dvpapi.exe
- eeyeevnt.exe
- elogsvc.exe
- emlproui.exe
- emlproxy.exe
- fameh32.exe
- fch32.exe
- firewall 2004.exe
- fpavserver.exe
- fprottray.exe
- fsaua.exe
- fsav32.exe
- fsbwsys.exe
- fsdfwd.exe
- fsgk32.exe
- fsgk32st.exe
- fsguidll.exe
- fsguiexe.exe
- fsm32.exe
- fsma32.exe
- fsmb32.exe
- fspc.exe
- fspex.exe
- fsqh.exe
- fsrt.exe
- fssm32.exe
- fw.exe
- fwsrv.exe
- gateway.exe
- icmon.exe
- ike.exe
- ipatrol.exe
- ipcsvc.exe
- ipctray.exe
- jpf.exe
- jpfsrv.exe
- kav.exe
- kavmm.exe
- kpf
- kpf4ss.exe
- licwiz.exe
- live help.exe
- lpfw.exe
- mpsvc.exe
- netguard lite.exe
- netmon.exe
- nip.exe
- njeeves.exe
- nstzerospywarelite.exe
- nvcoas.exe
- nvcsched.exe
- nvoy.exe
- oeinject.exe
- omnitray.exe
- onlinent.exe
- onlnsvc.exe
- op_mon.exe
- pcipprev.exe
- pf6.exe
- pfsvc.exe
- pgaccount.exe
- procguard.exe
- pxagent.exe
- pxconsole.exe
- rdtask.exe
- r-firewall.exe
- rtt_crc_service.exe
- sab_wab.exe
- scanwscs.exe
- sp_rsser.exe
- spfirewallsvc.exe
- sppfw.exe
- spyhunter3.exe
- spywareterminator.exe
- spywareterminatorshield.exe
- ssupdate.exe
- superantispyware.exe
- swnetsup.exe
- swupdate.exe
- sww.exe
- tikl.exe
- tinykl.exe
- tray.exe
- tsansrf.exe
- tsatisy.exe
- tscutynt.exe
- tsmpnt.exe
- umxagent.exe
- umxcfg.exe
- umxfwhlp.exe
- umxlu.exe
- umxpol.exe
- umxtray.exe
- updclient.exe
- vcatch.exe
- vdtask.exe
- vsdesktop.exe
- vsmon.exe
- wsweepnt.exe
- wwasher.exe
- xauth_service.exe
- xfilter.exe
- zanda.exe
- zerospyware le.exe
- zerospyware lite.exe
- zerospyware lite_installer.exe
- zlclient.exe
- zlh.exe
Now, the final exercise.
Compare the lists above to the ones reported here and try to spot 10 differences.
Look similar, don't they?
Update (31 May 2012): changed Tossy into Tosy.
3 Comments:
Hello, so despite the encrypted strings, it has the same behavior as Tossy?
Nice work, but if the information is available to the public, you can't draw any conclusions from that. Loads of malware is armed with a CuteFTP, FlashFXP, etc. stored information decoder, this is just because the information on how to do it is so widely spread, that implementing it takes a few seconds on google and a few minutes of coding...
Thank you, Nick.
The strings in the post are very unique (i.e. gawab/maktoob) - no other threat ever carried the same lists apart from Tosy. Tosy was also an OCX file. So if it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home