Archive for the ‘Red Team’ Category


The Best DerbyCon 2014 Talks for Red Teams

October 6, 2014

DerbyCon is one of my favorite conferences. I think its review committee does a good job choosing talks that are relevant, not just novel for the sake of novel. I worked my vendor table the whole weekend, but thanks to Irongeek’s amazing speed at putting videos online, YouTube’s 2x playback feature, and post-con insomnia–I went through a lot of DerbyCon material. Here’s my list of talks that are most relevant to red team operations.

Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades

This is probably my favorite DerbyCon 2014 talk. Tim Medin demonstrates how to request Kerberos service tickets, dump them from memory, and crack the passwords of these service accounts. He then demonstrates how to forge new tickets with the cracked password and give yourself elevated rights in some service contexts. It’s a pretty amazing talk and it’s something I plan to play with in my lab.

Secrets of DNS

In this talk, Ron Bowes shows some interesting uses of DNS. All of this was just a warm up though. Towards the end he introduces DNScat 2, a post exploitation agent that uses DNS to communicate. He talks about some of the lessons learned from the original DNScat and goes through his roadmap to build up DNScat 2, including a planned SOCKS pivoting feature. He also took the time to share the challenges of building a communication channel on top of DNS. Things like queries sent multiple times, queries that arrive out of order, and caches that hold on to things forever. I know, first-hand, the amount of work it takes to pull something like this off and this talk is a must-watch for anyone who (ab)uses DNS as a data channel.

Passing the Torch: Old School Red Teaming and New School Tactics

In this talk David McGuire goes through “old school” ways to interrogate a domain, abuse trust relationships, and steal interesting data. These topics and this process don’t get enough attention in our community. David woke me up to this and it has had a major impact on how I hack over the past two years. To see this influence, compare the lateral movement videos I’ve cut over the past four years: 2011, 2012, 2013, and 2014.

Will Schroeder is one of the developers of the Veil Framework. He also writes a lot of awesome stuff [1, 2] in PowerShell. Like me, Will hates doing things a computer could do better. Will has worked to automate a lot of David’s tradecraft and develop some of his own.

The talk covers a lot of information very quickly. The big pay off is at the end when David and Will each execute their methodologies to show the Old School vs. New School way of hacking. Now that Cobalt Strike’s Beacon supports PowerShell, I expect that my process will evolve to rely on these new school tactics.

Et tu Kerberos

This talk is a great survey of the Golden Ticket attack in Mimikatz. Chris Campbell goes through recent history about pass-the-hash, talks about the Golden Ticket attack and where it came from, and offers some pointers on which mitigations do and don’t work.

Red Teaming Back and Forth 5ever

I used to work for Automattic, the company behind Almost everyone in the company had an Apple computer. I’m Windows focused in my product and I’ve wondered what tactics work in a MacOS X environment. Fuzzynop provides the answer. In this talk, he goes through his quick and dirty C&C for MacOS X. He also digs into quick and dirty post-exploitation tricks for MacOS X as well. If you have to go against a MacOS X environment or you just want to watch an entertaining talk from a hacker who has to think different, I highly recommend this one.

Getting Windows to Play with Itself: A Pen Tester’s Guide to Windows API Abuse

This last talk comes from Brady Bloxham at Silent Break Security. I’ve known Brady since 2011 and he’s scary brilliant. In this talk, Brady challenges the audience to expand their capability-level beyond that of the casual attacker. This is an important call to arms and I agree with what Brady says here. This talk starts out with some advanced Windows persistence techniques, a primer on process injection, and tips to build on this material. The real pay off happens at the end. Brady introduces Throwback, a stealthy beaconing persistent-agent that’s now open source. You’ll want to check it out as a possible tool for your arsenal. If you want to learn to build your own tools, Brady Bloxham and Bryce Kunz are teaching Dark Side Ops: Custom Penetration Testing at BlackHat Trainings DC in December 2014.

If you watched these videos, you’ll notice there’s a theme. Each of these talks is a post-exploitation talk. Attackers will get in. We can’t just enumerate the ways this may happen. We have to help our customers understand their ability to slow down, detect, or frustrate a motivated and well-resourced attacker, post-compromise. Each of these talks operates with this fundamental assumption.

Each of these talks also demonstrates new tools and new approaches. You can’t represent a credible threat with commodity capability only. If you’re going to play at this level, you’ll need to  retool and rethink your approach. You can build capability or buy it.

Final note, trust relationships matter. There are many ways to attack and abuse trust. We’re just scratching the surface here. The best talks are going deep into this subject. This is the present and future of hacking modern enterprises.


