[EP_X0FF]

BTW , EP_X0FF do you think the "services.exe" and the CLSID variant are the sames?

Not enough data available.

There's also a desktop.ini (PE) into the GAC. What for?

This is 0 entry point "proxy" dll used by ZeroAccess itself. As you might know while injection ZA replaces some system dlls in memory with it's own code.

[kmd]

@EP_X0FF

what file it? i slow and dont get it, is it win32?

Preliminary results indicates file structure modification (DYNAMICBASE flag removed from header characterics - ASLR bypassing) + some additional code injected inside with jump to it from services.exe!ScRegisterTCPEndpoint. Overall 9 injected procedures, 7 of them calls one big with dexoring loop.

[Tigzy]

Thanks!
So it pushes this PE into GAC for 2 reasons, 1/ this is "hidden" (at least with explorer) from user. 2/ PE are reachable everywhere (GAC is in the %path%) ?

This is 0 entry point "proxy" dll used by ZeroAccess itself. As you might know while injection ZA replaces some system dlls in memory with it's own code.

So which component is it? Cause the injected dll is in Windir/Installer/_GUID_/n . What proxy? I thought this version was not using rootkit anymore.

[EP_X0FF]

@EP_X0FF

what file it? i slow and dont get it, is it win32?

http://www.kernelmode.info/forum/viewto ... 882#p13882

This is infected x64 services.exe from win7

[EP_X0FF]

While playing with this sample https://www.virustotal.com/file/66e15bd ... /analysis/ under x64 in continuation of yestarday reversing we have confirmed standalone x64 backdoor component which is equal to x86 version (sirefef droppers crossplatform), payload included both x64 and x86 version of proxy dll "desktop.ini" inside. Dropper by the way works along with signed Flash installer (mentioned somewhere here before) and trying to escalate admin rights - resulting in infinite loop of UAC popups.



No infected services.exe

If someone has recent, badly detected Sirefef's droppers with size 160 - 180 Kb then please upload.

[kmd]

If someone has recent, badly detected Sirefef's droppers with size 160 - 180 Kb then please upload.

i got pack of fresh two days bastards but they all "CLSID case". why this size?

[EP_X0FF]

If someone has recent, badly detected Sirefef's droppers with size 160 - 180 Kb then please upload.

i got pack of fresh two days bastards but they all "CLSID case". why this size?

Well calculate yourself.

Sirefef dropper ~160 Kb, comparing with previously used 200+ Kb it is regress due to code simplification, drivers removal, obfuscator changes.

Signed Flash Installer is about 90 Kb, even very good packed it is still ~45 Kb in size. Dropper logic ~10-15 Kb. Obfuscator they use usually adds trash code of few tens of kilobytes (varies). Payloads 40 Kb x 2. By the way this infected services.exe maybe not victim of Sirefef but payload it downloaded :) So complete services.exe ADS dump also welcomed.

prooflink considering obfuscator

https://www.virustotal.com/file/b0f8f55 ... 339501658/

This is dropper without obfuscation. All data still stored inside encrypted but overall as you see size downs for 30 Kb.

P.S.
MSS completely killed tested sample under x64 :)

[EP_X0FF]

For all who interested and seems no one not willing to share this, IDK why. Easy way to complete Sirefef droppers fuckup and extracting all resources from it. Step by step.

To be able to decrypt dropper you need a basic knowledge how Sirefef installs itself. This is quite complex malware installation process with combination of different stages, shellcode injections and Adobe dll's spoofing (yes Adobe mad skillz even here, already discussed, nothing interesting).

Overall work scheme:

0. Adobe Flash Installer working as loader for malware dropper. Signed and trusted, facepalm.
1. Obfuscator decrypts container with payload and redirects execution flow to it. Bpx NtResumeThread and you have totally decrypted stuff in dropper memory. Carefully cut it off. We are working with this binary now.
2. Dropper check environment and self deletes itself on error (cmd.exe shellcode)
3. If everything fine it additional memory pages in Explorer.exe memory and maps another shellcode here, causing "n" to be loaded inside Explorer.exe. "n" includes "desktop.ini" component inside as raw data.

Authors of this crap were so lazy to implement aplib so they decided to use MS Cabinet format instead. Take decrypted binary from step 1 and locate cabinet signature MSCF.



Cut the data to new file. Unzip/whatever it and all is done.

Cabinet archive info (in bytes):
Total size: 193184
Packed size: 104293

The above mentioned sample contains:

Code: Select all

Name                           Size(bytes)

fp.exe (Adobe Flash Installer)       89248
n32 (sirefef x86 edition)            56832
n64 (sirefef x64 edition)            43008
s32 (config for x86)                 2048
s64 (config for x64)                 2048

As everybody now knows from Flame hysterics there are several TimeStamps inside PE32 files, so you can take a look when these components was compiled :)

[Blaze]

Just to add, someone saw the following into his Internet Explorer:


Anyone saw this as well ? Unfortunately, the system was formatted before I could take a look.


Does anyone also have some fresh droppers of this CLSID variant ? Cheers !

[EP_X0FF]

Not everything with ZeroAccess string is ZeroAccess malware and not every ZeroAccess malware has ZeroAccess string inside.