I asked myself what tangible artifacts present on a file system can immediately tell us that the server system in place is a Domain Controller and/or DNS server.
I decided to run a simple experiment.
I installed a test version of Windows Server 2022, took a snapshot of the file system, then added DC and DNS capabilities, then took a snapshot of a file system again.
The (slightly edited) diff of these 2 can be found here.
This old series is not very exciting. Decompiling goodware installation scripts will never lead us to newsworthy discoveries – feel free to stop reading now.
Many installers copy files, add/change registry keys and values, install services, drivers, and do all that while their GUIs sometimes tell us what is happening, and occasionally ask us to guide them. Superboring stuff.
If you are still reading…
Recently, I noticed that some of the aforementioned ‘add/change registry keys and values’ activities affect the Process Environment block. The most popular modification is (obviously) focused on the PATH environment variable – installers just love adding new directories to it!
BUT
There is more.
The below is a list (not exhaustive) of other environment variables that are being added by installers:
While some of them seem to be quite unimportant, a lot of them seem to be asking for some … abuse (aka research) ?
I mean… anything that includes ‘PATH’ or ‘HOME’ in their name needs an appropriate research-driven follow-up.
Why?
All of them are under HKCU, so anyone can modify them. Secondly, these environment variables may open new ways to abuse legitimate, often signed binaries to do something they never intended to do – and as such, create new lolbin opportunities. It could be loading plug-ins from a malicious location, it could be executing framework binaries from a controlled location, there is definitely a scope for research here.