Find Unusually Long CLI Commands

Description

Oftentimes we're able to detect malware by looking for unusually long command line strings.


Use Case

Advanced Threat Detection, Security Monitoring

Category

Endpoint Compromise

Security Impact

To avoid detection by file integrity monitoring solutions or similar, malware will often execute code 'in memory' and never write the code to disk. But if you're watching process executions in some detail via windows process command line auditing or via Sysmon or similar, you can often pick up anomalous behavior such as statistically significant command line execution lengths. The example given here shows a command interpreter executing a large amount of .vbs code to download a ransomware encryption binary.

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Execution

MITRE ATT&CK Techniques

Command-Line Interface

MITRE Threat Groups

APT1
APT18
APT28
APT3
APT32
APT37
APT38
APT41
BRONZE BUTLER
Cobalt Group
Dragonfly 2.0
FIN7
FIN8
Gorgon Group
Honeybee
Ke3chang
Lazarus Group
Leviathan
Magic Hound
MuddyWater
OilRig
Patchwork
Rancor
Silence
Soft Cell
Sowbug
Suckfly
Threat Group-1314
Threat Group-3390
Turla
admin@338
menuPass

Kill Chain Phases

Installation
Exploitation
Actions on Objectives

Data Sources

Endpoint Detection and Response

   How to Implement

Implementing this search is similar to any of the other searches that require EDR data. In order to use it, we need to get process launch events, and know the full command line string (so the file path, process name, and the command line arguments). For the demo and live version of this search we use Microsoft Sysmon with the CommandLine field, but you could adjust that to another data source and change the field name (it is not a CIM field).

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect a spike in the length of the CLI commands, but that doesn't mean you really want to put it in front of an analyst. So while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

You should not review these alerts directly (except for access to extremely sensitive system), but instead use them for context, or to aggregate risk (as mentioned under How To Respond).

   How To Respond

When this search returns values, initiate your incident response process and determine the user account that is generating the alert. Contact the user and system owner to determine if it is authorized, and document if it is authorized and by whom. If not, the user credentials may have been used by another party and additional investigation is warranted as excessively long command lines commands could house malicious scripts.

   Help

Find Unusually Long CLI Commands Help

This example leverages the Simple Search assistant. Our dataset is a collection of Sysmon process launch logs (EventCode 1). The search then looks for unusually long command line strings, and surfaces those.

SPL for Find Unusually Long CLI Commands

Demo Data

First we pull in our demo dataset. This could be any EDR data source that provides the full CLI string.
Next we use eval to calculate how long the command line (file path + command line args) is.
Eventstats is like stats, but just adds the results to your existing dataset. So this will give us the avg and stdev per each host.
Finally we use stats to roll up multiple process launches, giving us the length of that cli string alongside the avg and stdev of the host, per host, per cli string.
With that setup, we can find processes that have substantially longer cli strings (4 * the standard deviation) than the average on this system.

Live Data

First we pull in our basic dataset, which consists of XML format Sysmon logs from the endpoints (ingested via the Sysmon TA). This could be any EDR data source that provides the full CLI string. Because we're looking for process launches, we then filter for EventCode=1 (the Sysmon Process Launch code).
Eventstats is like stats, but just adds the results to your existing dataset. So this will give us the avg and stdev of the command line length per host.
Finally we use stats to roll up multiple process launches, giving us the length of that cli string alongside the avg and stdev of the host, per host, per cli string.
With that setup, we can find processes that have substantially longer cli strings (4 * the standard deviation) than the average on this system.