TDL4 reloaded: Purple Haze all in my brain

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

Author David Harley, ESET

  • questions

    We have completed to its defense?

    • David Harley

      We wouldn’t analyse a sample and discuss it publicly without having a detection for it. :) That doesn’t, of course, mean that we can guarantee detection for all instances of TLD4, unfortunately.

  • Philip96

    InternetCrackUrlA is used as an API?Also what value does it use? ICU_Decode or Icu_Escape?

  • Chris

    What are you using for decompilation of the code above?  Is it Hex-Rays decompiler or something else?

  • Vish

    Hi David,
         Thank you and your colleagues for the earlier analysis of TDL4 – it made for 50 pages of fascinating reading.
    These bootkits have already reached the point where average users find them too difficult to detect / remove. That they even attempt to remove them has to do with the unpleasant  "symptoms" of the accompanying malware. In fact, if the infections did not hinder the user's computing experience so overtly (100% CPU usage, web search redirects etc) most users would probably accept the coexistence of the infection on their systems.

Follow us

Copyright © 2017 ESET, All Rights Reserved.