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…