Many Windows tools support commands f.ex.:

• reg.exe – QUERY, ADD, DELETE, COPY, SAVE, RESTORE, LOAD, UNLOAD, COMPARE, EXPORT, IMPORT, FLAGS
• sc.exe – config, continue, control, create, delete, description, EnumDepend, failure, failureflag, GetDisplayName, GetKeyName, interrogate, managedaccount, pause, preferrednode, privs, qc, qdescription, qfailure, qfailureflag, qmanagedaccount, qpreferrednode, qprivs, qprotection, qsidtype, qtriggerinfo, query, queryex, quserservice, sdset, sdshow, showsid, sidtype, start, stop, triggerinfo
• netsh.exe – ?, add, advfirewall, branchcache, bridge, delete, dhcpclient, dnsclient, dump, exec, firewall, help, http, interface, ipsec, lan, mbn, namespace, netio, p2p, ras, rpc, set, show, trace, wcn, wfp, winhttp, winsock, wlan
• fsutil.exe – 8dot3name, behavior, dax, dirty, file, fsInfo, hardlink, objectID, quota, repair, reparsePoint, resource, sparse, storageReserve, tiering, transaction, usn, volume, wim

We are very used to their invocations in a form of tool command but there is an alternative way to invoke them by using quotes around these commands f.ex.:

• reg.exe “query” is identical with reg.exe query
• sc.exe “start” is identical with sc start
• etc.

This breaks many hard-coded detections.

The second secret is the omnipresent support for everything ‘remote’, that is – operations that can be executed on other endpoints.

As such, one can use computer names in many of these commands, f.ex. we can prefix registry keys for reg.exe command with host names. And this includes localhost, 127.0.0.1, ::1 – yet notably, for these to work the RemoteRegistry service needs to be running on a local host. It’s actually very easy to do so:

sc config remoteregistry start= auto
sc start remoteregistry

and then we can easily run one of these:

reg save \\127.0.0.1\hklm\sam sam
reg save \\localhost\hklm\sam sam
reg save \\::1\hklm\sam sam
reg "save" \\127.0.0.1\hklm\sam sam
reg "save" \\localhost\hklm\sam sam
reg "save" \\::1\hklm\sam sam

This will break many detections too.

If you’ve been reading my blog for a while now you will know that I love to challenge my threat hunting game with a lot of err…. banalities. And not the banalities I can ignore, but a lot of these banalities that I eventually learn to embrace…

if it sounds cryptic…

You probably already know by now that things we often take for granted are not necessarily true, and today I am adding the ‘default installation path’ to that ‘fear, uncertainty, doubt’ list as well.

The reason I focus on this particular item today is because the default installation path is one of the most misunderstood, and in the end, the most profoundly misleading bits one may find in the so-called ‘aggregated lists covering this or that software of interest’, where the software group of interest can be Remote Access Tools, Proxy/VPN, etc.

Many people who build these lists are doing a phenomenal job collecting many interesting artifacts about a given software, but while doing so, they tend to forget about the architecture issues, the localization issues, versioning, and then … yes… that dreadful ‘default installation path’, too.

Believe it or not, many people actively use ‘Portable’ versions of software. And they do not install them from the PortableApps web site – the portable packages are very often offered by many savvy software houses (f.ex. 7zip, python, process hacker/system informer, sysinternals, ffmpeg, vlc, tor, ultraedit mobile, and many more). I absolutely adore these portable packages and most of my software I use everyday is of that type aka it is NOT installed in a traditional sense. I just download them, unpack them to my secret folders and… use them. I am very aware of the fact that many users do the same.

And this type of ‘Portable’ is unpredictable. Especially for Threat Hunters.

There goes your reliability on forensics artifacts that bind file names, process/image names, configuration files to a specific path, or file system location…

Plus, most installers nowadays allow users to specify their custom path that they choose as a destination folder for the software to be installed to. These custom installation instances are even worse than ‘portable’ cases as users can literally choose any random place on a hard drive… AND THEY DO!

Let’s look at an example…

If you google ‘niauth_daemon.exe’ you may find its common location to be a predictable one:

• C:\Program Files (x86)\National Instruments\Shared\niauth\niauth_daemon.exe

However…

