You are browsing the archive for Forensic Analysis.

Total Commander Plugins & Their Automated Installation

May 12, 2019 in Clustering, File Formats ZOO, Forensic Analysis, Malware Analysis

Total Commander (TC) and its Plug-ins are floating on the internet for a veeeery long time. As such, most of what I describe below is most likely known to many people. However, as it is with everything, it’s always good to just describe stuff from a DF/IR angle, especially to ppl who never used or came across this program itself or a very specific subset of its features.

And since this post is about TC, I must say for the millionth time that if you use Windows Explorer as your goto File Manager you are hurting yourself a lot. Once you try TC, FAR, or any type of the Orthodox File Managers, there is no way back. It’s worth every single eurocent you have to pay for it. Btw. I am not paid to endorse this software, I just love it and recommend it to anyone who wants to be more efficient.

Like many other popular programs TC supports plug-ins. There are many of these, they are often pretty cool and they add a lot of extra features to this awesome program e.g. handling of additional file types, direct access to Registry, additional archiving options, etc. Some examples can be found here. The page I linked to also includes a number of .chm files (search for a ‘guide’ keyword) that describe how to build your own plug-ins.

The topic of this post is not TC or its plug-ins coding though. At least not directly.

What I want to mention is this: the plug-ins support a mechanism that author of TC calls a ‘Plugins Automated Installation’. The idea is pretty straightforward – any common archive that TC opens/sees that has the ‘pluginst.inf’ file present inside the archive will make TC recognize the file as a possible TC Plug-in. This is actually a very handy auto-install method and I personally used it a number of times in the past.

When one opens such archive in TC, the following windows may appear:

Or

These messages come from the pluginst.inf file itself. The structure of the file is like any other standard .ini file, plus it needs these section bits to be defined:

[plugininstall]
description = description in English
description<lngcode> = description in the language identified by <lngcode>
type=<type>
file=<filename>
defaultdir=<path>
defaultextension=<extension>

The type determines what plug-in it is. The available types are: wcx, wfx, wlx or wdx or lng. Additionally the plug-ins may include files with a .mnu or .bar file extension + various misc. files that support its work.

Here’s a quick break down of what these file extensions are associated with:

  • WCX – New Archive formats.
  • WDX – New columns (properties) for items.
  • WLX – Lister plug-ins
  • WFX – New file systems (e.g. extX)
  • LNG – Language files
  • MNU + BAR + INI – Menu files

That’s it really.

While interaction is required to install these, it’s always better to be safe than sorry. For this reason, it is perhaps worth blocking these file extensions on the email gateway. I actually added them to my old post about file extensions of interest for exactly this reason.

It is also a handy way to use the presence of pluginst.inf inside the compressed files (note: doesn’t need to be .zip; 7z works too!) to properly identify archive file subtype.

Old HotFix files + SFX CAB + DFIR artifacts

May 11, 2019 in Archaeology, File Formats ZOO, Forensic Analysis, LOLBins

I don’t have much to say in this post, but since I looked at a sample file for a few minutes, it’s good to earn some brownie points by just describing what I have observed. Especially that quick google search returned nothing on the topics I want to cover here — who knows, maybe one day it will be helpful to someone… + there are some pointers for further research anyway.

The file I looked at is a very old (2003!) signed hotfix installer from Microsoft. I got curious about these, because they are very old, and signed, hence a possible target for a good LOLBIN.

Why?

These Hotfixes were coded in ancient times, the modern security assumptions and considerations were simply not there, and it’s a possible goldmine for new, interesting ideas of Bring Your Own LOLBIN or Bring Your Own Vulnerability type of scenarios.

As it is usually the case, my attention eventually got diverted and instead of looking at LOLBIN-ability of the file, I just started browsing the code and was pleasantly surprised with some quick & imho interesting DFIRCE findings. Some of these could be actually handy to me ~10 years ago.

Things observed are described below.

If you see a <drive>:\[hexdigits] folder during your exam, it is a high chance it is from a Hotfix/Update. When the SFXCAB-based Hotfix/Update is executed it just drops the installation files there f.ex.:

  • c:\[hexdigits]\$shtdwn$.req
  • c:\[hexdigits]\update\eula.txt
  • c:\[hexdigits]\portcls.sys
  • c:\[hexdigits]\update\q816650.cat
  • c:\[hexdigits]\update\spcustom.dll
  • c:\[hexdigits]\spmsg.dll
  • c:\[hexdigits]\spuninst.exe
  • c:\[hexdigits]\update\update.exe
  • c:\[hexdigits]\update\update.inf
  • c:\[hexdigits]\update\update.ver

This is not unusual, but I have seen similar folders so many times that I need to make a quick comment here. The perverted interest of many Windows HotFix/Update packages (including redistributables) to either use a temporary folder in the root directory of C:\, or any other available drive really is something I still don’t fully understand.

(I remember deleting many of these on my own systems at the time I was still updating my OS in an automated fashion. I simply don’t trust auto-updates anymore and often end up testing updates to anything let it be OS or a browser on VM before I deploy it on my main system. It’s crazy. it shouldn’t be like this. But luckily this post is not about this; This one is about it tho).

Anyway… It goes against the old Microsoft mantra of using the %TEMP% directory for this purpose – user- or SYSTEM-based, depending on the need. Oh well…

The installer uses/expects a number of very characteristically named environment variables which I have not seen described online before:

  • _SFX_CAB_SHUTDOWN_REQUEST
  • SP_UPDATE_LOG_CABBUILD
  • _HFM_EXE_PATH
  • SP_UPDATE_WARN_BEFORE_INSTALLING_FILES
  • _SFX_NoDefaultURL
  • _SFX_SourceFilesURL

and, mutexes:

  • Global\ServicePackOrHotfix

Again, I couldn’t find much info about these online, and I was not too inclined to find out what they are, but… the _SFX_SourceFilesURL is an interesting one as it adds additional source URLs for the updater/fixer to consider while it is patching the system. Who knows… maybe it is a nice LOLBIN possibility after all? Will need to play with it a bit more…

Other interesting DFIR artifacts are various log files created by these packages:

  • repair\setup.log
  • setup.log
  • svcpack.log
  • ~req~.log
  • ~rsp~.log

If you see these files on the examined system, you may now have a better way to understand where they come from.

Finally, the hotfix programs accept standard command line arguments:

  • /f Forces other programs to close at shutdown.
  • /n Does not back up files for removing hotfixes.
  • /z Does not restart the computer after the installation is completed.
  • /q Uses quiet mode; no user interaction is required.
  • /m Uses unattended Setup mode (Windows 2000).
  • /u Uses unattended Setup mode (Windows XP).
  • /l Lists installed hotfixes.

– these don’t provide much additional info, but if you see these in a context of a hotfix/update e.g. via EDR/sysmon logs, then you can at least decipher their meaning and understand what the setup program is doing.