Why Most Red Teams are Really Pentesters

Something that we have seen increasingly often on Twitter recently is people ostensibly posting about “Red Teams” and how if they did what APT X did, all their colleagues would be laughing at them. This is arguably a huge problem and we don’t mean the laughing. Not every organization is going to face the same tier of threat. This gives us a perfect segway to highlight the topic of this blog, that most “Red Teams” are in fact pentesters. I’m sure many of you are thinking, “if they have custom tools, then how are they not a Red Team?”

Red Teaming vs. Pentesting

Let’s take a step back and talk about the differences between Red Teaming and Penetration Testing. Fundamentally, a Pentest is focused on identifying shortfalls within the technical controls of an organization. You can think of these as probing networks for vulnerabilities in a system and developing ways to exploit or avoid the newest and greatest next-gen (insert other buzzwords here) EDRs. This may involve building custom tools because you discovered a way to exploit a new vulnerability.

While a Red Team is focused on testing the people and processes of organizations. Typically, this will be accomplished by comparing common threats against an organization to what is being seen in the wild. That way, the threat emulation is tailored against a customer and matches what threat or APT they may encounter.

On the surface, that’s a pretty straightforward distinction, but it gets a little more complicated when you put it into practice. For a pentester, your job is to be threat-agnostic while you test technical controls and identify as many vulnerabilities as possible.

Red Teams on the other hand, have to tailor their Tactics, Techniques, and Procedures (TTPs) to the level of the organization. For example, APT29 will most likely not target a mom-and-pop gift shop with a limited budget to support its 56K modem.

There’s also a little bit of a grey line as to where the line between technical control and organization process lies. Is a poorly configured EDR a failure of process or technical control? What about an overly permissive firewall? Or a SIEM that isn’t collecting enough data?

Defining or attempting to define the line between what is actually a technical control and organizational process would take an entire master’s course to teach. But for today, let’s focus more generally on how Red Teams should be employing their skills.

One important aspect of Red Teaming that gets overlooked is providing feedback back to the Blue Team/customer. Some people may call this “Purple Teaming,” but at the end of the day, working with Blue Teams, getting caught (yes! as a Red Team, you may want to get caught), training people, and testing their process. This allows organizations to make corrections and improve. Not just get smashed by a custom C2 or tool that is arguably more advanced than what is being used by many APTs and cyber criminals. A perfect example of this is over-tooling for an engagement. Over-tooling can work against providing an organization with a good threat representation.

Spectre Ops’ article on phishing campaigns is a great read and they discuss that Blue Teams were able to instantly identify a campaign as a “Red Team” because it was too advanced. It looked nothing like the threats the SOC was actually dealing with on a daily basis. The article even goes on to state that “we’re training defenders to be good at detecting and responding to Red Teams and not actual threats.” This statement isn’t limited to just phishing campaigns. It’s a problem across the entire industry.

Are You Actually Red Teaming?

For some reason, the term “Pentesting” or “Pentester” gets a negative connotation in parts of the community as a lower tier of operations. We have even personally heard some people refer to pentesters as script kiddies, painting them as operations that just run automated tools and move in. These negative connotations have led people to use “Red Team” more to refer to advanced operators rather than how the team is running, their ops, or what they are targeting for the engagement outcome. There is no reason that advanced pentest operations shouldn’t also be developing their own tools. In fact, we would argue that they should be and that pentests shouldn’t be viewed as a lower tier when they in fact, fill a crucial role in finding flaws in technical controls.

So, if pentesters can be advanced operators, what does a Red Team Op really look like? Well, they should be mapping their TTPs to match what an organization is facing. They should also operate to engagement objectives rather than focusing on achieving a network takeover or vulnerability discovery. Here is an example that we like to bring up in our Red Team Operations course. Imagine you bring in a Red Team and they focus on avoiding being detected through technical controls. So they brought in a custom tool with the latest TTPs published at a conference last week, but the customer had a major breach event two months ago initiated by a PowerShell-based payload. Even without doing the assessment, we can probably guess that the SOC won’t be successful in stopping the Red Team. More importantly, how can the Red Team provide feedback to the customer on whether the failure is in instrumentation or SOC personnel training if they are using a technique that the customer’s EDR is unlikely to pick up in the first place?

As the earlier SpectreOps quote said, we should be training defenders to detect threats, not Red Teams and as such, we should be operating as APTs do. Somewhat counterintuitively, this might mean that a Red Team needs to operate with older TTPs. At the beginning of the article, we mentioned that we have been seeing people comment about how if they operated like ATP X, their coworkers would laugh at them. But these APTs are having success with those things! According to CISA, PowerShell is still one of the most commonly used tools in advanced breaches. There was just reporting on an APT using PowerShell to successfully target a defense contractor key in developing the F-35, one of the most advanced fighters in the world. With that kind of impact and success, why is the Red Team community portraying these tactics as laughable and employing more advance TTPs that their customers likely aren’t facing outside of a Red Team engagement?

We know it doesn’t feel good to “lose,” but a “bad day” for the Red Team means that you provide training and testing opportunities for the Blue Teams. This means using older techniques and ones that might get caught, but a Red Team’s job is to train Blue Teams that are often understaffed and underfunded. We are there to improve the human factor of the organization and help identify what problems can be addressed without necessarily increasing capital funding to purchase new capabilities. A good Red Team can help an organization perform better with what they have and how to best utilize their limited budgets.

The post Why Most Red Teams are Really Pentesters appeared first on BC Security.