Category Archives: File Formats ZOO

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.

DeXRAY – Decrypting VBN files, Part 2

Posted on by

A few months back I posted about DeXRAY –  a generic script/file carver that tries to decrypt various Quarantine files + PE files hidden inside other files under a simple layer of a single-byte xor encryption.

Some time later, in one of my other posts I mentioned that newer VBN files used by Symantec Quarantine use a different encryption scheme; instead of using well-known xor with a 0x5A key, they now use 0xA5 key.

Turns out that I was right about it, but only partially as there is a twist to it – not only these files are encrypted, but they are also divided into chunks separated by a 5 byte ‘chunk divider’ in a form of 0xF6 0x?? 0x?? 0xFF 0xFF. So, to reconstruct the encrypted Quarantine files, one needs to decrypt them with 0xA5 first and then remove the chunk dividers.

Simple, isn’t?

I updated DeXRAY.pl to handle this (quick & dirty patch, but it should work). If you find some VBN files that don’t get decrypted at all or get corrupted after decryption, please let me know.

I bet Symantec guys added this to prevent accidental detection of Quarantine files by theirs and other AV companies’ scanners; the way I think it goes is that many AV companies use X-rays technique during scans (that is, they may find malware even if it is encrypted with a single byte xor) and they could potentially/accidentally decrypt and detect the Quarantine file during scans. That could potentially lead to some ‘funny’ results (recursive detection, etc.); introducing ‘chunk divider’ breaks the file format of the encrypted file and AV scans no longer can ‘understand’ the corrupted file structure (especially if it is an encrypted PE file).

Download a new version from here:  DeXRAY.pl