The Post Exploitation Team

September 18, 2014

I often get asked about red team skills and training. What should each team member know how to do? For exercises or long running attack simulations, I believe it’s fruitful to put junior members into the post-exploitation role first. This post describes the post-exploitation team, where they fit into the overall engagement, and their core tasks and skills.


Before we dig into the post-exploitation team, let’s go big picture for a moment. The following diagram is from my 2012 Dirty Red Team Tricks II talk at DerbyCon. It shows the model for hand-off from persistent access to post-exploitation that I saw evolve during the 2011 and 2012 CCDC seasons.


This diagram isn’t far off from the infrastructure and access hand-off model that I recommend today. The main difference is that I recommend the use of staging servers. These servers act as an intermediary between the servers for long-haul persistence and interactive post-exploitation.

The workflow from the above diagram is still the same.

Getting to Post Exploitation

An access team works to get a foothold into a target network. There’s a lot that goes into getting a foothold–especially when it’s important to not get caught.

The next step is to escalate privileges on the network, ideally to domain administrator. Domain administrator is not always required to accomplish a specific goal. It’s a stepping stone to easily accomplish a goal on a network.

It’s important to also setup persistent payloads through the network so that the red team may regain a foothold, with privileges. These payloads should call home to the long-haul infrastructure.

These steps to get a foothold, elevate access, and execute a persistence plan are (potentially) hard. These steps depend on the target environment and may require custom code to succeed. You want your strongest people available for these tasks.

Post Exploitation

As sexy as it is to break in, take the terrain, and hold it, no one breaks into networks and holds them for no anticipated purpose. It’s important to have objectives. Depending on the engagement, these objectives may mirror those a likely adversary would go after or they should satisfy training criteria for a network defense team.

Conducting post-exploitation activity and working on objectives is something well-trained, but potentially junior, red team members can do.

What should the post-exploitation team know how to do? What are their core skills? These team members should know how to task an asynchronous agent into interactive access. I arbitrarily define interactive access as a payload that calls home on a one minute interval or faster.

Interactive control should always happen on infrastructure that is separate from the infrastructure used to receive low and slow callbacks. This helps protect the red team’s operational security. If an interactive access gets caught, you do not want to lose all of your persisted access because of it. Ideally, the tool for interactive access is different from the tool for low and slow access [or, at least, different indicators!].

Once a team member has access to a system, they have to work from that access. They must know how to navigate a file system, download files, log keystrokes, take screenshots, hijack browser sessions, and otherwise grab whatever satisfies the objective they’re out to meet. They should also know how to interpret the output from each of these tasks and act on this information. They must also know how to triage sources of information and find what’s interesting, quickly.

Team members should know lateral movement, cold. They must know how to work with credentials, tokens, and Kerberos tickets. They should know their options to touch other systems with these things. If they need to use a payload (NOT always the right answer); they should know how to bootstrap the payload with PowerShell when it’s possible. If they have to fall back to an executable, they should know how to generate an anti-virus safe artifact.

Concretely, I expect post-exploitation team members to know how to start a remote process with psexec, at, schtasks, wmic, and sc. This skill also requires the team member to understand the nuances of which artifacts they can and can’t use with each of these. For example, if I try to schedule a plain executable with sc it will fail. Why? Because sc expects an executable that responds to Service Control Manager messages. If I schedule an executable that doesn’t do this, Windows will kill it very quickly.

All red team members should have judgement. They should know that the direct route isn’t always the best way to fulfill a requirement.

Team members should understand that some post-exploitation actions will fail depending on several contextual factors. Troubleshooting these contextual factors comes with experience. It’s helpful to have a senior lead on hand to step in when a junior member gets stuck.

All red team members should know how to tunnel external tools through any interactive post-exploitation tools in use. SOCKS and proxychains are good topics of study. All red team members should also have strong knowledge of the standard clients that interact with common services.

Finally, red team members should know how to clean up after themselves. If they’re done with an interactive access, they should know to drop it.

These core skills cover most of the work a post-exploitation team will do. Train several junior members with these skills, assign them to a senior lead, and you’ll get a lot of use out of them. They’ll grow during the engagement too.

Tradecraft, parts 4 through 9, covers these topics.


Infrastructure for Ongoing Red Team Operations

September 9, 2014

Recently, I’ve had several questions about how to set up infrastructure for long running red team operations with Cobalt Strike. This is an ideal use case for Cobalt Strike. In this post, I will reiterate the advice I’ve shared with these users.

System Requirements

