The art of Stuffing and Dressing of Application Data folder

Application data folder is a very popular destination for malware. The files are typically dropped either directly inside it, or into subdirectories that are either randomized, leverage existing OS subdirectories, or sometimes malware creates their own – often mimicking the well-known applications’ folders (f.ex. Mozilla).

The attached list contains over 7000 file names for files that are ‘dropped’ inside the application data folder. The file names are extracted from a large set of sandbox reports.

Once stuffed in the folder, the malware often dresses itself impersonating popular applications f.ex.:

chrome.exe

  • \Application Data\23405d2\Chrome.exe
  • \Application Data\4236aa7\Chrome.exe
  • \Application Data\cchrome.exe
  • \Application Data\Chrome.exe
  • \Application Data\Directory\Chrome.exe
  • \Application Data\Google\Chrome\Application\chrome.exe
  • \Application Data\GoogleChrome.exe
  • \Application Data\Orbitum\Application\chrome.exe
  • \Application Data\qChrome\chrome.exe
  • \APPLICATION DATA\SVCHOST\CHROME.EXE
  • \Application Data\temp\chrome.exe
  • \APPLIC~1\chrome.exe

firefox.exe

  • \Application Data\firefox.com
  • \Application Data\firefox.exe
  • \Application Data\firefox32.exe
  • \Application Data\firefox32\fox32.exe
  • \Application Data\Mozilla\Firefox\firefox.exe
  • \APPLIC~1\Firefox.exe

java.exe

  • \Application Data\google\java.exe
  • \Application Data\Java.exe
  • \Application Data\java\java.exe
  • \Application Data\logjava.exe
  • \application data\sys\jre\bin\java.exe
  • \application data\x10flasher_lib\jre\bin\java.exe
  • \application data\x10flasher_lib\winjre32\bin\java.exe
  • \application data\x10flasher_lib\winjre32\jre\bin\java.exe

smss.exe

  • \Application Data\CDWD\ntsmss.exe
  • \Application Data\GHGF\ntsmss.exe
  • \Application Data\ipseol32\rtcssmss.exe
  • \Application Data\Microsoft\smss.exe
  • \Application Data\Microsoft\Windows\smss.exe
  • \Application Data\secetupn\mqsvsmss.exe
  • \Application Data\smss.exe
  • \Application Data\sys\smss.exe
  • \Application Data\sysdrivers\smss.exe
  • \Application Data\syssmss.exe
  • \Application Data\System\Oracle\smss.exe
  • \Application Data\WINDOWS\SMSS.EXE
  • \Application Data\winhelp\smss.exe
  • \Application Data\zbwpukwyg\smss.exe
  • \APPLIC~1\smss.exe

and so on and so forth including some ridiculous Corporate hybrids like these:

  • \Application Data\\Application Data\Google\hkcmd.exe
  • \Application Data\google\java.exe
  • \Application Data\Google\MicrosoftSecurity64.exe
  • \Application Data\Google\svchost.exe
  • \Application Data\GOOGLE\winlogon.exe
  • \Application Data\install\csrss.exe
  • \APPLICATION DATA\INSTALL\EXPLORER.EXE
  • \APPLICATION DATA\INSTALL\IEXPLORER.EXE
  • \Application Data\Java\svchost.exe
  • \Application Data\MicOffice\MicOffice.scr
  • \Application Data\Microsoft\Adbeflashplugin.exe
  • \Application Data\Microsoft\GoogleToolbarNotifier.exe
  • \Application Data\Microsoft\Micromedia\winconime.exe
  • \Application Data\Microsoft\SystemCertificates\LeapFTP.exe
  • \Application Data\Microsoft\SystemCertificates\My\CRLs\Flashfxp.exe

or AV impersonators:

  • \Application Data\Karpesky.exe
  • \Application Data\KASPERANTIVIRUS.EXE
  • \Application Data\KasperskyAV.exe
  • \Application Data\MCAFEEANTIVIRUS.EXE
  • \Application Data\MCAFEEAV32.EXE
  • \Application Data\NOD32KERNELS.EXE
  • \Application Data\NOD64.EXE
  • \Application Data\NORMANANTIVIRUS.EXE
  • \Application Data\NortonLive.exe
  • \Application Data\SYMANTECAV.EXE
  • \Application Data\SYMANTECAV2.EXE

Since it’s a blacklist, it can be applied to hunting and file list analysis. FPs are definitely there, so you have been warned 🙂

IDAPython – making strings decompiler-friendly

Update

As pointed out by 0stracon there is an option in Hexrays that actually enables it to print all strings. Go to Hex-Rays Decompiler Analysis Options and untick ‘Print only constant string literals’.

To make it permanent, enable it in hexrays.cfg:

#define HO_CONST_STRINGS   0x0040   // Only print string literals if they reside
                                    // in read-only memory (e.g. .rodata segment).
                                    // When off, all strings are printed as literals.
                                    // You can override decompiler's decision by
                                    // adding 'const' or 'volatile' to the
                                    // string variable's type declaration
HEXOPTIONS               = 0x....   // Combination of HO_... bits

I was not aware of this option and reinvented the wheel 🙂

Old post

One of the features of IDA is its ability to recognize strings. This is a great feature, especially useful when you combine it with a power of HexRays decompiler – together they can produce a very nice pseudocode.

There is only one annoying bit there: if strings are recognized and defined inside a writable segment, they will not be presented by the decompiler as strings, but as variable names referring to strings.

Let’s have a look at the example.

In the below example (Dexter sample) IDA recognizes the string “UpdateMutex:”

strings_1When we now switch to the decompiler view, we will see that the decompiler changes it to s__Updatemutex:

strings_1a

(the ‘s__’ prefix comes from the string prefix I typically use i.e. ‘s->’ which decompiler ‘flattens’ to ‘s__’). The s__Updatemutex refers to a string as shown below i.e. “UpdateMutex:” :

strings_2Obviously, a  decompiled code that refers to the actual string is much more readable – see the same piece of code as shown above where data is referred to by actual strings:

strings_2aIn order to make the decompiler use these actual strings (not the reference) we have two options:

  • Make the segment where the string is recognized read-only (by disabling ‘Write’ in segment properties):

strings_3Unfortunately, this will confuse the decompiler and will make the output not trustworthy (it is often truncated). You will also receive a friendly reminder that you are doing something stupid 😉 a.k.a. a red card from the decompiler’s authors:

strings_3a

  • The second option is to use a ‘proper’ method of fixing the issue by telling the IDA that the string is a read-only a.k.a. constant i.e. you can change the type of the string from existing one to the one prefixed with a keyword ‘const’:

strings_4Since most of the time strings are static it is handy to convert all the strings in IDA to read-only i.e. retyping all of them using the ‘const’ trick.

This is exactly what the strings_to_const.py script is intended to do.

It enumerates all segments, finds all strings recognized by IDA (note the comment about the prefix I use, you may need to adapt it to your needs), and then converts them to read-only.

The result?

See below – before and after:

strings_before_after