Category Archives: Compromise Detection

When you are a temp your days are often numbered. So are your file names. Part 1

Posted on by

Many application create temp files. In the past it was completely random and various directories were chosen depending on application developer’s whim, nowadays the file names are often somehow predictable (as long as the app is legitimate, that is) and both placed inside the %TEMP% folder and named using a pattern that contains a unique prefix followed by a digit, or a number. We can quite often encounter them during forensic investigations. And if you are wondering how these temp. files are created – the applications that know how to behave typically use a Windows API called GetTempFileName; it allows programmers to specify a prefix used by temporary files used by their application. Programmers often specify prefix longer than 3 characters, but the API is using only the first 3 characters as explained in the API description on MSDN:

lpPrefixString [in]

The null-terminated prefix string. The function uses up to the first three characters of this string as the prefix of the file name. This string must consist of characters in the OEM-defined character set.

It may be handy to get familiar with a few well-known temporary file names and prefixes as it may allow us to recognize specific temporary file names families, and potentially use this knowledge to reduce data for analysis (of course, don’t do it blindly).

The list below contains popular temp. file names / prefixes – I am also including other well-known temporary file names:

  • C:\~GLC1034.TMP – side-effect of running Wise Installer; stage 2
  • %TEMP%\<digits>.tmp – typically caused by GetTempFileName API called with an empty prefix (or, file is created ‘manually’)
  • %TEMP%\7zS<digits>.tmp – side-effect of running Self-Extracting installer based on 7z
  • %TEMP%\~DF<hexdigits>.tmp – side-effect of running a Visual Basic Application; described in my older post
  • %TEMP%\~dfs<digits>.tmp – dropped by Adware.DomaIQ
  • %TEMP%\GLB<digits>.tmp – side-effect of running Wise Installer; stage 1 – this is a stub dropping DLL performing the installation (WISE*.dll)
  • %TEMP%\GLC<digits>.tmp – side-effect of running Wise Installer; this is the WISE*.dll – a DLL performing the installation
  • %TEMP%\GLD<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GLF<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GLG<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GLI<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GLJ<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GLK<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GLL<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GLM<digits>.tmp – side-effect of running Wise Installer; stage 3
  • %TEMP%\GL<other letter><digits>.tmp – possible side-effect of running Wise Installer; stage 3
  • %TEMP%\IXP<digits>.TMP – directory created by old-school installers developed using IEXPRESS
  • %TEMP%\nsi<digits>.tmp – side-effect of running Nullsoft Installer
  • %TEMP%\nst<digits>.tmp – side-effect of running very old Nullsoft Installer; it uses a hardcoded ‘nst’ as a prefix
  • %TEMP%\ns<other letter><digits>.tmp – side-effect of running older Nullsoft Installer; it uses a random letter following the prefix ‘ns’
  • %TEMP%\scs<digits>.tmp – side effect of running ntvdm.exe on Windows XP; usually two temporary files containing the same content as autoexec.nt and config.nt
  • %TEMP%\sfx<digits>.tmp – side-effect of running GkWare Installer
  • %TEMP%\stp<digits>.tmp – side-effect of running Wise Installer; stage 1
  • %TEMP%\sxe<digits>.tmp – self-extracting executable, a custom installer often used by malware (I am not sure who developed it, it could be some old legitimate installer, or even Windows) – it is dropping a compressed clean DLL (SZDD at the top of the file – usually sxe1.tmp), the DLL is decompressed (usually sxe2.tmp) and reveals itself to be just a decompression library (only one exported function DllInflate), and finally sxe3.tmp is the payload

I am still crunching some data, so there will be part 2.

Beyond good ol’ Run key, Part 21

Posted on by

MFC localization DLLs are similar in nature to Visual Basic ones (I talked about them in my last post).

