Blu3_Team

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 runnin...

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...

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 b...