You will need to set up infrastructure to use for your engagement. I recommend that you host each piece of attack infrastructure on a VPS. I’ve used Linode and Amazon’s EC2 for this purpose. Make sure you factor the cost for multiple VPSs into your assessment budget.

I do not recommend that you setup a reverse port forward through your office’s NAT device. It’s in your best interest to minimize the number of devices and weird configurations between you and your target. It’s enough effort to guess what their network is doing, you don’t want to add troubleshooting your devices into the mix.

Attack infrastructure, for the purpose of this blog post, comes in two flavors: team servers and redirectors.

Team Servers

A team server is the server component of Cobalt Strike. It wraps the Metasploit Framework, connects to the database, and manages Cobalt Strike’s features. Multiple people may connect to a team server at one time. I also make the Cobalt Strike client available for Windows, MacOS X, and Linux.

You will want to follow the Cobalt Strike system requirements when you spec out a team server. I recommend 2GB of RAM, but you can get away with 1.5GB or more. On Amazon’s EC2, I use the c1.medium instance with 1.7GB of RAM. I like to set it up with a 64-bit flavor of Ubuntu 12.04.

Cobalt Strike’s quick-msf-setup script makes it very easy to set up the dependencies for a team server. This script is distributed with the Cobalt Strike Linux package. Run quick-msf-setup, choose your install preference, and everything else is taken care of for you. I use quick-msf-setup’s Git option to stage my dependencies.



A redirector is a system that proxies all traffic from your target’s network to a team server system. Redirectors give you IP diversity. You may configure listeners for Meterpreter and Beacon that call home through different redirectors. Beacon will phone home through multiple redirector addresses if you tell it to. I get away with low powered servers for my redirectors. An EC2 micro instance is fine here.

I also recommend that you obtain several domain names to use for your engagement. You will want to assign A records that point to each of your redirectors and team servers. If you choose to use the DNS Beacon, you will want to make its team server authoritative for multiple domains.


Use Multiple Team Servers

I’ve seen attack infrastructure proposals that rely on one team server supported by multiple redirectors. This could work, but Cobalt Strike lets you take it one step further. The Cobalt Strike client connects to multiple team servers at one time. Each server may have its own listeners supported by its own set of redirectors.

I recommend that you designate a role for each team server that you stand up. When I setup infrastructure, I group my servers into three categories: long-haul, staging, and post-exploitation.

Long-Haul Servers

Long-haul servers catch callbacks from hosts that you’ve setup persistence on. I call these servers long-haul because they’re meant to maintain long-term access into your target’s network.

I use Cobalt Strike’s Beacon payload for long-term persistence. Beacon will call home to multiple servers, it speaks multiple protocols, and it’s designed for asynchronous “low and slow” operations. These are nice characteristics in a persistent agent.

Cobalt Strike’s Beacon does not have a turn-key persistence mechanism. If I put one in, everyone would know what to look for. You may export Beacon, without a stager, in a variety of formats though. I recommend that you architect a persistence strategy that makes the most sense for your engagement.

Long-haul servers require discipline to use effectively. These servers are your crown jewels as an embedded attacker. If they’re found out–you may find that your engagement is over. Here are a few tips to get the most of your long-haul infrastructure:

1. Never pass a session to a long-haul server

Every access on a long-haul server should come from a persistence mechanism. This allows you to monitor the status and health of your compromised systems. If a system isn’t calling back, it means it’s down or something is wrong with the persistence. This is your cue to investigate.

2. Use high callback times

Long-haul servers are designed for long-term access to a target’s network, not necessarily convenient access. I recommend that you configure your Beacons with high callback times. Consider a 24-hour callback interval with some randomization.

3. Use unique profiles

If a staging or post-exploitation action gets caught, you don’t want an indicator from that communication to lead to your long-haul infrastructure. Cobalt Strike’s Malleable C2 is a boon for these situations.

Malleable C2 lets you redefine the indicators in Beacon’s communication for each team server. Profiles take five minutes to write and test. Make sure your long-haul profile looks different from other profiles you use.

You may configure a default sleep time and jitter [randomization] factor through Malleable C2 as well.

4. Take Advantage of Protocol Diversity

I like to run two long-haul servers. I use a DNS Beacon on one server. I use an HTTP Beacon on another. I find that the DNS Beacon with a high sleep time and multiple domains offers a great challenge to professional network defense teams. The DNS Beacon uses one A-record request to an attacker controlled domain to “phone home”. One A-record request every 24-hours is quite benign.

5. Have a Persistence Strategy

The purpose of the long-haul servers is to keep a foothold in a target network or enclave. You do not want every compromised system to call home to this infrastructure. I recommend that you architect two persistence strategies. Let workstations beacon home to your attack infrastructure. Come up with something else to maintain access to compromised servers. You do not want high-value compromised servers calling out to your long-haul infrastructure.

Staging Servers

Staging servers are an intermediate level of infrastructure between long-haul persistence and interactive post-exploitation. I use staging servers as a convenient place to hold access to systems I plan to work with in a short period of time.

I use Beacon on staging servers with a sleep time that’s high enough to avoid detection but low enough that it’s convenient to use.

When I task access from a long-haul server; I almost always task the access to a staging server. Tasking an access means asking Beacon to spawn a session on another server when it checks in next. This is something built into Cobalt Strike’s workflow.

I recommend that you set up one staging server with its own redirectors to start with. If it gets caught, that’s OK. Spin up another one in its place.

Post-exploitation Servers

Post-exploitation servers are for interactive access to a compromised host. By interactive access, I mean a payload that calls home every minute or faster. This is Meterpreter and Beacons with a low sleep time.

Interactive access has its uses. You can pivot third-party tools into your target’s network and you get immediate feedback on your actions.

Request interactive accesses from your staging servers.

When I use a post-exploitation server; I tend to tunnel my Meterpreter sessions through Beacon rather than rely on the Metasploit Framework’s native handlers.


During your long engagement you will need to manage software updates carefully. I recommend that you never update a production team server during an engagement.

I work a lot on Beacon and I regularly break backwards compatibility with Beacons from previous releases. Be aware of this!

If a Metasploit Framework or Cobalt Strike update includes compelling features; feel free to introduce new software to your engagement. Just do it through a separate team server. Post-exploitation and staging servers are very transient and there’s no reason for these to stay the same for the length of your engagement.

Make sure you’re careful with those long-haul servers! If you need to update these, create new infrastructure with updated software, and reapply your persistence with the new long-haul servers as the target. Keep the old infrastructure available until you’re 100% confident that everything is moved over.


I get asked about licenses and team servers. Cobalt Strike is typically licensed to X users in an organization. Users with a Cobalt Strike license are allowed to use the software on as many systems as necessary to do their job. Team servers count in this. Team servers are not a new user. So, if you have one license and one user, you’re welcome to spin up as many team servers as you need. If you have thirty licenses [you’re awesome!] and thirty users, you’re welcome to spin up as many team servers as you need.


These are my notes on setting up long-running attack infrastructure with Cobalt Strike. You’ll notice a lot of Cobalt Strike features play into this scenario. The distributed operations capability allows you to manage multiple servers. Beacon is a flexible agent that works as a persistent agent, acts as a placeholder for interactive accesses, and even offers an alternate communication layer. Better–you can customize Beacon’s C2 so each of these uses have their own indicators. This isn’t by accident. Managing accesses across distributed infrastructure in a team friendly way is Cobalt Strike’s bread and butter.

Tradecraft, part 9, speaks to some of the concepts in this post.


Puttering my Panda and other Threat Replication Case Studies

August 14, 2014

Cobalt Strike 2.0 introduced Malleable C2, a technology to redefine network indicators in the Beacon payload. What does this mean for you? It means you can closely emulate an actor and test intrusion response during a penetration test.

In this blog post, I’ll take you through three threat replication case studies with Cobalt Strike. In each case study, we will emulate the attacker’s method to get in, we will use a C2 profile that matches their malware, and we will analyze what this activity looks like in Snort and Wireshark.

Putter Panda

Putter Panda is an actor described by a June 2014 Intelligence Report from CrowdStrike. In this video, we replicate Putter Panda’s HTTP CLIENT malware and use a Document Dropper attack to deliver it.

String of Paerls

String of Paerls is an intrusion set described by Sourcefire’s Cisco’s VRT. In this video, we replicate the actor’s C2 with Beacon and use a macro embedded in a Word document to attack a target. We also reproduce the attacker’s phish as well.

Energetic Bear / Crouching Yeti / Dragonfly

This actor, known by many names, allegedly targets the energy sector. The best information on this actor came from without a slick PDF or PR team to back it up. In this video, we replicate this actor’s havex trojan with Beacon and use a Java drive-by exploit to attack a target.

With the right technologies, threat replication isn’t hard. Read about and understand the actor’s tradecraft. Craft a profile that uses the actor’s indicators. Launch an attack and carry out your assessment. Threat Replication is a way to exercise intrusion response and see how well a security program stands up to these actors.


