Category Archives: Batch Analysis

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

Posted on by

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

munch_attacked_action-lua

  • 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:

kaspersky0

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

kaspersky1

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_FLAME_PRODS.lua.dec
  • ATTACKOP_FLAME_STARTLEAK.lua.dec
  • ATTACKOP_FLASK.lua.dec
  • ATTACKOP_FLASK_PRODS.lua.dec
  • ATTACKOP_JIMMY.lua.dec
  • ATTACKOP_JIMMY_PRODS.lua.dec
  • ATTACKOP_MOVEFILE.lua.dec
  • ATTACKOP_RUNDLL.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
  • IMMED_ATTACK_ACTION.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
  • MUNCH_ATTACKED_ACTION.lua.dec
  • MUNCH_SHOULD_ATTACK.lua.dec
  • NETVIEW_HANDLER.lua.dec
  • NETVIEW_SPOTTER.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
  • SNACK_BROWSER_HANDLER.lua.dec
  • SNACK_ENTITY_ACTION.lua.dec
  • SNACK_NBNS_HANDLER.lua.dec
  • STD.lua.dec
  • storage_manager.lua.dec
  • SUCCESS_FLAME.lua.dec
  • SUCCESS_FLAME_STARTLEAK.lua.dec
  • SUCCESS_GET_PRODS.lua.dec
  • table_ext.lua.dec
  • transport_nu_base.lua.dec
  • TRANSPORT_NU_DUSER.lua.dec
  • TRANSPORT_NUSYSTEM.lua.dec
  • USERPASS_CRED.lua.dec
  • WMI_EXEC.lua.dec
  • WMI_SAFETY.lua.dec

DeXRAY 1.7 – ccSubSdk files – part 2

Posted on by

I have added a buggy routine that attempts to interpret the content of the decrypted ccSubSdk files; this is based purely on looking at the file properties – at first I noticed that there are many GUID-like values that appear in the files many times and across many files. Then looking at the layout I tried to split the data by using these GUIDs as dividers – this was helpful and led to a better understanding of how these chunks are structured. Some patterns started emerging and in the end the serialization character of the file layout became more apparent. Walking through trial-and-error I put together a raw parser that attempts to make a better sense of the data records.

The tool stores the hexadecimal dumps of the interpreted data in .met files that are now accompanying all decrypted out files for both submission.idx and actual submission files. You will find errors in some of the output files, but atm it’s the best it can do. Work in progress 🙂

The output is tagged using  ‘###’ f.ex.:

### GUID
      21 A3 05 3F B7 43 78 45 93 C8 CD C5 F6 4A 14 9A  !..?.CxE.....J..
09
      22 00 00 00                                      "...

06
      01 00 00 00                                      ....

06
      01 00 00 00                                      ....

07
      13 00 00 00                                      ....

      4D 72 43 6C 65 61 6E 20 53 75 62 6D 69 73 73 69  MrClean Submissi
      6F 6E 00                                         on.

### STRING-A
      MrClean Submission

The following identifiers are now being used:

  • STRING-A – String ANSI
  • STRING-W – String Wide (Unicode-16LE)
  • BLOB – binary blob
  • GUID – 16 bytes long GUID-like data

The latest version of DeXRAY can be found here.