The executable can be found present in many unpredictable locations:

• B:\NI_LABVIEW\Shared\niauth
• C:\Archivos de programa\National Instruments\Shared\niauth
• C:\Arquivos de programas\National Instruments\Shared\niauth
• C:\Logiciel_Projet\National Instruments\Shared\niauth
• C:\National Instruments\Shared\niauth
• C:\New folder\Shared\niauth
• C:\Program Files (x86)\National Instruments\2014\Shared\niauth
• C:\Program Files (x86)\National Instruments\Shared\niauth
• C:\Program Files (x86)\Shared\niauth
• C:\Program Files\National Instruments\Shared\niauth
• C:\Program Files\Shared\niauth
• C:\Program\National Instruments\Shared\niauth
• C:\Programas\National Instruments\Shared\niauth
• C:\Programme\National Instruments\Shared\niauth
• C:\Programmi\National Instruments\Shared\niauth
• C:\Programy\LabView\Shared\niauth
• D:\LabVIEW2014\Shared\niauth
• D:\LabVi\Shared\niauth
• D:\Labview runtime engine\Shared\niauth
• D:\Multisim14.0\Shared\niauth
• D:\National Instruments\Shared\niauth
• D:\Program Files (x86)\National Instruments\Shared\niauth
• D:\Program Files (x86)\Shared\niauth
• D:\Program Files\Multisim\Shared\niauth
• D:\Program Files\National Instruments\Shared\niauth
• D:\Programas\National Instruments\Shared\niauth
• D:\Programs\National Instruments\Shared\niauth
• D:\Programy\LabVIEW\Shared\niauth
• D:\Shared\niauth
• D:\Software1\Shared\niauth
• D:\Software\National Instruments\Shared\niauth
• D:\games\Shared\niauth
• D:\labview\Shared\niauth
• D:\multisim10\Shared\niauth
• D:\multisim\Shared\niauth
• D:\program file\multisim12\program\Shared\niauth
• E:\Archivos de programa\National Instruments\Shared\niauth
• E:\HOC TAP\Shared\niauth
• E:\Multisim\Shared\niauth
• E:\National Instruments Downloads\Shared\niauth
• E:\National Instruments\Shared\niauth
• E:\Nedlastinger\programfiler (x64)\National Instruments\Shared\niauth
• E:\PROGRAMMS\Electronics Workbench\EWB9\National Instruments\Shared\niauth
• E:\Program Files (x86)\National Instruments\Shared\niauth
• E:\Program Files (x86)\WB\Shared\niauth
• E:\Program Files\National Instruments\Shared\niauth
• E:\Programming\NISoftware\Shared\niauth
• E:\Shared\niauth
• E:\multisim\Shared\niauth
• F:\LabView\LAB\Shared\niauth
• F:\Mtech IN\LabView\New folder\Shared\niauth
• F:\NI LAB 2014\Shared\niauth
• F:\NI\Shared\niauth
• F:\National Instruments\Shared\niauth
• F:\Prog\NI\Shared\niauth
• F:\Program Files (x86)\National Instruments\Shared\niauth
• F:\Program Files\National Instruments\Shared\niauth
• F:\Programy\NI\Shared\niauth
• F:\installedprogams\drims\Shared\niauth
• F:\multi sim\Shared\niauth
• G:\Program Files (x86)\National Instruments\Shared\niauth
• G:\prog files\installed programs\National Instruments\Shared\niauth
• H:\Program Files (x86)\National Instruments\Shared\niauth
• I:\Program Files (x86)\National Instruments\Shared\niauth
• S:\Program Files\National Instruments\Shared\niauth
• T:\Program Files (x86)\National Instruments\Shared\niauth
• Z:\Program Files (x86)\National Instruments\Shared\niauth
• d:\Program Files (x86)\National Instruments\Shared\niauth

… and it’s just a tip of an iceberg…

We do want to believe that the Threat Hunting is built on some sort of discipline… We see something going on, we codify it, and we pat ourselves on a back. The devil is in the details though and that very same devil loves the error of availability…

Let’s take a note then, shall we? Full directories/folders should NOT be included in many Threat Hunt searches that focus on presence of specific file/process/image names in specific locations. As of today, that custom install location is yet another known unknown.