‘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…