Blu3_Team

Update: See "An easier method of finding duration of processes" to simplify this. I came across this interesting tweet from @subTee that got me interested in not just this TTP but looking at process durations in general. That could be a good method to have in the toolbox. It makes sense that userinit.exe should not run for long so I looked to see how I could calculate the duration using Carbon Black process logs. One method of calculating values where you need timestamps from two different events is to use the Splunk streamstats command but I try to avoid it because it can be slow. Luckily Carbon Black shows an event for both process start and process stop which has the timestamps so I just needed to get them together. field name "type" contains process start or process stop field name process_guid contains the unique id for the process Calculate the duration of the process index=edr event_type=proc process_path=*\\userinit.exe | stats values(type) ...

Having signatures for common techniques is great but let's take it to the next level. Imagine if a script executable is simply copied with a new name, will your dectection still trigger? This is a good technique to keep in mind while creating searches. Take a look at the following Splunk search to detect mshta.exe with suspicious strings. index=edr mshta.exe getobject script (vbscript OR javascript) command_line!="" | table command_line process_path computer Works great, lasts a long time right, but a central match is the mshta.exe string. Here is another version which negates the mshta.exe to catch just those where the file has been renamed, which in my view would be a higher severity and I want to see those separately. index=edr mshta.exe getobject script (vbscript OR javascript) NOT mshta command_line!="" | table command_line process_path computer Here is another example to find the -accepteula string from sysinternals psexec. index=edr -acce...

Sometimes it is helpful, especially in a large organization, to break up a search like C2 or processes with netconn into categories based on the directory. The directory may even provide some help with triage as we can make some basic assumptions. download: user initiated temp: generally not user initiated appdata: the installer wants to look legitimate All of these are fuzzy but I generally find potentially unwanted programs(PUPs) starting from download and the initial callback can help to identify it. Temp can be anything but those are sometimes the most interesting. For appdata installs I generally look at the directory name first, legitimate installs mimic the installer name while PUPs try to be clever and use a nonsense name. Finding generic malware isn't sexy but if you hope to find the tricky stuff then you'll need a good base detection for everything else. As usual, any filtering has been left out of these examples. Executions from Appdata\roaming -not netconn...

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

I have no qualms about boiling a small ocean if it means detecting malware. I wrote earlier about some individual occurrences of malware that use legitimate system32 executables in non-standard paths for DLL side-loading. A colleague asked why we couldn't do all the checks at one time so we worked on a method to do just that. It turns out that there are over 600 executables in system32. The first thing I tried was just to put them all into a big search and be done with it. You can try it if you want but I had no luck getting Splunk to run a search string that large. So we converted the list to a csv. To get the filenames from the inputlookup to expand to the search we want I had to use the following format and a header value of "process_path". You'll see the reason for the header and the *\ in a little bit. process_path *\agentservice.exe *\aitstatic.exe *\ald.exe The way inputlookup is expanded the search string will become: (process_path=*\\agentservice.ex...

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

I observed a couple of malware samples that did multiple dll side-loading by copying (assumed) system32 exes to a random path in appdata\roaming and dropping their own malicious dll. sigverif.exe -> version.dll rdpinit.exe netplwiz.exe -> netplwiz.dll applysettingstemplatecatalog.exe -> activeds.dll computerdefaults.exe msdt.exe -> duser.dll utilman.exe -> dui70.dll Assuming you have EDR data in Splunk here is a simple detection example to look for the executable and negate the normal path. index=edr msdt.exe process_path=*\\msdt.exe process_path!=c:\\windows\\system32\\* There are some other paths to negate as well but I want to keep it simple here. Related post to detect ANY system32 executable running from a non-standard path. Mitre ATT&CK ID T1073 References: http://www.hexacorn.com/blog/2016/03/10/beyond-good-ol-run-key-part-36/

If a method is used more than once then it begins to become a technique for the actor and worthy of a signature and signatures are cheap. Here are a couple that might trip up some internal red teams or testing. payload.txt dest_port = 1337 mimikatz powersploit powerview nc.exe metasploit exploit kerberoast You get the idea, don't make it easy on them.

I hope to publish some techniques and methods of detection that have worked for me. These are not original to me necessarily but adopted and adapted from many sources. Some will be broadly focused such as C2 detection and others might be a quick TTP pulled from Twitter. As I have recently switched from using Arcsight to using Splunk I have had to rethink and relearn many things, hopefully you might gain from my pain.