TDL4 reloaded: Purple haze all in my brain

TDL4 reloaded: Purple Haze all in my brain

A new TDL4 sample includes novel privilege escalation mechanisms in the dropper and changes to the hidden storage system.

A new TDL4 sample includes novel privilege escalation mechanisms in the dropper and changes to the hidden storage system.

Update: Mila's own blog on the topic is now available here. Other vendors may find the MD5 useful:   A1B3E59AE17BA6F940AFAF86485E5907. However, Mila reports that detection of the sample is already improving.

Update 2: just to clarify, Aleksandr and Eugene should get the credit for the analysis, as is usual with our collaborations. I'm just the scribe/editor round here. :)

Update 3: you can get ESET's stand-alone cleaner for Win32/Olmarik here.

[ New data from my colleagues in Moscow.]

This week we received an untypical sample of Win32/Olmarik.AYD (TDL4) from Mila (of the contagiodump blog). We have already spent a long time tracking TDL4 bootkit family (The Evolution of TDL: Conquering x64) and this time we are seeing key modifications to the dropper and hidden file system. In the dropper we find some interesting mechanisms for privilege escalation: this is something we haven’t seen before in Win32/Olmarik droppers. The first interesting discovery is that the dropper downloads and executes a legitimate Adobe Flash Player installer to be launched in the context of the “trusted” application. In the November of the last year Win32/Sirefef (ZeroAccess) used the same technique to implement a DLL hijacking attack with the msimg32.dll module.

 

This time TDL4 uses the ncrypt.dll module for implementing the attack and to install a bootkit on the system with trusted process privileges. We wonder how long this bug will be on our tail?

 

The next interesting finding is its mechanism for escalating privilege using a COM Elevation technique trick on 64-bit systems.

 

Everyone remembers the trick for bypassing HIPS with the AddPrintProvidor() WinAPI function, but this time the technique relies on a new function AddMonitor() for loading the malicious module in the address space of the trusted system process.

 

The names of all stored modules have been changed in the hidden file system. The hidden container is now stored without encryption. This modification may have been made in order to bypass cleaning and detection algorithms in security software.

 

Next, some small changes have been made to the fake kdcom.dll module (Win32/Olmarik.AWO): before this update the malicious driver was loaded in a modified KdDebuggerInitialize1() using the ExQueueWorkItem() system function, in order to create the system worker thread and give control to the malicious routine.

 

In the latest version the modified KdDebuggerInitialize1()function call straightaway sets a notify routine. It’s possible that this modification is also intended to bypass static signature detection by security software.

 

The new name for the configuration file is “Purple Haze”, on account of the  inclusion of a header string from of the song same name by Jimi Hendrix. :)  

Only one encrypted file is stored in the hidden file system, the file containing C&C domain names. The encryption algorithm used is RC4 with the constant key “phs [file name of encrypted file]”.

 

And finally, we would like to mention a string constant applied to the pdb file path within compiled modules. We have already written (Evolution of Win32Carberp: going deeper) about how this string can disclose some information about the projects path on the developer’s computers. J This time, however, the developer has used randomly generated names for his projects.

 

I foresee a whole bunch of Hendrix song titles in forthcoming security blogs. ..

Aleksandr Matrosov
Eugene Rodionov
David Harley

Discussion