Home > Articles

Peacomm.C
Cracking the nutshell

Version:
1.0

Last Update:
21th September 2007

Author:
Frank Boldewin / www.reconstructer.org

This paper mainly focuses on two topics. The first one aims to extract the native Peacomm.C code from the original crypted/packed code, which means the following issues are covered in detail:

• First stage XOR decrypter
• Second stage TEA decrypter
• TIBS Unpacker
• Anti-Debugging code
• Files dropping
• The driver-code infection
• Finding the OEP to the native Peacomm code
• Finding and patching the VM-detection tricks

The second topic covers all the rootkit techniques of the spooldr.sys driver. These issues are:

Security products monitoring/disabling

• SSDT file hiding
• Shellcode injection for process spawning
• System files locking

As goody to this paper, also included are the different binary dumps and commented IDA .idb files.

As always use caution when reproducing the work described here. Consider employing a virtual machine like VMWare or Virtual PC and perform the analysis on an isolated network to avoid the damage that could be caused by this malware. Use at your own risk!



3. Target Overview

To get an overview of our target first let's have a look at the chart in figure 3.1

Figure 3.1:


The first thing that happens in "area 1" right after the start of applet.exe is an easy XOR decryption of the data in "area 3" followed by jumping to this area which contains code now and performs several tasks, like files dropping, decrypting and unpacking the native Peacomm code in "area 2" and so forth. In the end all the imports for the native binary are being collected/set and the code in "area 2" gets executed to attend to its "real business". But let's cover this step by step.



4. 1st Stage decrypter or how to fool Antivirus emulator-engines

The figure 4.1 shows the complete routine used to decrypt the code in "area 3". The instruction at 0x40101e tells us the data of EAX it getting XORed with the value of 0x0149594f. But also take a look at the instructions above. Next to XORing the data the return value of a call to the function FreeIconList is added at 0x401019 as well.

Figure 4.1:



Why this? - You might ask now, because the FreeIconList call should always return the same value in EAX. So, this is a really useless behaviour, right? The solution is, that this is an often used malware trick, to crash or trigger an exception in Antivirus sandbox engines, because FreeIconList is a legacy function of windows and thus often not emulated by AV engines. While doing the research for this paper I've downloaded several samples of applet.exe and found out that next to the XOR key also lot's of other legacy API functions are used. Additionally, I've also discovered that the decryption engine completely changes from time to time. All of these routines were easy to understand for a reverser, but definitely doing its jobs to hide from AV signature based malware detection. Right after all the data has been decrypted (0x38d0 bytes) a jump at 0x40102d executes the code in "area 3" at 0x42321f. If you try to load applet.exe into the IDA disassembler, you won't be able to see the decrypted data at 0x42xxxx, because the binary works with fake PE- Header information. This could be fixed to see everything in the idb file, but you still would have crypted data in this area and an extra idc-script would be needed to emulate the decryption. A much faster way is to load applet.exe into Ollydbg, setting a breakpoint at 0x40102d with F2, running the code until breakpoint occurs, pressing F7 for one single step into "area 3" at 0x42321f and then dumping the whole binary using the Ollydump plugin. This is what I have done to have one idb file for commenting.

5. Anti-debugging and defeating

The next step before we can start reading the disassembly on a relaxed basis is to defeat a small anti-debugging trick. If you load the lately dumped "after 1st stage decryption" binary into IDA the new entry point will be 0x42321f. If you scroll down a little bit to address 0x42330d now, you'll see (figure 5.1) a lot of junk instructions (insb, arpl ...). As this code runs in user mode and insb/arpl instructions are privileged, meaning only usable from kernel mode without an exception and further the last
instruction that makes sense at 0x423308 calls 0x423324, this junk must be something other than code. A short look using the "hexview" of IDA discloses that these "instructions" are for real data or better a string.

Figure 5.1:



So, to get a "clean" disassembly, just mark the area between 0x42330d and 0x423322, press `U' and then `A' in IDA. This should give the result seen in figure 5.2 There are several of these little anti-debugging tricks in the second stage and it's wise to clean the complete disassembly before moving on with manual decompilation. Fortunately for this binary, I have already done all the boring work. ;)

Figure 5.2:

6. TEA decryption and the TIBS unpacker

Like in many other sophisticated malware, also Peacomm makes use of an established cryptographic algorithm. One of the first things that can be done to quickly find signatures of well-known crypto functions is to scan for them. Ilfak Guilfanov, the developer of IDA Pro, wrote a small plugin called findcrypt to do this job. Also an Ollydbg port of this tool is available, but personally I always count on KANAL v2.82 (figure 6.1), a PEID plugin, which has the most signatures from my experience.

Figure 6.1:


