Category Archives: Forensic Analysis

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.

PE Compilation Timestamps vs. forensics

Posted on by

If you use PE Viewers, Editors, Dumpers for forensic purposes, you are most likely using them to extract a compilation timestamp from a binary – to determine when a specific file was compiled.

There is a little ‘gotcha’ here.

Some of these tools show the timestamps as UTC, some localize them to your timezone. This is far from ideal. Without being sure, you may be writing down incorrect information in your report.

We can fix it.

If you don’t know the algorithm your tool of choice is using to display the time you can quickly test it.

How?

As per the PE documentation, the Compilation timestamp is:

Date and time stamp value. The value is represented in the number of seconds that have elapsed since midnight (00:00:00), January 1, 1970, Universal Coordinated Time, according to the system clock. The time stamp can be printed by using the C runtime (CRT) time function.’

So, there is no better way to test your fav. programs other than using atest executable with a timestamp set to 0, and observe the results (make sure you change your timezone to a different one from UTC!).

If the result is 1970-01-01 00:00:00 then your tool is using UTC. If it is different, then it’s a local time, and perhaps in some cases, it may be wrong (better test with two different tools). As such, you may even see compilation year 1969!

Quick test shows that:

  • Die, IDA, Efd, PE Studio – use local time

and

  • PE Bear, PPEE, VirusTotal – use UTC

After I published this post, Brian provided additional comment (thx!):

I would also take note of daylight saving time. Offset of UTC changes from your local time zone.


And here is the test .exe I used, in case you need it.