The MFC framework went through many versions over the years, but the localization piece is still there and for many years it was initialized incorrectly by loading the resource DLLs as actual code (using LoadLibrary API). It eventually got fixed in the mfc110.dll (now it is using LoadLibraryEx API and forces to load the resource DLLs as data only), so while the new versions are secure the older versions can be potentially leveraged as a persistence mechanism.

As mentioned, there are many versions of MFC DLLs (refer to wiki link I provided in the first sentence of this post) so let’s walk through them one by one.

  • mfc40.dll
    • Loads MFC40LOC.dll
  • mfc42.dll
    • Loads MFC42LOC.dll
  • mfc70.dll
    • Loads MFC70<LNG>.dll & MFC70LOC.dll
  • mfc71.dll
    • Loads MFC71<LNG>.dll & MFC71LOC.dll
  • mfc80.dll
    • Loads MFC80<LNG>.dll & MFC80LOC.dll
  • mfc90.dll
    • Loads MFC90<LNG>.dll & MFC90LOC.dll
  • mfc100.dll
    • Loads MFC100<LNG>.dll & MFC100LOC.dll
    • Uses LoadLibraryEx, yet still loads the resource DLLs as code
    • Note: often accompanied by existing resource files for major languages: mfc100chs.dll, mfc100cht.dll, mfc100deu.dll, mfc100enu.dll, mfc100esn.dll, mfc100fra.dll, mfc100ita.dll, mfc100jpn.dll, mfc100kor.dll, mfc100rus.dll
  • mfc110.dll
    • Loads MFC110<LNG>.dll & MFC110LOC.dll
    • Note: often accompanied by existing resource files for major languages: mfc110chs.dll, mfc110cht.dll, mfc110deu.dll, mfc110enu.dll, mfc110esn.dll, mfc110fra.dll, mfc110ita.dll, mfc110jpn.dll, mfc110kor.dll, mfc110rus.dll
    • Note: This is the first version of MFC library that loads the resource DLL in a proper, secure way, via LoadLibraryEx using a LOAD_LIBRARY_AS_DATAFILE flag – as such, it doesn’t execute any code (that is, the persistence mechanism described here won’t work)
  • mfc120.dll
    • Loads MFC120<LNG>.dll & MFC120LOC.dll, but also loads them as data so persistence mechanism won’t work either
    • Note: often accompanied by existing resource files for major languages: mfc120chs.dll, mfc120cht.dll, mfc120deu.dll, mfc120enu.dll, mfc120esn.dll, mfc120fra.dll, mfc120ita.dll, mfc120jpn.dll, mfc120kor.dll, mfc120rus.dll

Note #1:

  • LNG is a 3-letter language code: ENU, CHS, JPN, FRA, etc. (e.g. MFC70ENU.dll)

Note #2:

  • The newer versions (>=70) of MFC load MFCxxxLOC.dll DLLs only if the LCID is set to LOCALE_SYSTEM_DEFAULT – since the loading of localization DLLs happens in a loop (all LCIDs are enumerated until loading of a localized DLLs succeeds), one of the enumerated LCIDs is actually set to LOCALE_SYSTEM_DEFAULT on Windows XP and both MFCxxx<LNG>.dll and MFCxxxLOC.dll are loaded, but I have not encountered the situation during tests where it would be set on Windows 7 (so you won’t see loading of MFCxxxLOC.dll on win7; this requires more research)

Note #3:

  • The Unicode and Debug versions of MFC libraries are behaving in an identical way e.g. for mfc110.dll you have:
    • mfc110.dll – ANSI
    • mfc110d.dll – ANSI, Debug
    • mfc110u.dll – Unicode
    • mfc110ud.dll – Unicode, Debug

To test, you can load the mfc DLL into OllyDbg, put a breakpoint on LoadLibraryA/W (and LoadLibraryExA/W for newer versions, and A/W for Ansi or Unicode respectively) and see what happens – the below screenshot shows various versions of MFC DLL loading the localization DLLs – first five are from English OS and the last two from Russian:

mfc_loc