Category Archives: Living off the land

Old HotFix files + SFX CAB + DFIR artifacts

Posted on by

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.

Poisoning MUI files

Posted on by

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.