As we can see from the snapshot above two signatures were found. The first one at 0x423f44 and the second one at 0x423f93. Furthermore, we get the information, that KANAL found a single DWORD which is used by multiple algorithms like TEA/N, RC 5/6, SERPENT and ISAAC, which
means we have to read some disassembly.

Figure 6.2:


In figure 6.2 you can see the main function of the TEA algorithm. It uses a 128bit key (at 0x426A90) for decryption and will be called several times in a loop until all the data of every PE-section was decrypted.
For further infos and sample implementations of the TEA algorithm consult the link in the references

Right after decrypting all the data with the tiny encryption algorithm the TIBS unpacker routine is called. It enumerates all PE-sections as well and then unpacks its data. The unpacking code can be found between 0x4269f7 ­ 0x426a6e.

This non-public packer is used very often in malware nowadays and most Antivirus companies have a generic detection implemented in their scanning engines by now. So, if a malicious code is not detected by its variant, e.g. because of its polymorphic behaviour, most AV-engines still detect it by reporting something like: Trojan:Win32/Tibs.DU.




7. Files dropping and Windows driver-code infection

After all that decrypting/unpacking has been done, a routine at 0x4239df is called, which disables the windows file protection for tcpip.sys and its cached copy using the non-exported sfc_os.dll function 5 called SfcFileException (see the reference link for further information). Confusingly enough, no more action is done with this file, so I thought it must be an artefact from former variants. First I believed an earlier version of Peacomm patched the max number of outbound connections, which is typical for malware used for DDoS attacks, but friends like Elia Florio from Symantec research told me, that older variants infected tcpip.sys to load the rootkit driver spooldr.sys. But for this special case the kbdclass.sys driver and its cached copy gets infected with additional code for loading the spooldr rootkit driver. Nicolas Falliere added the info, that the SFC infection trick was broken for about 3 weeks. So they've started infecting other driver like kbdclass.sys or cdrom.sys.

Next to the infection of kbdclass.sys two files are dropped. First one is a self-copy of applet.exe saved as spooldr.exe in %systemroot% and the second file is the overlay containing the spooldr.sys driver, which gets detached to %systemroot%\system32.



8. Finding the OEP and dumping the native Peacomm.C binary

Right after dropping the files and infecting the keyboard driver, a routine at 0x423e5b scans the decrypted/unpacked native Peacomm binary for its libraries and belonging function names and stores the matching addresses to the functions.

Then a system command is executed to allow spooldr.exe at the windows firewall with the following command:

netsh firewall set allowed program "%systemroot%\spooldr.exe" enable

The last action is a jump to the OEP at 0x403531 (see figure 8.1).

Figure 8.1:


To get a clean native Peacomm.C binary, just load applet.exe into Ollydbg, set a breakpoint with F2 at 0x40102d, run using F9, clean bp with F2, step into with F7, set a breakpoint at 0x423283, run again, clean bp, step into the allocated memory and search for the jump instructions to the OEP, as this is a dynamic address for sure. Then set a bp, run again, clean bp, step into with again and use the Ollydump plugin to save the binary. That's all! Or if you are lazy, just use my dumped version, shipped with this paper. ;)



9. Cleaning the native code from VME detection tricks

Ok, now as we have a clean native Peacomm.C code for analysis it would also be nice to run it on a virtual machine like VMWare or VirtualPC.
Unfortunately, we have to defeat two vm-detection routines before achieving this. The first check is right after the OEP at 0x403389, calling a routine at 0x4031bc. It's a VMWare detection using the ComChannel VMXh magic trick (see Figure 9.1)

Figure 9.1:



Just some instructions away from the VMWare detection is the second call to a virtual machine detection routine at 0x40339c jumping to 0x40314e.
This time it is a Microsoft VirtualPC detection using the illegal Opcode exception trick (see Figure 9.2). For further information on both VM- detection tricks, read Peter Ferries excellent paper on virtual machine attacks v2. A Link to this paper is included in the references.

Figure 9.2:



If one of the environments is being detected, a jump to a "sleep forever" loop at 0x403524 is called. One easy way to circumvent this, would be to patch 2 bytes at 0x40338f with a direct jump to 0x4033a9 (push ebx).
Use your favourite hex-editor or just Ollydbg, if want to do this.

10. Dissecting the rootkit driver

Ok, you've reached the last part of this small essay. In my opinion the most interesting one, as this rootkit uses some techniques I haven't seen in the past. But before I get into detail, first let's observe what the RkUnhooker report said.

The figure 10.1 just shows an oldschool SSDT hook of the native function NtQueryDirectoryFile and the figures 10.2 and 10.3 reveal the therewith related hidden processes/files.

Figure 10.1:


Figure 10.2:


Figure 10.3:


The figure 10.4 also shows the call to the hooking code for all spooldr* files.

