One of the most common words that a new guy on the team will hear me say is “Pivot.” And while Archimedes was a pretty cool guy, that’s not what I’m talking about. In order to succeed at red teaming - at emulating what real-world adversaries do - you have to be able to pivot around inside of a network from an initial point of compromise (or from a beachhead system) to compromise other systems without reaching back out to the Internet. That means pivoting.
I’m going to use Cobalt Strike as my toolset in this example, because that’s what I’ve been using recently in my day job. It’s an awesome tool and while I’m not going to gush at length on this, you should give him your money. A few other useful tools are PowerView (specifically Invoke-StealthUserHunter and Find-LocalAdminAccess) and PowerSploit (specifically Invoke-Mimikatz).
Anyway, one of the most awesome features Cobalt Strike has is the ability to spawn implants within a network that communicate over SMB named pipes. SMB named pipes have been around in Windows forever, and yet defenders still don’t watch for such activity. Part of that is because it’s really hard to watch all internal-to-internal traffic on a network and part of it is because the tools to do so don’t exist. That said, in the 20 years since Windows 95, people could have written some pretty awesome tools to do so. But they haven’t (to my knowledge). So we exploit that.
To get that first host on a network, I use phishing. It works well, I can control who I target, and by using something like macros I’m able to get reliable execution without needing a client-side exploit. However, sometimes clients don’t need us to prove that attackers can win at phishing, sometimes they start us off on a random host with an unprivileged domain user. Either way, we land on a host. Yay, us!
However, the first host you land on isn’t where you want to stay. If you’re going to get detected at all during an engagement, I’ve found that you’re most likely to get detected on that initial host. Whether it’s someone spotting the phishing e-mail, the initial callback, privilege escalation, etc. - that’s the most likely spot to get burnt. As a result, you need to establish a beachhead. You need to gain access to some other system on the network that isn’t your phishing victim, using a different C2 server, so that it won’t get destroyed if someone spots your phishing e-mail a month later.
As a result, we now have a beachhead calling out to a clean command and control server:
Pivoting and Escalation
As part of an adversarial emulation engagement, we always have an intelligence objective beyond domain administrator. Whether that’s trade secrets, financial data, or simply access to a key individual’s e-mail, it’s something that distinguishes what we’re doing as having a motive beyond “I like to commit felonies.” That said, domain administrator is still a valuable stepping stone in our path toward victory, as it gives us the access we need to impersonate other users, monitor the defenders to see if they’re on to us, etc.
As a result, the first thing we do from the beachhead is to start using our existing access to see how we can spread. Our primary access goal is to achieve domain administrator credentials, so we look at the network and see if we can find any system where a domain administrator is logged in that we’ve got administrator access to (StealthUserHunter is key for this). If yes, we go right there and win. If not, it might take a few steps of repeating the same methodology going from workstation administrator to server administrator to domain administrator.
At each step of the way, we’re elevating our permissions, gathering more legitimate domain credentials, and still using SMB named pipes to tunnel around inside of the network. Our only communications with the outside world travel over those orange arrows in reverse back to the single node that is sending traffic out to the world over HTTPS. For most defenders, that single egress node is their only means of spotting us. They don’t have the eyes inside of their network and aren’t watching their logs for the right kinds of information.
In the above image (sanitized from an engagement), the bottom-right host gave us the domain administrator access that we needed, once we’d traveled down the upper path a bit more getting administrator access onto a management server. At this point, we pop the champagne and start our victory dance, right? I got domain admin, that’s what pentesters do!
Domain Compromise and Action on Objective
Except that’s not what we do. We go further and compromise whatever your key intellectual property is, helping you to understand how someone can turn your domain against you and gain access to the critical resources. After all, that’s what the bad guys are doing - they’re compromising your domain and then harvesting your intellectual property, accessing your financial database, or simply spying on all email to/from your executive staff. Think about your own organization: what one thing, if a bad guy got to it and either stole it for their own ends or published it online, would be the end for you and your company? That’s what we go after in order to make sure it’s protected.
So what does that look like, once an attacker starts to move in that direction post-domain compromise? Again, how would the defender be able to spot this activity and counter it? My graphic is a little busted since I was tearing down the infrastructure at the time, but you get the picture:
That’s a lot of access throughout an internal network, getting into a wide variety of systems. And yet it’s all tunneling back over SMB named pipes and up across the Internet to my C2 server through a single node over HTTPS. Likewise, I had a few other systems calling back to a different C2 node as my backups. If the defenders had spotted my egress node, I could have used one of my other Beacons to relink my entire in-network infrastructure back together and not lost any time, because it’s highly unlikely the defenders would have traced down everything in time to stop me.
Defenders Behind The 8-Ball
So how do you spot this kind of exploitation? Are you prepared? Does your SOC staff have the skills, the tools, and the training to understand that this is not only how attackers are going to come at you, but are they able to detect and contain the intrusions?
In my example above, if I’d been really evil and the client had spotted me, they would have had to shut down all Internet access to their enterprise network (to sever all potential C2 channels), force domain-wide password resets (including double-resetting krbtgt), and then they would have to hunt across the domain to try to ensure they found all of my Beacons, including any fallback beacons communicating to different C2 nodes over different protocols. And if they missed any? When they bring the link back up, I’ll just sit patiently and wait… and then take the network back over.
There isn’t a single blinky box in the world that’s going to teach you how to defeat this kind of attack - it’s going to take a competent, well-trained SOC staff who understands adversarial tactics and has the tools and (most importantly) network/host data to spot something like this before it gets to the point of rebuilding your network. Is your staff ready?