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.<\/p>\n\n\n\n
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. <\/p>\n\n\n\n
Why? <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
Things observed are described below.<\/p>\n\n\n\n
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.:<\/p>\n\n\n\n
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. <\/p>\n\n\n\n
(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<\/em>; This one<\/a> is about it tho). <\/p>\n\n\n\n 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…<\/p>\n\n\n\n The installer uses\/expects a number of very characteristically named environment variables which I have not seen described online before:<\/p>\n\n\n\n and, mutexes:<\/p>\n\n\n\n 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…<\/p>\n\n\n\n Other interesting DFIR artifacts are various log files created by these packages:<\/p>\n\n\n\n If you see these files on the examined system, you may now have a better way to understand where they come from.<\/p>\n\n\n\n Finally, the hotfix programs accept standard command line arguments:<\/p>\n\n\n\n – 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. <\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading