Leaving No Safe Haven For Commandline Obfuscation (Part One)

-

The only thing I find more fascinating than digital anti-forensics, obfuscation and defence evasion is coming up with ways to thwart those techniques as they are employed by adversaries in the wild. This will be a few posts about ways to detect Windows command line obfuscation using Splunk, but I'm sure that the SPL I'm going to include here could be adapted to create detections for other SIEM tools like elastic or Sentinel with relative ease.

Think of this as a chance to look up a magician's sleeve for a little peek at the concealed dove.

If you are following along with ATT&CK I think this technique is best mapped to T1027, Obfuscated Files or Information.

One of the most basic command line obfuscation techniques I've seen in the wild is paired double quotes insertion. Take this for instance:


You can place pairs of arbitrarily positioned double quotes in your command line and as long as the number of quotes per command line is an even number and there are no more than two subsequent quotes, programs will generally accept this input without blinking.

If you had a SIEM alert that related to usage of "whoami" and it was based on that string appearing in the command line, you would miss that usage based on the obfuscation shown above.

If we want to look for quotes in Splunk we need to escape them, the SPL below gives us a quote count:

index=* sourcetype="wineventlog:security" EventCode=4688
| eval quoteCount=mvcount(split(Process_Command_Line,"\""))-1
| stats count by Account_Name, host, Process_Command_Line, quoteCount
| sort - quoteCount

Obviously set the index to wherever you are keeping your Windows logs and hopefully you are logging Process_Command_Line with EventID 4688, right?

The only way I might improve this SPL is to add a where clause, looking for a quoteCount greater than 2 for instance, which would help exclude relatively "normal" double quote usage such as around file paths or file names.

Your mileage will vary here, this might be better suited to threat hunting as opposed to an alert depending on your environment and what is and isn't benign behaviour in your world.

Next blog entry we will go a little deeper into other methods of Windows cli obfuscation and how we can detect it within Splunk.

Popular posts from this blog

Fastening the Seatbelt on.. Threat Hunting for Seatbelt

-
Image
  Quick blog entry on detections for the Ghostpack discovery/reconnaissance tool Seatbelt . This entry will focus on looking at command line parameters that can be caught even if the executable itself is renamed, if I have time we can delve into other event log artefacts another time. From the Seatbelt github repo: Seatbelt is a C# project that performs a number of security oriented host-survey "safety checks" relevant from both offensive and defensive security perspectives. So essentially what the tool does is retrieve local system information that might have security or safety implications. In terms of commands that can be tacked on to Seatbelt there are a literal ton of options. But what we are going to focus on here are the command groups, which break the many, many available commands down into categories, so we have: All, User, System, Slack, Chromium, Remote, Misc. The groups above are invoked like this, if you wanted to run all checks: Seatbelt.exe -group=all And so
read more »

Capturing Pcap driver installations

-
Image
Today we're looking at Network Sniffing , ATT&CK technique T1040. This is very much a signature based rule but if you are ingesting WinEventlog:Security (and of course you are, right?) and specifically EventCode 4697 ("A service was installed in the system") then you can take the barebones splunk SPL from below and make it work for you. So how are we going to detect network sniffing on Windows endpoints? The installation of the drivers for the various Pcap variants. index=win10 sourcetype="wineventlog:security" EventCode=4697 AND Service_File_Name IN ("*pcap*", "*npcap*", "*npf*", "*nm3*", "*ndiscap*", "*nmnt*", "*windivert*", "*USBPcap*", "*pktmon*") | table _time Account_Name Computer_Name Originating_Computer Service_Name Service_File_Name   The Service_File_Name list is derived from looking at the names of .sys files associated with the most popular packet capture o
read more »

Microsoft Defender, Find User Ignored Threats With Splunk

-
Image
  Today we're looking at "vanilla" Microsoft Defender and some SPL to find "severe" or "high" categories of detected threat severity that have subsequently been "ignored" by a user. EventID 1117 gives us our detection, categorization and severity of the threat found and EventID 5007 gives us a log of user changes made, including ignored threats. EventID 5007 logs changes enacted by users to how threats are handled with a field called "New_value", it will look something like this: New value: HKLM\SOFTWARE\Microsoft\Windows Defender\Threats\ThreatIDDefaultAction\2147742972 = 0x6 It is a registry value, the string of numbers at the end is the same ID assigned recorded in EventID 1117, the "0x6" at the end signifies that this is an ignored threat. A little bit of regex retrieves our 5007 newly created "ThreatID" field and we can then compare this to our 1117 ID value to see if they match. We achieve this without reco
read more »