Certifried Red Team Operator

I wasn't actually planning on writing up a blog about passing the CRTO, but here I am about two months since passing and felt like writing down some after-thoughts. Now that all the information has had time to simmer, there have been some key takeaways I've noticed in my day to day working in threat research. If you're not familiar with the CRTO, a TLDR is this focuses on using the C2 framework CobaltStrike from a red team perspective created by RastaMouse at Zero Point Security.

  

If you've ever worked in a SOC before, you've maybe heard the long standing joke 'it's an admin, false positive'. It used to make me laugh, until I moved in threat hunting and intelligence. Now hearing this just gives me anxiety. Elevating privileges typically isn't that difficult to accomplish but, detecting and preventing it before it has a negative impact is challenging. This is even more difficult when going against a skilled attacker that understands elevating privileges isn't necessary unless it gets them to their goal. Applying this mindset during an investigation can help us think like an attacker. Personally, when I think of obtaining escalated privileges, I think of an attacker abusing LSASS, exploiting an unpatched vulnerability, or in some cases, just buying initial access to an overly permissive account. The CRTO does a great job at introducing us to some concepts to accomplish this on much simpler levels that in my experience slip through a lot of detections and defenders.  

  

Without going too far into the weeds, many detections exist around suspicious SC usage. However, enumerating weak service and binary permissions that may be exploited to gain elevate privileges is often over looked. Using CobaltStrike beacon to accomplish this by stopping a legitimate service, placing a TCP local beacon into a legitimate services path, and then changing the legitimate services path to our beacon is an easy way to gain privileges. Using SC to do this may trigger some low/medium severity alert if the visibility is there. However, I've seen this slip by uninformed analysts before, as something so simple doesn't necessarily look nefarious. For me, this just means accounts of all access levels need to be highly scrutinized. 

run sc stop svc_legit

beacon> mkdir C:\Temp

beacon> cd C:\Temp

beacon> upload C:\Payloads\tcp-local_x64.svc.exe

run sc config svc_test binPath= C:\Temp\tcp-local_x64.svc.exe

beacon> run sc stop svc_test

beacon> run sc start svc_test

beacon> connect localhost 444

The next part that was probably the biggest take away is the configurations that are used to set up a team server and a C2 channels. I'm in a very unique position, as while going through the CRTO, I was moved into a cyber threat intelligence role and was placed on a team with an individual who has influenced my career more in the last 3 months than I thought was possible. What he's been teaching is how to track and collect CobaltStrike infrastructure using tools like Shodan, Censys, and proprietary scanners. I'm only going to speak on this from a very high level, because that whole concept of "intel gained intel loss". So what's my point here? Well for one, after pulling 1000's of beacon configs from threat actor infrastructure, most of them use the default settings. Seeing at times almost the exact configuration you learn in the CRTO out in the wild has been humbling to me and really sets the tone for the required skill set to use something like CobaltStrike.
 

    set spawnto_x64 "%windir%\\sysnative\\dllhost.exe"

    set spawnto_x86 "%windir%\\syswow64\\dllhost.exe"

The other side of this is the domains and IP's that attackers use for their infrastructure. Pay attention to these, track them, and attempt to identify patterns. The CRTO doesn't go too deep into this, but the name of the domain, when it was registered, the ASNs, or the registrars are points we can pivot on from a collection standpoint. A point I want to stress here as I'm learning both sides of tracking CobaltStrike C2, if a domain is in the top 100k, 1million or whatever it's a prime candidate to be targeted and used. Now, the caveat to this is that the bar to entry is set as high as you want it to be when using CobaltStrike. Do you want to create highly customized configurations? Sure go for it. Do you want to just copy paste well known configs? You can do that too! Do you want to compromise legitimate websites that will fool your average defender with limited knowledge? Absolutely!  

We often forget that on the other side of the keyboard, defender and attacker is another person. Attackers using this (or me) can be new or highly experienced. With this massive gap skills set it's important from a defensive standpoint to appreciate that the more skilled threat actors will likely evade us, but we can learn to find those small mistakes to find them. 

The tone this has set for me is that I feel a lot of things in security have this illusion of being behind locked doors and you need to be some hacker savant with a bag full of zero-days to accomplish anything. Really you don't, through trial and error, mostly error on my part, you can learn these same skills and apply them to your day-to-day. 

So this it for my CRTO write up, really short, but hopefully this might pique someone's interest in diving a little bit deeper into something like CobaltStrike. Whatever it may be, I'll keep learning new ways to track C2 infrastructure, refine what we are doing, and continue to hunt for attackers. One final thing to note, when I created this blog I told myself every 3 months I'd put out some *technical* piece which this really isn't but, if you're interested reading some pieces I've recently contributed to, you can find them cyber espionage intrusion analysis and MOVEit out of my life or if you want to listen ShadowTalk

Doodlederp                                                               Corgderp