Technical Analysis of the Skype Trojan

During December yet another trojan started making rounds, this time dubbed the Skype trojan -- SEO conspiracy. Was the trojan exploiting a zero day vulnerability in the Skype protocol? Absolutely not, as it was basically using Skype's messaging service as a propagation vector, thus, the gullible and in a Christmas mood end user was still supposed to interact with the malware by clicking on the link. And with required end user's interaction, the possibilities for major outbreaks were very limited. Perhaps the only development worth mentioning is the malware author's use of commercial anti-cracking software -- NTKrnl Secure Suite -- to make the unpacking harder, or at least theoretically improve the time needed to do so compared to using publicly obtainable, and much more easily detectable packers.

Two days ago, Nicolas Brulez from Websense Security Labs released a technical analysis of the trojan itself, and here's your proof for the logical possiblities of specific copy'n'paste malware modules :

"The main protection scheme I faced was the copy pasted from my Honeynet Scan of The month 33 Challenge. The breakpoint detection was 100% identical, even the numbers I had generated randomly. More importantly, the technique I had written based on SEH + cpuid/rdtsc was also copied. The only difference was that they used the EDX register to compare the timing.

Copy pasting protection code without even changing it a little, provides no security at all and allowed me to unpack it even quicker. (gotta love looking at code you wrote 2 years ago)

It apparently included some other tricks, that made it a little harder to unpack, and the file looked like it was corrupted at some point. In order to debug it and comment my disassembly in a readable way, I opted to use a userland debugger, and thus had to write a little shellcode for injection into the packed malware. Basically, it entailed abusing Windows Exception Handling (using a hook), to get past every check. After that, one could attach his favorite userland debugger to the malware and eventually find the Original Entry Point. Although the imports rebuilding for this protector isn't hard at all, it wasn't mandatory in this executable as it only imported one function: ExitProcess"

And while the average malware coder is using commercial tools to make his releases harder to analyze, the almighty jihadist is still living in the Hacker Defender world.