Storm (aka Peacomm/Nuwar/Zhelatin/Tibs) is known to be repacked every few minutes. Even if its sample is modified, recompiled and then re-packed with a different packer, it can still be recognized as Storm by looking at its memory contents.
Such “recognition” is possible due to the same patterns that repeat in its memory from generation to generation. As long as they can be recognized visually, the automation can recognize them too.
ThreatExpert recognises these patterns during the static analysis of the memory contents of Storm, which is obtained during the dynamic phase of the analysis.
To show these repeating patterns, let's consider two samples of Storm: an earlier one (circa January, 2008) and the latest one (the “April Fool’s” one).
What these 2 samples have in common?
They both are the droppers.
In the first case, the dropper injects the code into the process services.exe, as seen in the report:
ThreatExpert automation will inspect two newly created memory objects in this case: the dropper's process itself and the newly allocated pages on the heap of services.exe, where the injected code is running:
The memory content of the dropper’s process resembles an unpacked image of the original file. However, the stub that it carries inside for further injection into services.exe is still packed. Thus, it’s difficult to find any effective signatures in the dropper’s memory itself (they would not be generic enough).
On the other hand, the code injected into services.exe contains an unpacked image of the packed stub contained in the dropper. The injected code is a perfect place to choose generic Storm signatures:
The new (“April Fool’s”) Storm uses a different memory model – the dropper will drop and load a DLL file testdll_f.dll into its own dropper process - this can be seen very well in the report:
ThreatExpert automation inspects this new model as shown below:
As in the first case, the new dropper’s process also has no valuable signatures to select. The only one more or less appropriate signature in it is:
But it’s too short and is not generic, e.g. the next Storm variant will use a different name of the DLL that it drops and loads, thus this signature won’t be detected. Because of this reason, we will ignore it and have a closer look at the memory contents of its DLL once it’s loaded into the dropper’s process:
If you look closer, the memory content of this DLL is very similar to the previously shown code injected into services.exe. It’s not identical, but the patterns are the same.
The picture below simply compares the final memory contents of both samples of Storm, side-by-side, to show what patterns are identical:
Recognizing the patterns that are constant across multiple generations of Storm guarantees a reliable generic detection of all Storm samples + any zero-day samples that the author of Storm will release in the future.
What kind of packer was used, how many encryption layers were added, what memory injection mechanism was chosen – all of this is irrelevant. In order to run, it needs to unpack itself at some point, and once it does so, ThreatExpert will inspect its memory contents: be it a process, a module, or a heap page, and recognize the common Storm patterns.
The analysis of samples from two different generations clearly shows that Storm is not evolving at all, apart from trying various dumb tricks.
In other words, "And you, no matter what position, will never make a fine musician", a Russian fable writer Krylov once said about the quartet that tried to play better music by switching seats.
