The Access Management Team [Shell Sherpas]June 18, 2014
When I participate in an exercise, with multiple target networks and a large red team, I favor splitting the team up into cells. Each cell owns a target network and is responsible for any objectives that must occur in that target network. These cells are supported by an access management team.
The access management team is a global support role and it’s the only team that touches all of the networks. Access managers offer red cells stable access to key assets in their target’s network. This enables on-going post-exploitation. This is their job.
I refer to access managers as shell sherpas, because they protect and herd shells.
In this post, I’d like to offer details on what an access management team does.
An access management team has to configure payloads that will walk through whatever static defenses are in play. They take a guess at all of the things the available payloads do, they reason about things that look strange on the wire, and they try to figure out how to adapt the available tools to get around these things.
Some target networks will not require this support. Others will. I see advanced payload configuration (and development) as a specialized skill, one that’s rarely co-equally available to all cells.
[I’m working to make payload modification accessible to non-developers though. I have a prototype language that offers fine-grained control over the indicators and behaviors of my Beacon payload. This will allow access managers to creatively bypass content filters, design communication schemes that blend in with the target’s environment, and exercise a blue team’s attribution process by replicating known malware.]
Manage Callback Infrastructure
Once we have a way out of a network and past static defenses, our second task is to make sure we have survivable communication. This involves diversifying our access and making sure each payload calls back to multiple hosts. If some of our hosts get blocked, it’s nice to know our access can still survive. Better, it’s best to avoid drawing attention to our access where possible. For this, we rely a lot on low and slow beaconing over DNS to maintain a lifeline to a host when no one is using it. As an access management team, we usually setup and manage this callback infrastructure.
Third, we have to make sure that our payloads live in processes that are survivable. If we know that a defense team is good at host-based anomaly detection, we have to gear up to play in this space. Once we have survivable communication, our next priority is to find a process we can live inside of without drawing too much attention. notepad.exe is not the best option.
Survivable access is an interesting problem and the best answers to it are not always obvious. There’s a tendency to want malware that can survive any scrutiny and stay on any host no matter what. When I wear my access manager hat, I know I don’t have this magical malware. We get creative and think about other ways to survive in a network. We don’t need to survive on each host. We just need a way to regain access to key hosts at will.
Fourth, we have the opportunity to worry about on-disk persistence and how to survive a reboot. This is its own can of worms though. Let’s say we land a user-level access. What do we do with it? We could stick an executable in a startup folder for the current user or schedule a process to kick off when the user is idle. If it’s an exercise, we’re probably dealing with application white-listing, so that won’t work. We could try to schedule a task with a PowerShell one-liner to avoid dropping an artifact. That might work, in some cases. Or… we could try to escalate privileges on the systems we land on. If these systems are a newer patch level of Windows 7 and there is little evidence the system is lived in (e.g., no installed software with configuration issues); our chances to escalate, without 0-day, are probably nil. We can try though. If we do escalate privileges somehow, then we have more options to fortify and secure access on the host.
I’ve participated in a number of exercises, both with and without an access management team concept. The access management team is the keystone of a large-scale red team operation. An access management team takes on tasks that are easy to execute on all networks at once, saving each cell this extra work. The access management team also serves as a clearing house for solutions to problems other teams had to solve. An access management team, given their control of long-haul infrastructure, is also a tool to provide red team leadership a sense of target health/difficulty across the board.
Tradecraft, part 9 discusses red team operations with Cobalt Strike and how a shell sherpa would fit into a team construct.