Pass-the-Golden-Ticket with Cobalt Strike’s Beacon

July 30, 2014

Back in May, I wrote up some impressions about Meterpreter’s Kiwi extension. It’s Mimikatz 2.0, complete with its ability to generate a Kerberos “Golden Ticket” with domain-admin rights offline.

I’ve had a very positive experience with this capability since May. My best practice is to create a Golden Ticket catalog. When you capture a domain controller, get the krbtgt hash, and store it in this catalog. Keep this catalog for the duration of the engagement.

Golden Ticket Catalog

= Network Name =
2. Domain Administrator User
4. krbtgt hash

If someone cleans you out of their systems: just phish another user, use the catalog information to generate a ticket, apply the ticket, and you’re right back at domain admin. It’s nice. The Golden Ticket capability really is a “persistent” attacker’s dream.

This assumes that the network owners don’t follow steps to re-roll the krbtgt user’s password. I suspect this will become part of a post-attack cleanup process, but it’ll take time for this practice to disseminate.

I recommend that you keep a catalog of ticket information over a collection of pre-made tickets. Here’s why: You may create a ticket for a user. If that account gets disabled, the ticket will no longer work. If you end up in this situation–use the net group command to query for the new domain admins and update your catalog accordingly.

To apply a self-generated Kerberos ticket to my current session: I have to either drop something to disk (mimikatz 2.0) or I have to switch to interactive command and control with Meterpreter. Those who’ve worked with me know that I dislike interactive C2. It has its place, but it’s also an opportunity to attract attention from a good network defense team. I’m also not a fan of touching disk–unless I really have to.

So, what does a hacker do when caught between two unlikeable choices? Make a third.

I’ve added support for self-generated Kerberos tickets to Cobalt Strike’s Beacon. Now, you may inject a Golden Ticket into a Beacon session and use it for lateral movement. This is a natural marriage.

Beacon’s lateral movement workflow requires its user to generate an artifact, copy it to a target host, and schedule it to run. I’ve built a minimal set of tools into Beacon (e.g., privilege escalation, token stealing, and now ticket injection) to support this. The rest of these steps happen using native tools on the target’s system. I’m a big fan of doing lateral movement with native tools as it’s less likely to look like hacker activity.

Seriously, if I have to answer for one more service named XtAx754A running a malicious ApacheBench–I’m going to scream!

Here’s a video that shows pass-the-ticket with Cobalt Strike’s Beacon:

If you’re headed to Las Vegas for BlackHat USA or DEF CON–you have an opportunity to hear more on Kerberos abuse at both conferences. Benjamin Delpy and Alva “Skip” Duckwall will deliver Abusing Microsoft Kerberos: Sorry You Guys Don’t Get It at BlackHat USA. Chris Campbell will deliver The Secret Life of KRBTGT at DEF CON. I expect that these talks will give this subject the authoritative treatment and depth it deserves. Be sure to check them out.


Use Cobalt Strike’s Beacon with Veil’s Evasion

July 24, 2014

The Veil Framework is a collection of  red team tools, focused on evading detection. The Veil Evasion project is a tool to generate artifacts that get past anti-virus. It’s worth getting to know Veil. It has a lot of capability built into it.

Cobalt Strike 2.0’s Payload Generator includes an option to output a Cobalt Strike payload in a format that’s Veil-ready. Go to Attacks -> Packages -> Payload Generator to open it. Choose your listener and set veil as the output type. Save the file it generates.


Now, go to Veil and choose the type of artifact you want to create. Veil will ask if you want to use msfvenom or supply your own shellcode. Select the option to supply your own shellcode. Paste in the contents of the veil file made by Cobalt Strike. Congratulations–you have made a Veil artifact with a Cobalt Strike payload.

Here’s a video that shows this process:

Before Cobalt Strike 2.0, there were ways to deliver Beacon with Veil. Cobalt Strike’s Beacon is compatible with the Metasploit Framework’s reverse_http and reverse_https stagers. You had the option to use the Metasploit Framework’s stagers to deliver Beacon. That said, Cobalt Strike’s Beacon has its own stagers that are not available to the Metasploit Framework. Cobalt Strike’s DNS stager will download Beacon over DNS and inject it into memory. Cobalt Strike’s HTTP/S stagers account for proxy restrictions that other HTTP/S stagers do not. This new option in Cobalt Strike’s Payload Generator lets you use these custom stagers with Veil.


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.

Payload Configuration

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.

Survivable Access

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.

On-disk Persistence

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.


Get every new post delivered to your Inbox.

Join 13,456 other followers