Process trees in Livehunt: YARA rules that know who launched what

Note: YARA-X v1.21.0 adds a parent_name field to the items in vt.behaviour.processes_list, and v1.22.0 adds ancestor_names. VirusTotal now fills that list for every sandbox report that includes a process tree, by flattening it. The result is one entry per process, and each entry knows the name of the process that created it and of the processes above it. Read the YARA-X blog.

If you have written Livehunt rules on top of sandbox behavior, you have probably used vt.behaviour.processes_created. It is a flat list of command lines. It tells you that mshta.exe ran and that powershell.exe ran, but not that one started the other. For a lot of detections that is the whole point: PowerShell on its own is noise, PowerShell launched by mshta.exe is not.

Our sandboxes have always recorded the full process tree. The problem was getting it into YARA, which has no recursive types. As of this month, every file with sandbox reports that reaches Livehunt carries vt.behaviour.processes_list: one entry per process, from every sandbox that ran the file, and each entry knows the name of its parent, the names of its ancestors, and the files it touched.

This post covers what is in each entry, what to keep in mind when writing rules against it, and five cases we worked through while preparing it, each with the rules we wrote and tested. Every case comes with at least one hash, so you can paste the rule in the Livehunt editor and test it yourself.

If you haven't read it yet, we recommend our earlier post It's all about the structure! Creating YARA rules by clicking. It shows how to open the Structure view of any file in the Livehunt editor and turn fields into rule conditions with a click, which is handy for everything that follows.

What each process entry carries

Field
Type
What it holds

name
string
The process, as the sandbox reports it. Usually the image path plus the command line.

parent_name
string
The name of the process that created this one. Empty for root processes and when the parent is unknown.

ancestor_names
array of strings
The names of its ancestors, nearest first: ancestor_names[0] is the parent (the same as parent_name), ancestor_names[1] the grandparent, and so on. Empty for root processes and when the parent is unknown.

process_id / parent_process_id
string
PIDs, as reported by the sandbox.

start_time / termination_time
integer
When the process started and ended, if known.

files_written
array of strings
Files this process created or modified.

files_opened
array of strings
Files this process opened.

files_deleted
array of strings
Files this process deleted.

files_copied[x].source / .destination
string
Files this process copied, when the sandbox attributes copies to a process.

The fields that change how you write rules are parent_name, ancestor_names and the per-process file lists. With them, "PowerShell wrote a .dll" becomes "the PowerShell that cmd.exe started wrote a .dll".

The simplest possible rule looks like this:

import "vt"

rule cmd_spawns_schtasks_create {
  condition:
    for any p in vt.behaviour.processes_list : (
      p.name icontains "schtasks" and
      p.name icontains "/create" and
      p.parent_name icontains "cmd.exe"
    )
}

Things to know before you write rules

Names are not normalized. Each sandbox writes process names its own way. CAPE gives the quoted command line, Zenbox prepends the image path to the command line, Tencent HABO gives only the executable name, and C2AE and Microsoft Sysinternals often leave environment variables unexpanded (%ComSpec% /c ...). Use icontains and match on the executable name, not on a full path with == or startswith.

Link processes by name, not by PID. A file is usually run by several sandboxes, and Livehunt puts all their processes in the same list. PID 1040 can be cmd.exe in one report and explorer.exe in another. To go more than one level up, use ancestor_names: it is built from each sandbox report on its own, so a chain never mixes processes from different sandboxes. For long chains, you can also climb by name: look for the entry whose name is equal to the parent_name you already have. Both strings come from the same sandbox report, so an exact == is safe there.

A practical workflow is to search first and write the rule second. Intelligence search already supports behavior_processes:"<command line>", which matches anywhere in the list with no hierarchy. It is a quick way to collect candidates. Then you write the rule with the parent condition, and test it against those hashes in the Livehunt editor.

Case 1: porting a Sigma rule, and what it misses

Sigma's Suspicious MSHTA Child Process (03cc0c25-389f-4bf8-b48d-11878079f1ca) is a good

Read the original article:

Process trees in Livehunt: YARA rules that know who launched what