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 ?

BUT

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.