Detect long running processes with netconn using Splunk subsearches


I have done a couple of posts concerning detecting C2 activity and calculating duration of processes from Carbon Black data in Splunk. In this post I'll show a method of combining the two to detect network connections only from long running processes. This hunt targets script processes which can be a backdoor in themselves but are usually pretty noisy in the enterprise. This also helps close a detection gap in the way that Carbon Black logs are presented. If a single process makes a long running C2 connection the only events seen are the procstart and procend. Within those two events any amount of data can be sent and received.

The term "long running" is arbitrary, after experimenting,  I moved the time down to 5 seconds since it was easily filtered and pretty quiet. This makes sense when you think about it, there should not be many scripts that run for minutes at a time that make external network connections.


Lets start with a profiling search to find long running processes (for each scripting engine)



The event_type is critical, we need both the procstart and procend for stats to aggregate.
The where condition determines the minimum run time.

From there filter out noisy enterprise scripts so that we don't pass too much data to the outer search.

Next we convert the search to a subsearch and export just the process_guid.

Here is the format



Finally add the outer search to complete the search



Note that we now can filter netconn events by remote_ip or domain to clean up our results.
In practice there should be a number of filters necessary to quiet things down.
The search is a bit slow on long time frames but runs fine looking back a couple of days.

This is the example with cscript but wscript, powershell and any other target process will work the same.

- Update -

Alex Teixeira (@ateixei) brought up a pertinent point that subsearches timeout after 60 seconds and have a limit of 10000 results returned. This makes the inner search filtering and profiling very important. I went back and ran just the inner searches up to the point of failure to make sure I could filter them and keep them withing the limits. This brought to light an interesting feature of Carbon Black logs which usually isn't a problem. We actually get three proc logs, one procend and two procstart but one of the procstart logs has limited data (no command line data). It became necessary to filter this event since the normal filter was only filtering the one with the command line data. The added filter is:

NOT ( command_line="" procstart )


Good hunting

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