Detecting C2 using Splunk


I have spent some time evolving this C2 detection and I will break it down into several different versions. The assumptions that I am making are that this is recently installed malware so only a handful of workstations should be seen going to the domain. The other assumption is that this is command and control and not heartbeat communication. C2 with an actor in control will have a greater session count over a few hours and that gives me the ability to filter out low count sessions. This works with both proxy and Endpoint Detection and Response(EDR) logs if you have netconn.  I run this over a 24 hour timespan because I need a lot of data to get the auto-filtering to work. The auto filtering works since over a larger time frame there is more opportunity to get a full list of pcs hitting the domain which triggers the filter after a designated limit. It is not a fast query but it is worth the wait since it can catch C2 without any other inputs. It is also not reliant on any static beaconing timeframe.

First setup the basic search parameters. There will be a lot of filters for this such as loopback, internal domains, RFC1918 addresses, not to mention scores of legitimate connections. I will leave all that out as it differs for each enterprise.

Here is an initial search just looking for a minimum number of connections over time. This isn't a realistic search, just an example to illustrate the problem.





The results will be the number of sessions to each domain by each computer. Obviously not very helpful since lots of connections mean popular sites and low connections mean even less. There is also no way to see the number of computers that went to each domain.

I'll add another counter for the computers per domain using eventstats since we can't get that count from stats when we already grouped by domain and computer.





Results from this should show pc_count along with the number of sessions for each domain computer group. Adding a filter will show us only those sessions where there  a limited number of computers hitting the domain. Higher session counts mean more activity.

The problem here is that we dont see connections over a long time period. A workstation could hit a fairly unique domain a hundred times in a very short period and this isn't what I am looking for.

We need some time buckets and Splunk has a BIN (or bucket) command for this. I kind of got it to work but ultimately I just rolled by own for visibility and control. In many cases Splunk already has date_hour and date_minute as extracted fields so you can use those. Again, I just made my own.
 



  • Convert timefomat is creating a new field "hour_minute" with the timestamp like "15:30" for use in the deduping statement and to provide counts over time
  • Dedup gets rid of duplicate entries within each minute window (aggregation)
  • Stats is now doing a distinct count of the hour_minute field as the number of deduped sessions
  • Eventstats is still counting the number of pcs hitting each domain
  • The where count now has a minimum number of sessions as well as a maximum number of computers for each domain

The special case of pc_count=1:
If I want to look only for the case where a single pc has hit a domain I can simplify the query. I could even up the pc_count a little at the cost of losing the accuracy of the hit count since they are all grouped together.



  • The pc_count is now done with distinct count and eventstats is not needed

Areas for improvement:
I could also add another field with just the hour in order to do a count of hours to make sure it spanned a given number of hours. Using the "fields" command to limit the fields is usually a good idea. This does not address IP only sessions and may not work for cloudfronting.

Another avenue to explore is to use the process paths provided by the EDR to limit the directories to interesting ones like %temp% and appdata.

The rarity principle of limiting results that are too common is useful in multiple situations. I use it for general filtering if I have a nice signature but it is just too noisy and it doesn't have to be just for pc counts. Rarity of md5, filename, file path, task name, parent child pairs are all good things to explore.

References:
http://findingbad.blogspot.com/2018/03/c2-hunting.html
https://www.splunk.com/blog/2018/01/17/finding-new-evil-detecting-new-domains-with-splunk.html
https://answers.splunk.com/answers/155062/search-proxy-logs-for-beaconing-hosts.html
https://pleasefeedthegeek.wordpress.com/2012/12/20/detecting-malware-beacons-using-splunk/https://www.threathunting.net/  

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