Skip navigation.
Home

Storm Worm Reversing Challenge

Hi folks,

Over a year now, Storm has dominated the Malware of its class. (still?)
One of the biggest challenge has been the diversity of packers used on its various versions.

So here is our challenge.

1 - pick up any sample of the Storm Worm Trojan.
2 - unpack it and reconstruct the IAT if needed.
3 - upload your unpacked binary to a fileserver and submit the link here with your comments.

ps* Please don't forget to mention the md5sum of the sample you've chosen.

Clarity of the final unpacked code is what is more appreciated.
So pick up a sample packed with a packer you know quite well to save you some time.

I don't know yet if Val or you other guys have a better organisation idea.

Any comment/suggestion?

asmatiks

My submissions

The Original 591258adc48b422c86730214aef81989

The dropped driver f75ced55ddf2005bf949a35534057887

The kit injected into a running process 9896cc5f8b90265297eada6a045bdc22

Original:

Original: 8d743df03e17526bddba57a3c7c366ca

Unpacked version after XXTEA-decryption: 27fbc55a31d0811367bb03a4e553e894

Unpacked version after stage 2 decryption(ntdll hooks and fake testdll_f.dll), this is the naked bot: eea91bd42785f0e9fc99702c9627c08c

No rootkit driver included in this one.

deadline

Nice posts,

I'm thinking about a deadline to make it more exciting.
suggestion?

asmatiks

Original:

Original: 8d743df03e17526bddba57a3c7c366ca
Unpacked: 7540bbeca4adb67275f91a27291aa6e3

I never found the stage 2 decryption like ralf talks about yet :S

Directly after the XXTEA

Directly after the XXTEA decryption the binary installs several hooks in ntdll.dll and subsequently calls LoadLibrary("testdll_f.dll"). Actually, that file does not exist, but since LoadLibrary makes use of certain ntdll exports which were hooked, the binary tricks LoadLibrary into believing that the file does exist. Subsequent calls by kernel32 in order to load the file's content into memory are manipulated and data is read from the process's binary instead of "testdll_f.dll".
That's what I was talking about. It depends on what you consider as "decryption", maybe the word "unpacking" would be more appropriate. I classed it as another stage of decryption before the "real" bot's code is started :)

OOh that explains why it

OOh that explains why it loaded a module that didn't exist yet it was still loaded successfully.