Figure 10.4:


But this is definitely not really a cutting edge rootkit, right?
And any run-of-the-mill AV solution or personal firewall would detect or block this.
So, where's the news?

Take a look at figure 10.5 and you will see a call to the function PsSetLoadImageNotifyRoutine with a parameter that points to a driver- supplied callback routine.

Figure 10.5:


On the windows driver developers site OSR-Online we can read:

"PsSetLoadImageNotifyRoutine registers a driver-supplied callback that is subsequently notified whenever an image is loaded for execution."

For detailed information on this function consult the link in the references.

Figure 10.6 shows us this routine in detail.

Figure 10.6:



As you can clearly see from the commented code at the beginning it checks if a driver or a normal user mode program has been loaded. If it is a program it gets terminated using the ZwTerminateProcess function and if it is a driver, the routine scans for its EntryPoint and patches it with:

XOR EAX, EAX
RETN 8

So, after the driver starts, it just returns with 0 and ends.
As we learned from the former chapters this all happens right after loading an early driver that was infected before, like kbdclass.sys, cdrom.sys or tcpip.sys, who then immediately spawns our rootkit
driver. Every driver and program that is loaded after spooldr.sys is under full control of the rootkit. And now it should be clear why a normal SSDT hook for hiding the driver is enough. No security products, no problems. ;)

Here is a complete list of security products which are disabled at system start:

Zonealarm Firewall
Jetico Personal Firewall
Outpost Firewall
McAfee Personal Firewall
McAfee AntiSpyware
McAfee Antivirus
F-Secure Blacklight
F-Secure Anti-Virus
AVZ Antivirus
Kaspersky Antivirus
Symantec Norton Antivirus
Symantec Norton Internet Security
Bitdefender Antivirus
Norman Antivirus
Microsoft AntiSpyware
Sophos Antivirus
Antivir
NOD32 Antivirus
Panda Antivirus

Check out the After-1st-XOR-Decryption-Dump.idb file for details which executables are in conjunction with these products.


Another sneaky trick can be seen in figure 10.7. This special function scans the explorer.exe process and hooks the import entry of the PeekMessageW function, which is called very often by explorer, with a special shellcode that deletes the import entry for PeekMessageW and spawns the spooldr.exe in this trusted space. This is a nice trick to omit the usage of CreateRemoteThread, which most security products monitor today and as not all available sec-software were included in the termination list, it was a wise decision to use this much more sophisticated way.

Figure 10.7:



The last thing what is worth being mentioned, can be seen in figure 10.8
The rootkit also locks two files, ntoskrnl.exe and the infected kbdclass.sys driver, using NtLockFile. My assumption was that this is to reject access to these files from user mode, e.g. when tools like
Hijackthis try to scan for suspicious changes in these files, because file locking is no stumbling block for kernel mode tools like rootkit scanners or AV-products.

Figure 10.8:



11. Conclusion

After this small excursion into the world of Peacomm.C it should be clear that the developers of this malware deal with a lot of nasty tricks to gain access to victims' machines and hide from detection, even on standard protected boxes. Analyzing malware gets harder and just using the usual auto-analysis tools, seems not very target-aimed. The AV and PFW industry has to think of better heuristics in behaviour analysis, smarter ways of generic unpacking and more reliable system integrity mechanisms to safely recognize such cunning tricks used in sophisticated malware like
this one. As 100% solutions will stay a pious hope, reverse engineering knowledge is still the weapon of choice for the analyst. I hope you enjoyed this paper a little and as always - constructive reviews are much appreciated.

12. References

Peerbot: Catch me if you can
http://www.symantec.com/avcenter/reference/peerbot.catch.me.if.you.can.pdf

Fast-Flux Service Networks
http://www.honeynet.org/papers/ff/fast-flux.pdf

Peer-to-Peer Botnets: Overview and Case Study
http://www.usenix.org/events/hotbots07/tech/full_papers/grizzard/grizzard.pdf

The Tiny Encryption Algorithm (TEA)
http://www.simonshepherd.supanet.com/tea.htm

Attacks on Virtual Machines v2
http://pferrie.tripod.com/papers/attacks2.pdf

Disabling WFP on a file for 1 minute via undocumented SFC API
http://www.bitsum.com/aboutwfp.asp#Hack_Method_3

The PsSetLoadImageNotifyRoutine function
http://www.osronline.com/DDKx/kmarch/k108_5sc2.htm

Big thanks go to Elia Florio and Nicolas Falliere/Symantec, Val Smith/Offensive Computing and Thorsten Holz/German Honeynet Project for reviewing this paper!

Reproduced with kind permission of Frank Boldewin
www.reconstructer.org

This article is also available in PDF format along with the files mentioned from Frank's Site.