You are browsing the archive for LOLBins.

VS2005_vcredist_x86.exe as a LOLBIN

May 22, 2019 in Living off the land, LOLBins

This is a completely random find. I was installing this old package on a test system, and out of habit checked if it takes any command line arguments. It actually does:

This is too good to be true. Guess what happens when you run:

VS2005_vcredist_x86.exe /q /c:c:\windows\system32\calc.exe

btw. it doesn’t work for newer ones:

  • VS2008_vcredist_x86.exe
  • VS2010_vcredist_x86.exe
  • VS2013_vcredist_x86.exe

There may be some possibilities for VS2010_vcredist_x86.exe as it takes a lot of different command line arguments:

To be precise, these options are actually taken by setup.exe after the VS2010_vcredist_x86.exe unpacks files to c:\<random hex> folder.

Just a quick code review of various versions of redistributable installers immediately highlights plenty of ideas for sideloading as well e.g. signed install.exe from VS2008_vcredist_x86.exe loads one of the language-specific resource DLLs placed in the same directory via LoadLibrary, hence they can be swapped with a payload DLL:

  • install.res.1028.dll
  • install.res.1031.dll
  • install.res.1033.dll
  • install.res.1036.dll
  • install.res.1040.dll
  • install.res.1041.dll
  • install.res.1042.dll
  • install.res.2052.dll
  • install.res.3082.dll

And last update: it turns out that VS2005_vcredist_x86.exe was packaged with IExpress Setup, so any installer from that era created with iexpress.exe should have a lolbin functionality.

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.