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.

‘Blade Runner’ – the cult classic movie – teaches us that the (non-)human traits/behaviors can be detected with a so-called Voight-Kampff test. This post is about discussing (not designing yet) a similar test for our threat hunting purposes…

The key to Voight-Kampff test was the empathy. For threat hunting the key is the actual – and one that is beyond-any-reasonable-doubt – human-system interaction… a proof of life, if you will.

Looking at logs, we often see this…:

• Some process creating another process – no context, no decision.
• Some process connecting out – again, no context, no decision.

and then there is a lot of NOISE – Everything Everywhere All at Once.

How can we tell that what we see in telemetry was human-made, and what was not? Or the opposite – what logs are created as a result of computers doing preprogrammed things? And this is not to ignore the latter, we all know the windows’ services.exe is a busy body, and cron jobs downloading some stuff and running it via a pipe to shell ad nauseam is not the activity we want to ignore, but the focus here is on the ‘person behind the keyboard’ type of things…

Surprisingly, it’s an extremely difficult task… and imho, to be able to attribute activities to a human is of paramount importance to us threat hunters…

Why?

Scope reduction. Yup, it’s that simple. We are already tasked with hunting very small needles hidden inside very gigantic haystacks… and not just one, but many of them… so we need to cut corners here and there, and this is one of the ways…

Putting aside difficult problems like mapping browser activity (which is most of the time a human-made activity with a lot of noise), as well as Initial Access type of things (an attractive target and definitely a top target for research, but it’s kinda out-of-scope here as it is just a McGuffin to kick the ‘bad’ things off), what else is out there for us to find?

The first and easy answer is obviously a built-in set of mechanisms present in any modern OS that supports macro- or script-based automation that can be used to make your mouse jiggle, and move around in preprogrammed way, or simulate keyboard strokes as if a person was actually typing it. The second is accessibility features which are very powerful, but also a bit out-of-scope here. Let’s discard these for a moment.

We want to ‘see’ a person behind the keyboard and mouse. An active user doing things using UI, terminal, using software, producing some … I guess.. output?

One can suggest that the only way to do it right is to fully keylog & screen capture us all, but to my surprise, I heard from someone arguing back at his very idea that it would not make our job any easier! It would just add more data for us to analyze. The argument went even further – that it’s a very long journey from having all this keylogged & screen captured data in place to actually raising an alert in response to some malicious activity detected in it!

Sounds familiar? All the telemetry is like this – useless, until contextualized!

Wear shoes of a very prolific threat actor for a moment. If their campaign is very successful they end up with gazillion of logs that they simply CAN’T process w/o some automation and an arbiter system in place! I have seen repositories of infostealer logs taken from thousands of machines and I can only imagine the confusion of the TAs that face the very same problem that the blue teams do… it’s just too much data! I believe that today many TAs sit on far more than they can chew for this very reason…

Let’s get back to the original question though: how do we detect human activity?

The DFIR discipline comes to a rescue… because DFIR artifacts can lead us to some ideas…

Windows offers a lot of hints when it comes to at least partial proof-of-life and ‘human interaction’. Downloading files from the internet creates Zone.Identifier Alternate Data Streams. Opening documents creates LNK files in the Office\Recent folder. Opening any file with an editor is of interest, and can be ‘observed’. Pinning items to Start Menu or Taskbar leave traces. Files downloaded and stored inside the Downloads folder or on a Desktop are to be looked at. Anything created on a file system with a name portable in it is of interest as well. A folder called New Folder is interesting, as well as its numerous localized equivalents… Then there are media files and warez, plus some heavily biased network traffic.

And this makes me circle back to the point I made earlier:

An active user doing things using UI, terminal, using software, producing some … I guess.. output?

This is a powerful statement. Look at any ransomware, look at any infostealer. They are all actually very focused and go after all these ‘valuable’ outputs: documents, most-likely human-created files, working files, backups, as well as configuration files of many programs, and data from the browsers and browser plug-ins.

This brings us closer to the answers we want:

• Users browse the internet using browsers
  • they visit web sites
  • they install plug-ins
  • they download files
  • they open some of them
• Users send and receive emails
  • They also open attachments
• Users communicate via IM
  • They upload and download files
• Users view files
  • PDF, DOC(X), XLS(X), PPT(X), but also Google docs and sheets
• Users edit files
  • configuration files
  • marketing collateral materials
  • CAD files
  • etc.
• Users print stuff
  • To file
  • To printer – local or remote
• Users run software
  • Specialized software
  • Office software
  • Games
  • Illegal software
  • and many more
• Users sysadmin OS
  • Installing software
  • Uninstalling Software
  • Adding user accounts
  • Removing user accounts
  • Modifying user accounts
• Users use social media
• Users use cross-device accounts
• Users check their private emails at work
• Users copy and move files
• Users mount external devices
• Users copy stuff over SMB
• Users copy stuff over Airdrop
• Users download and upload files
• Users initiate remote sessions (RDP, SSH)
• Users use *aaS applications
• User run applications that crash (WER, Crashpad)
• Userss program
  • Install dependencies
  • Install modules
  • Test random code from the internet
• Users use GUI a lot
  • all the things listed above
  • plus more

Where does it leave us?

There is no simple way to prove it’s the person behind the keyboard that initiated any sequence of events…

We need a different telemetry. One that can distinguish between a human and a machine. Plus, context is everything.

Threat Hunting has a very long way to go…