You are browsing the archive for Malware Analysis.

Beyond good ol’ Run key, Part 47

September 29, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

The persistence mechanism that I am going to describe today is not for the faint-hearted.

When Windows 10 starts, lsass.exe loads Authentication Packages (AP) from the following registry location:

  • HKLM\SOFTWARE\Microsoft\IdentityStore\Providers

The location contains a number of subkeys that use GUID-based naming convention. The default ones are:

  • {B16898C6-A148-4967-9171-64D755DA8520}
    • ApPluginDLLPath=aadcloudap.dll
  • {D7F9888F-E3FC-49B0-9EA6-A85B5F392A4F}
    • ApPluginDLLPath=MicrosoftAccountCloudAP.dll

It’s tempting to add your own f.ex.



The LoadParameters key must contain the Enabled value name – this ensures the DLL is loaded.

However…. there is a little problem (yet it’s one that is good to have!) – the Microsoft developers had a foresight here and made it quite difficult for anyone to abuse these keys.


The DLLs are loaded using LoadLibraryEx with the LOAD_LIBRARY_SEARCH_SYSTEM32 and  LOAD_LIBRARY_REQUIRE_SIGNED_TARGET options on.

  • This means that the DLL must be placed inside the c:\windows\system32 directory (LOAD_LIBRARY_SEARCH_SYSTEM32).
  • Secondly, the DLL loaded from this location must be signed.
  • Thirdly, the DLL not only must be signed, but also compiled with the /INTEGRITYCHECK option on. This ensures that the Kernel-Mode Code Signing (KMCS) checks are enforced.

Finally, the Registry key is owned by Trustedinstaller. One needs to change the owner to modify the access rights and grant the permissions to add/modify the keys.

Practical aspects of it mean that it’s relatively hard to test it (I may describe how to do it later).

Here’s an example from the test system:


Old Flame Never Dies (a.k.a. decompiling LUA)

September 26, 2016 in Batch Analysis, File Formats ZOO, Malware Analysis, Reversing

When the news about Flame exploded all over the media, I remember grabbing available samples and like many other researchers started poking around. Pretty quickly, I extracted a large number of very unique strings from various Flame samples and posted them online.

Recently, I accidentally came across that old post and started wondering if anyone ever posted the decompiled Lua scripts for the malware. I googled around for some of the strings I posted on my blog back then and to my surprise – my blog was the only one showing up!

I guess there must be some conspiracy theory that will explain that…

Back in 2012, I didn’t have all the samples, but I did run them through a quick analysis process which I will describe below. The procedure for obtaining the strings was extremely crude, but like many quick&dirty solutions – it worked pretty well (and it was fast!).

  • For each DLL, load it via rundll32
    • For each exported function, execute it
      • For ever every single execution, delay for some time
      • Grab memory dumps for rundll32
      • Kill rundll32

Interestingly, I still have the memory dumps I used to extract the strings from, so… since I suddenly thought of these Lua scripts I re-used the memdumps to extract over 60 Lua bytecoded scripts (from both static files and memory dumps to be precise).

And here comes the real purpose of the thread – document how to obtain decompiled Lua scripts from Flame:

  • I wrote a quick carving tool in perl to extract Lua bytecode from both static files, and memory dumps
    • This was pretty easy, since the compiled Lua always starts with a header “\x1BLua”
    • For each extracted file, I wrote another quick&dirty script to rename it to the name embedded inside the bytecoded Lua script
    • That’s how we get the ‘original’ name of the files f.ex. ‘MUNCH_ATTACKED_ACTION.lua’ is embedded inside the bytecoded Lua script


  • With all the files preprocessed, I ran them through a Lua decompiler
    • For many files, it worked like a charm; for some, it failed

If you remember Kaspersky’s Flame code from 2012:


you can find the code inside the flame_props.lua.dec file (you need to remove decompiler’s comments):


The collection of all decompiled scripts can be found here.

The password is: old_flame_never_dies

List of all scripts:

  • ___kaspersky.dec
  • attackop_base_prods.lua.dec
  • attackop_base_sendfile.lua.dec
  • ATTACKOP_FLAME.lua.dec
  • ATTACKOP_FLASK.lua.dec
  • ATTACKOP_JIMMY.lua.dec
  • basic_info_app.lua.dec
  • casafety.lua.dec
  • clan_entities.lua.dec
  • clan_seclog.lua.dec
  • CRUISE_CRED.lua.dec
  • euphoria_app.lua.dec
  • event_writer.lua.dec
  • fio.lua.dec
  • flame_props.lua.dec
  • get_cmd_app.lua.dec
  • json.lua.dec
  • leak_app.lua.dec
  • libclanattack.lua.dec
  • libclandb.lua.dec
  • libcommon.lua.dec
  • libdb.lua.dec
  • libflamebackdoor.lua.dec
  • liblog.lua.dec
  • libmmio.lua.dec
  • libmmstr.lua.dec
  • libnetutils.lua.dec
  • libplugins.lua.dec
  • libwmi.lua.dec
  • main_app.lua.dec
  • payload_logger.lua.dec
  • post_cmd_app.lua.dec
  • REG_SAFETY.lua.dec
  • RESCH_EXEC.lua.dec
  • rts_common.lua.dec
  • SECLOG_HANDLER.lua.dec
  • SECLOG_SPOTTER.lua.dec
  • STD.lua.dec
  • storage_manager.lua.dec
  • SUCCESS_FLAME.lua.dec
  • table_ext.lua.dec
  • transport_nu_base.lua.dec
  • USERPASS_CRED.lua.dec
  • WMI_EXEC.lua.dec
  • WMI_SAFETY.lua.dec