It's probably worth a couple of minutes to mention this item: https://attack.mitre.org/techniques/T1128/
Essentially good ol' netsh can be used to load a malicious module and that it offers persistence. The tool does document this perhaps unexpected functionality in the help:
netsh add
The following commands are available:
Commands in this context:
add helper - Installs a helper DLL.
So you can "install" a helper DLL, for example:
netsh add helper C:\netsh\netshdll.dll
Ok.
Where for test purposes the DLL is just the bare-bones to launch calc.
#include <windows.h>
BOOL APIENTRY DllMain(HANDLE hModule, DWORD reason, LPVOID lpReserved){return true;}
extern "C" __declspec(dllexport) DWORD InitHelperDll(DWORD dwNetshVersion, PVOID pReserved){system("start calc");return 0;}
The referenced DLL will be invoked straight away as it is added and the InitHelperDll method of the DLL called.
Even if you don't have an InitHelperDll function in the DLL it still seems to load and function, you just get a warning message when you run netsh which would give the game away to the end-user something looked suspicious.
The function InitHelperDll was not found in C:\netsh\netsh.DLL.
The interesting and persistence part is that it creates the following registry string value based off the DLL name so the module will be loaded each time, e.g. for the command above:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NetSh]
"netshdll"="C:\\netsh\\netshdll.dll"
Of course on a 64-bit OS, there is the 32-bit netsh.exe under \windows\syswow64\, this 32-bit version uses the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\NetSh
As you might expect, these registry keys can be created directly to remove the need to run the "add helper" routine.
At face value, netsh running in your environment may not seem too much of a worry (firewall configuration changes aside) but it's worth knowing that it could be loading modules you don't expect on each invocation. This tool is typically run as local system or administrator which makes it a little more concerning,
To simply list the keys and referenced modules:
select path, data from registry where key ='HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\NetSh' or key='HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NetSh';
It is, however, tricky to automatically join on say the 'sophos_file_properties' table to get values for these entries such as mlScore, puaScore, localRep and globalRep as you need a pathname or sha256. The malicious DLLs referenced could be in the 'path' so a full path may not be specified. We could run the following query, just to identify DLLs that don't just match, by name, the built-in ones. It would certainly highlight our example DLL and start the hunt off using the sophos_file_properties table for example.
select path, data from registry where
(key = 'HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\NetSh' or key = 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NetSh')
and data not in(
'ifmon.dll',
'rasmontr.dll',
'authfwcfg.dll',
'dhcpcmonitor.dll',
'dot3cfg.dll',
'fwcfg.dll',
'hnetmon.dll',
'netiohlp.dll',
'nettrace.dll',
'nshhttp.dll',
'nshipsec.dll',
'nshwfp.dll',
'p2pnetsh.dll',
'rpcnsh.dll',
'WcnNetsh.dll',
'whhelper.dll',
'wlancfg.dll',
'wshelper.dll',
'wwancfg.dll',
'peerdistsh.dll'
);
Otherwise, we can turn to the Sophos tables "sophos_image_journal", 'sophos_process_journal' and 'sophos_file_properties' to spot DLLs that are loaded by a netsh process and get their sha256 and local, global rep.
I hope it's useful information to consider as would child process of netsh!
Regards,
Jak