A few other sources of information have stated that there isn’t much that has changed with these binaries. That may not be completely true.
The packer itself has changed. So much, in fact, that AV detection for these binaries is non-existent. Is the “Tibs” packer not being used? What is so different about this one that is causing problems for signature-based solutions?
First off, let’s look at the static characteristics of the newest executables: two sections, .text and .rdata are present. Instead of nonsensical lists of outdated, disjointed and unused api calls in its import directory, this one contains four imports from kernel32.dll, like a number of other packers commonly used by legitimate packers.
Here is a screenshot of the import nonsense that packed Storm executables exhibited in the middle of last year, based on an executable used for our Virus Bulletin 2007 presentation:
And here is the tight listing of imports for this new Storm variant:
Frank Boldewin provided a great paper on the Storm packer/cryptor algorithms used in previous Storm executables’ unpacking stubs. He even provides visual aides to demonstrate the runtime flow:
1. First stage xor decrypter (or decoder)
2. Second stage TEA decrypter
3. TIBS unpacker
But not only has this set of unpacking steps changed, the executable payload doesn’t include kernel level components anymore. A dll (testdll_f.dll) is unpacked within the downloaded executable’s process space, which then drops a copy of the aromis.exe executable to the windows directory, and adds the executable path to the Windows firewall exception list — something Storm attacks previously evaded with kernel mode injection into services.exe. There is no file mapping based driver infections, this variant simply adds a value to the current user’s run registry key. We’ll have to look into this one further, it is a stripped back variant as far as autostart sophistication goes.
This code has changed quite a bit from what we would expect from Storm. More details to follow.
