Advanced Powershell Hunting with the Splunk Decrypt App


If you already have powershell event logs in Splunk and want to decode the base64, this may help.

This tutorial builds on the work of others with some new cleverness to provide an efficient decoding of powershell commands for threat hunting.

After adding the Splunk Decrypt addon #2655 to decode powershell encoded scripts I ran into a problem. Namely that the app decodes the powershell fine but removing the null padding (seen as periods) took me a while to figure out.

TL;DR  Here is the sig


There is a bit going on here:
  • I had to play with the search line a bit to capture different variations from -e all the way to -encodedcommand without false positives. The NOT filter helps with that. This is also a good place to filter noisy known good powershell from your environment.
  • The rex command is modified from the .conf2016 presentation from Bechtel. Base64 encoding can contain /+ so the \w becomes [\w/+]. I also had to play with the lengths a bit to capture as much as possible but stay within a mod 4 boundary. Note it is possible to work around that with some extra evals. If the length mod 4 is not 0 then the decrypt app fails to decode.
  • The decrypt method has been changed to output hex instead of base64. Just chain the atob (b64decode) to hex. This gives me the ability to strip out the nulls.
  • Rex regex "s/([0-9A-Fa-f]{2})00/%\1/g" to strip the nulls and prepend the % to the hex which the urldecode will need.
  • Eval urldecode converts the hex to ascii and avoids all the periods that decrypt emits using just base64 decode.
  • The regex is where I filter known goods. It will be a bit longer in production but not crazy long.
  • Table or Stats it up

This search is fast enough to go back all time so it can be a great review for historical events. Note that this is a profiling search where I filter out the false positives to view all the new unknowns. Set aside some time for your team when you first run this for all time, you may be surprised how much you can see.

Happy Hunting



References:

https://splunkbase.splunk.com/app/2655/#/details

https://www.splunk.com/en_us/blog/security/hellsbells-lets-hunt-powershells.html

https://conf.splunk.com/files/2016/slides/powershell-power-hell-hunting-for-malicious-use-of-powershell-with-splunk.pdf

https://answers.splunk.com/answers/151846/how-to-convert-hex-to-ascii-in-splunk.html

Comments

Post a Comment

Popular posts from this blog

Misleading extensions Xls.exe Doc.exe Pdf.exe

I get something out of twitter almost every day and it is not uncommon to see examples a few times before the realization sinks in that you are looking at a technique that needs a rule. These should fall under the ATT&CK framework as masquerading. I saw a tweet the other day that reminded me of a couple of signatures worth talking about. These misleading double extensions are not new but they never seem to go out of style. With modern EDRs it is an easy win. The malware filename ended in .xls.exe but lets expand that to include other office file types. index=edr ( doc OR docx OR xls OR xlsx OR pdf ) exe ( process_path=*.doc.exe OR process_path=*.docx.exe OR process_path=*.xls.exe OR process_path=*.xlsx.exe OR process_path=*.pdf.exe ) The sig is largely self explanatory, the tokenization allows for keyword search by breaking up the extension, and the process path stuff just anchors it all to the process name since these are pretty generic terms. Another tweet by blackor
Read more

Netconn from suspicious directories

Suspicious directories are an interesting topic and I am always on the lookout for them as a TTP.  The premise may be that directories like temp and downloads are already under review so some other directory should be used. That is fine for a while but once known it is easy to detect. The problem is noticing the unusual directory and adding it to your detection. I have no idea where I got most of these so if you have a post similar to this I will be happy to reference it. Number one is the recycle bin, nothing should run from here, be referenced from here and certainly not netconn. I also do a signature for $recycle.bin in the command line just to catch anything non-netconn related. These are locations to look for processes doing netconn.  Additional filtering is possible looking for activity from the root of these locations if you have a noisy one or it is a legit higher level path like C:\. A search query for only the root would look something like this: index=edr process_pa
Read more

Powershell DNS C2 Notes

I recently took a look at Powershell DNS C2 and found a couple of interesting things. The special case of DNS requests from powershell should be easy enough to identify using an EDR. Using splunk and stats just look for multiple remote port 53 occurrances from powershell. There will be a few but DNS c2 is noisy so a large limit can be used for filtering. Next I took a look at DNSCat https://github.com/lukebaggett/dnscat2-powershell Interestingly powershell does not make the dns request directly but spawns nslookup to do it. Easy enough to make a signature for that. Again, powershell calling nslookup will occur legitimately, but a large filter for occurrences will filter those out. index=edr powershell.exe nslookup.exe parent_path=*\\powershell.exe | stats values(command_line) count by computer_name parent_process_guid | where count>10 Next I went back to some old Oilrig samples which used DNS C2. Nothing new here, just multiple DNS requests directly from powershell. B
Read more