3 little secrets of netsh.exe

It is typical for many of us to discover ‘the cool thing’, and then quickly move on to research something else. Over the last few years my ‘little known secrets’ series exploited this phenomenon by showcasing scenarios that, admittedly, were available to many researchers before me, all of them ‘who were there first’, but… who then just stopped looking at other interesting things after they discovered, and then published about, ‘that one cool thing’.

if it sounds cryptic…

Take netsh.exe as an example.

Its Lolbas page describes only one lolbin usage that relies on the ‘netsh.exe add‘ command in which we load an arbitrary DLL into netsh.exe process.

O-kay.

A casual study of netsh.exe command line syntax offers two additional opportunities:

  • -f <scriptfile>
  • exec <scriptfile>

These commands take a script name as an input and then process the commands stored inside the <scriptfile> file. It’s super basic, but it works.

And it’s not the end.

Turns out the Alias file processing works too:

  • -a <AliasFile>

And it’s not the end either.

Just trying to add a single alias leads to a DLL loading too! (and I don’t even know if this is a proper syntax!)

And then it hits you…

You are doing all these tests on the very same system, one by one, in a context of changes you have already introduced to the system. And these changes should not be ignored!

The first test added a netsh.exe ‘plug-in’ to the Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NetSh\test=test.dll

As a result, any subsequent invocations of netsh.exe attempted to load that test.dll!

Ouch.

It’s a classic example of contamination of the evidence/sample, and once it happens (and we miss it!), everything that follows, research-wise, is all wrong!

And this is the moment when we come back to the basics, and test our hypothesis one by one, using _clean_ environment for all the tests we have ever thought of.

And then, after careful testing, we can still prove that these are still very decent LOLBIN scenarios;

  • -f <scriptfile>
  • exec <scriptfile>
  • -a <AliasFile>

And if you enter the interactive mode of netsh.exe, you can add a DLL-loading alias like this, too:

or

The lesson here is that we always need to dig a bit more, but we also need to be careful, because some of our conclusions may be convenient, but also… incorrect…

Not installing the installers, part 4

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:

  • ACE_STUDIO_PATH
  • BRAINGINES_PATH
  • CC_PIXEL_RATIO
  • DELIGHT
  • FLOW_PATH
  • FMXLINUX
  • GIT_LFS_PATH
  • GPU_AUDIO_PLUGIN_INSTALLATION_PATH
  • IDF_TOOLS_PATH
  • IFCEXPORTER
  • INTELBRAS_AMTRD_JAVA_HOME
  • JAVA_HOME
  • JETTY_WEB_HOME
  • JIOCLOUD_INSTALL_TYPE
  • LANDO_INSTALL_PATH
  • LANG
  • LANG_PSERVER
  • P3DEXPORTER
  • QT_DEVICE_PIXEL_RATIO
  • RTOOLS43_HOME
  • RTOOLS44_AARCH64_HOME
  • RTOOLS44_HOME
  • XR_RUNTIME_JSON

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.