Blu3_Team

Nice find by @Hexacorn on " SettingSyncHost.exe as a LolBin ". Knowing that gatherNetworkInfo.vbs had some of the same characteristics I checked it using @Hexacorn's methodology and it works great. Just rename your binary in the current working directory and trigger. I was also able to get this to work in other user writable directories so it is not just limited to TEMP. c:\windows\system32\cscript.exe c:\windows\system32\gatherNetworkInfo.vbs I don't think this is the full list of programs called but it should be most of them. reg.exe sc.exe wevtutil.exe arp.exe certutil.exe route.exe net.exe Detection Identifying a true positive for these might be tricky, not because a signature is difficult, but because even if it triggers the main indicator is not command line artifacts (which are normal) but the process path itself. A while back I did a post on detecting System32 executable from non-standard paths which would work for these occurrences. It t

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

Mixed case obfuscation is a good technique if security appliances are case sensitive and a wash if they aren't. But looking at "PoWERsheLL -e"  you know its bad so lets do a quick signature for the case obfuscation to add to our other powershell detections. Of course this ONLY detects the mixed case but this is a valid TTP as it is seen in the wild. First you will need to profile the existing common case occurrences for your network. Turned out I see just a couple of common ones which will become our filter. Profile search index=edr powershell command_line=*powershell* | rex field=command_line "(?i)(?<case_sensitive_string>powershell)" | stats count by case_sensitive_string So (?i) to do a case insensitive match for powershell and stats does its normal case sensitive aggregation. Hopefully at this point you have a small filter list. Now for the real search index=edr powershell command_line=*powershell* | regex command_line!="(POWERSH