By Ruben Santamarta
When I was reading the CrySyS report on Flame (sKyWIper), one paragraph in particular caught my attention:
In case of sKyWIper, the code injection mechanism is stealthier such that the presence of the code injection cannot be determined by conventional methods such as listing the modules of the corresponding system processes (winlogon, services, explorer). The only trace we found at the first sight is that certain memory regions are mapped with the suspicious READ, WRITE and EXECUTE protection flags, and they can only be grasped via the Virtual Address Descriptor (VAD) kernel data structure
So I decided to take a look and see what kind of methods Flame was using.
Flame is conceived to gather as much information as possible within heterogeneous environments that can be protected by different solutions, isolated at certain levels, and operated upon by different profiles. Which means that, from the developers point of view, you can't assume anything and should be prepared for everything.
Some of the tricks implemented in Flame seem to focus on bypass just as much AV products, specifically in terms of heuristics. A distributed "setup" functionality through three different processes (winlogon, explorer, and services ) is way more confusing than letting a unique, trusted process do the job; i.e. it's less suspicious to detect Internet Explorer coming from
In essence, the injection method seems to pivot around the following three key features:
· Disguise the malicious module as a legitimate one;
Shell32.dllin this case.
· Bypass common registration methods supplied by the operating system, such as
LoadLibrary, to avoid being detected as an active module.
· Achieve the same functionality as a correctly-registered module.
So, let's see how Flame implements it.
During the initial infection when
DDEnumCallbackis called, Flame injects a blob and creates a remote thread in
Services.exe. The blob has the following structure:
The loader stub is a function that performs the functionality previously described: basically a custom PE loader that's similar to the CryptoPP
dllloader.cpp with some additional tricks.
Injection Context: Blob + 0x710
The loader stub also contains some interesting tricks.
Shell32.dll: A matter of VAD
To conceal its own module, Flame hides itself behind
Shell32.dll, which is one of the largest DLLs you can find on any Windows system, meaning it's large enough to hold Flame across different versions.
shell32.dllhas been mapped, a VAD node is created that contains a reference to the
FILE_OBJECT, which points to
Shell32.dll. Flame then zeroes that memory and loads its malicious module through the custom PE loader, copying sections, adjusting permissions, and fixing relocations.
As a result, those forensics/AntiMalware/AV engines walking the VAD tree to discover hidden DLLs (and not checking images) would be bypassed since they assume that memory belongs to
Shell32.dll, a trusted module, when it's actually
The stub then calls to
DllEntryPoint, passing in
DLL_PROCESS_ATTACHto initialize the DLL.
The malicious DLL currently has been initialized, but remember it isn't registered properly, so cannot receive remaining events such as
And here comes the final trick:
msvcrt.dllis loaded up to five times, which is a little bit weird, no?
Then the PEB
InLoadOrderstructure is traversed to find the entry that corresponds to
msvcrt.dllby comparing the DLL base addresses:
Once found, Flame hooks this entry point:
InjectedBlock1 (0x101C36A1)is a small piece of code that basically dispatches the events received to both the malicious DLL and the original module.
The system uses this entry point to dispatch events to all the DLLs loaded in the process; as a result, by hooking into it Flame's main module achieves the goal of receiving all the events other DLLs receive. Therefore, it can complete synchronization tasks and behaves as any other DLL. Neat.
I assume that Flame loads
msvcrt.dllseveral times to increase its reference count to prevent
msvcrt.dllfrom being unloaded, since this hook would then become useless.