Execution and initial access: every way code gets…

This is the first of six posts that walk through a library of roughly 450 endpoint behaviour rules. Execution is the largest functional group: about 80 rules for the moment code starts running, plus 13 for initial access (web servers, droppers and exploit delivery). I grouped the rules by the mechanism they watch, because most of them are variations on a few ideas.

The library as a whole breaks down like this, which tells you where the effort goes.

category              rules   covered in
Evasion                  88   post 3
Execution                81   this post
Persistence              62   post 2
Reconnaissance           52   post 5
Credential Access        44   post 4
Tampering                37   post 3
Collection               27   post 5
Privilege Escalation     18   post 2
Exfiltration             13   post 5
Lateral Movement         10   post 4
Infiltration              7   this post
Dropper                   6   this post
File type obfuscation     6   post 3
File privilege            3   post 2
Unix, macOS and tools     -   post 6

Severity is a pyramid: 286 informational, 48 low, 94 medium and 24 high. Execution rules are mostly informational or medium, because the same programs are used by administrators every day. Their strength is in relationships: who started whom, with which arguments, from which folder.

1. Office and document programs that start other programs

A document application has almost no legitimate reason to run a shell. This is the most productive family in the library, with a rule for each way a macro or exploit leaves its mark.

spawns a commonly abused process          cmd, powershell, wscript, mshta, regsvr32, ...
spawns the console host (conhost.exe)     hidden console window made by a macro        HIGH
spawns an unsigned process                downloaded payload being launched
spawns a process with suspicious args     encoded or long command lines
spawns verclsid.exe                       shell extension verifier used as a proxy
Equation Editor spawns a bad process      CVE-2017-11882 style exploit
starts a compiler (csc.exe)               .NET payload compiled on the fly
loads the PowerShell engine DLL           PowerShell run inside Office without powershell.exe
injects code into another process         macro injecting shellcode
writes an executable to disk              dropper behaviour
creates an unusual .LNK file              shortcut staged for a later step
document embeds a .LNK file               shortcut hidden inside the document
runs an unsigned file from a strange path user profile, temp, public folders

Why these matter: macros and exploits run inside the Office process, and sooner or later they have to start something else. The console-host rule is rated high because a normal user never causes Office to create a hidden console. The compiler rule catches a clever trick in which a macro writes C# source and compiles it locally, avoiding a file download.

False positives come from add-ins, mail-merge tools and document converters. Scope any exclusion by signer and path, not by the parent name.

2. Script hosts

Windows ships several script engines, and attackers use them because they are signed and always present.

wscript and cscript: any execution is informational, but combinations matter: launched with script arguments from the command line, running with SYSTEM rights, connecting to an external address, or starting from a temporary folder.
VBScript: executed from the command line, and a separate, high-severity rule for encoded VBScript (the script encoder is almost never used legitimately).
mshta and HTA files: mshta started directly from a browser, and a browser downloading an .hta or .application file. Both are classic phishing mechanics.
ActiveX shell calls: a script creating a COM object to run a shell command.
AutoIT: commonly abused compiled automation scripts, plus network connections from them.
Perl and Python scripts connecting to the network: rated medium, since a language runtime making a raw connection from an unexpected location often means a reverse shell.
Scripting engines creating executables (the rule is disabled by default because it is so noisy).

3. PowerShell

PowerShell has the most detections of any single program because it is both powerful and ubiquitous.

reverse shell one-liners          (two rules, medium) socket + stream objects
reverse shell using a scripting engine
Execution hunt: Architecture transition from 64-bit to 32-bit PowerShell   typical stager behaviour
Execution hunt: Unrelated program receives PowerShell-style flags   renamed copy
a non-PowerShell process loading the PowerShell DLL            unmanaged hosting
PowerShell trying to start as administrator
PowerShell connecting to the internet
PowerShell with a download in its command line
PowerShell run through the App-V publishing server  (see section 4)

Interpreting them: the 64-to-32-bit hop is how many frameworks switch architecture before injecting shellcode. A PowerShell DLL loaded into a process that is not PowerShell means someone is hosting the engine inside another program to avoid the normal command-line logging.

4. Signed Windows programs used as launchers

These are the living-off-the-land binaries. The rules rarely care that the program ran; they care about how.

rundll32     running JavaScript | loading a known abused DLL | spawning a bad child
regsvr32     registration activity involving a remote scriptlet or payload
msbuild      started by an unusual parent | a .NET process loading its framework DLL
odbcconf     used to register a DLL
control.exe  loading a suspicious DLL
mshta        launched from a browser
pubprn.vbs   signed-script proxy execution                     HIGH
cmstp        connection manager profile installer running a command line
regsvcs / regasm   from an uncommon path
syncappvpublishingserver   PowerShell launched through the App-V publishing component
scripted diagnostics host  spawning a commonly abused process (two rules)
compiled help (CHM)  writing a script file, and making network connections
screensaver (.scr)   executed from the users or temp folder
werfault     the ReflectDebugger registry value being set

The trick behind each: the Windows component is signed, so allow-lists trust it, but its configuration or arguments let an attacker run their own code. Detection therefore keys on the arguments (a URL on the regsvr32 line, a script-block on rundll32), the parent (a browser launching mshta) or the path (a help file or screensaver from a download folder).

5. WMI, PsExec and service-based execution

Remote WMI: the wmiexec pattern (a remote command through WMI that writes output to a share), WMI starting cmd.exe with output redirection, and WMI used to terminate a process (sometimes a security tool).
PsExec: the registry value showing the EULA was accepted, a command line carrying plain-text credentials, and the service binary (psexesvc) executing a command on behalf of a remote host.
Tasks and services: a commonly abused process running as a scheduled task, a commonly abused process launched as a system service, and a scheduled task whose action references an HTTP or FTP address.
Other: the Gost tunnelling tool, the Rubeus Kerberos toolkit (high), process injection by a LOLBAS binary, an unsigned process injecting code, and a crash dump file written to disk, which is informational but often follows credential-theft attempts.

6. Exploit-specific rules

The library includes rules written for single vulnerabilities. Two custom rules were added in September 2021 for CVE-2021-40444, the browser-rendering flaw delivered through Office documents. The exploit's last visible step launched a control-panel applet through control.exe or rundll32, so the rules key on those launches pointing at .inf or .cpl files. One fired hundreds of times during testing, which is exactly what you want while validating a rule. The Equation Editor rule (CVE-2017-11882) follows the same idea: Equation Editor must never spawn another process.

7. Initial access: web servers and droppers

These 13 rules cover what happens right after delivery.

web server starts an unsigned process
web server starts a commonly abused process        (two rules)
web server drops an executable on disk
mail server process writes .aspx files             HIGH   (web shell planting on Exchange)
tool pack from a known attacker toolkit executed
Initial-access hunt: Excel query artifact saved locally

Adobe Reader starts a browser
Adobe Acrobat Reader drops an executable
Outlook creates an executable file
lsass.exe creates an executable                    (something is very wrong)
PowerShell running with a download in the command line

A web server's worker process should serve pages. When it starts cmd, whoami or an unsigned binary, the usual explanation is a web shell or an exploited application. The mail-server rule rated high is one of the best detections for Exchange compromise because it fires at the moment the shell is written.

Using this group well

Treat parent-child rules as the backbone and arguments as the filter.
Make a short, explicit list of programs that must never write executables, and alert on every exception.
Pair informational script-host rules with a risk score, so one event is context and three are an alert.
Test each rule quarterly by replaying a harmless version of the trick (for example Office starting calc.exe).

Execution and initial access: every way code gets started