Leaving No Safe Haven For Commandline Obfuscation (The Second Part)

-

 


In part one of these blog entries on command line obfuscation in Windows (which you can find here, if you haven't read it), we covered some real basic SPL for detecting the usage of double quotes to potentially circumvent SIEM detections.

One of the things I forgot to mention then is that counting specific characters in fields has a lot of potential uses within Splunk searches if you are prepared to think outside the box a little.

For instance let's say you were looking at Apache web logs and you were wanting to find instances of directory (or path) traversal, someone appending something like "../../../../../../../../../../../../etc/passwd%00" to a url to try to get at your valuable files, you could modify the SPL as follows:

 

index=apache sourcetype=access_combined

| eval traversalCount=mvcount(split(uri,"."))-1

| where traversalCount >=4

| stats values(uri) BY traversalCount clientip status

 

This would give you any instances of uris containing 4 or more periods, mess with the threshold attached to there where as needed. You can use that basic SPL for all kinds of tricks if you think about it.

Anyway, that's a tangent, back to command line obfuscation.

In terms of Windows command line character insertion obfuscation only certain characters work, so we can gather what these characters are and search for them. Our full list will be carets, colons, semi-colons, pipes, back and forward slashes, our aforementioned double quotes and finally the humble parentheses (opening and closing).

What you can end up with are EventID 4688 events that look something like this:

 



Now for a little SPL magic:

 

index=* sourcetype="wineventlog:security" EventCode=4688
| eval cliLength=len(Process_Command_Line)
| rex field=Process_Command_Line max_match=0 "(?<special>[\"\\\/\(\)\;\|\^])"
| eval specialCount=mvcount(special)
| where specialCount > (cliLength / 2)
| table cliLength specialCount Process_Command_Line
 

So what are we doing? We are getting the length of the command line (itself a good potential way to find the padding that character insertion causes), then counting our potential character insertions via rex and an eval and finally looking for where the count of those characters is more than half of the total actual characters in the command line.

As always feel free to alter the "where" or remove it altogether, there are a lot of potential tweaks you could make to the above SPL.

Check out Invoke-Dosfuscation on github if you want to learn more about this topic, the repo includes samples of Windows logs that you can ingest into the SIEM of your choice to test out your own potential hunts.

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 »