You are browsing the archive for Malware 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:


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:

description = description in English
description<lngcode> = description in the language identified by <lngcode>

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.

Poisoning MUI files

April 27, 2019 in Code Injection, Living off the land, LOLBins, Malware Analysis, Random ideas

In one of my older posts about persistence tricks I described a mechanism relying on a modification of MUI files. The idea was that if you could change a string inside a MUI file – a string so specific that is actually directly passed to one of the program executing functions (e.g. ShellExecute) during program run-time – you could achieve some sort of persistence. The idea is kinda OK, but the real world renders it completely useless. It’s just really hard to find programs that match the criteria…

There is one more interesting bit you can do with MUI files tho.

If you copy Notepad.exe and its associated En-Us\notepad.exe.mui file to a different directory, you now have an environment where you can launch a signed OS binary with its MUI file under your control. The MUI file is signed too, but this fact doesn’t seem to be checked during the program execution. So, we can play around with it.

My first test was a simple change to the way Notepad shows ‘working’ file name in its title. The original resource string:

  • %1 – Notepad

refers to a placeholder ‘%1’ (file name), followed by a hyphen, and then comes the ‘Notepad’ string. We are of course very familiar with this template being rendered into something like this:

When you open a file, or Save content of your Notepad window that ‘Untitled’ part in the title will be replaced by an actual file name.

Coming back to the resource strings – as mentioned earlier, the ‘%1’ refers to an argument that is replaced by a ‘working’ file name by program during its run-time. Could we add more arguments?

To test it, I changed that template string into:

  • %1 %2 %3 – Notepad

– assuming that program will fetch additional arguments from its stack while it renders the title of the main window. This indeed occurs and when I relaunched Notepad I immediately got this ‘corrupted’ title window:

A-ha. This is a good sign. We now know that can modify the MUI file and cause Notepad to misbehave.

This finding opens doors to a possible more systematic research on a controlled modification of MUI strings to force programs to behave erratically, or crash, at least. And who knows, maybe in some instances also to controlled code execution, or signed OS binary acting as a lolbin.

The latter is actually not that far from our reach. If you can find a signed program that fetches URL directly from MUI file and either opens it directly via an API, or places it on its UI so that it can be clicked you can easily swap that URL with a link to a local ‘badguy’ file (e.g. ‘file://c:/test/badguy.exe’). Launching the program, and/or clicking the link will ‘lolbinexecute’ the badguy.exe. The interaction is required, but the proxied execution via a signed OS binary is achieved.

A quick query over the default Windows install highlights some candidates (.exe.mui files with references to ‘http’ strings), but I couldn’t find any that would be easy to use as a demo. Oh well.. Maybe the technique is not that interesting after all ?


There is one more thing we can do with it. Since we know that we can insert anything we want into a MUI file, what about we smuggle in some payload into a memory space of a signed .exe? The signed .exe will have this payload embedded and present in memory immediately after launch. No need for WriteProcessMemory.

To test the idea I added an EICAR file to my test Notepad MUI file. After launching the .exe and searching for EICAR string in memory I was able to pinpoint it like this:

The memory seems to be PAGE_WRITECOPY protected so it may pose a problem, but at least the data is already there.

There may be other ideas here that I missed.