Blog: Red Teaming

Learning from Red Team engagements

Ben Ruffell 02 Sep 2019

An organisation’s defences tend to be split into three different categories, these are:

  • Prevention
  • Detection
  • Response

The prevention would be via common security measures, such as an e-mail filtering system, or restricting access to applications including command prompt and powershell.

The detection looks at anything that has slipped past the prevention measures, be it by anti-virus flagging an item, or a SoC noticing odd behaviour on the network.

This detection then needs to be coupled with a quick response, to take action to resolve the issue that has been flagged. This response is where we regularly see issue with companies taking up to 2 days to respond to an issue that has been flagged.

Each item of the Att&ck framework can be split into these three categories and looked at individually to provide a full assessment of the security posture of the business, from initial access to feet on the ground actively responding to threats.

Here’s an example of how that can look in reporting:

With these examples I’m not trying to trumpet how ‘clever’ Red Teaming and Purple Teaming is, it’s more to show how the DPR process can be used to see that even when one or two of those three are weak or even missing it’s possible to put up a good defence.

Using that learning will then help inform how to bolster and improve everything else, efficiently and with your real-world experience and knowledge.

Example no. 1

Pen Test Partners Red Team were busy compromising a market data organisation.

The value of a Red Team is obviously in the implementations made after the engagement to improve, primarily, the detect control layer of the organisation.

So on our daily call with the white team, they asked us to use some more noisy techniques to see if these could be picked up.

And, as anticipated, they did pick it up. Or at least, their EDR did.

The problem was the response latency – the process.

The technology was doing it’s part, but once the EDR flagged an alert, it took the orgniasation 2 days to triage and escalate.

This is where the value of the engagement was delivered.

If the leaked Conti Ransomware Manual has taught us anything, it is that ransomware gangs and their affiliates endorse noisy techniques that enable them to achieve their goal, even if they know that they know are going to be picked up by an EDR.

Which says to me that they have had success dong it in the past, most likely because of the problem we discovered – that alerts simply do not get acted on in a timely enough fashion.

That’s why Red Team engagements can deliver value to an organisation – you can improve processes so that people, process, tech are all aligned to maximise resilience to attacks from capable attackers.

What was learned?


Example no. 2

As ever, password security is an ongoing challenge for organisations and often a source of compromise during our red team exercises.

One of the common issues is a static password created for a new starter, or during a password reset in the event of a forgotten password.

If no enforced change is required by the user after first use of that new password, it’s very common for it to be left.

I was blown away to hear from one of our red team operators that a password of ‘Winter2020’ had been guessed on a public OWA instance.

The user had started a few months prior and not changed their password, as they hadn’t been forced to.

That password had been used for all new starters in the 3 month winter period.

That OWA account compromise was the start of a complete ‘breach’ of the organisation.

During another red team exercise, a CISOs domain password was cracked.

It simply wasn’t long or complex enough, despite complying with the relatively strong complexity requirements set on the domain.

What was learned?



Make your adversarie life harder by:

  • Enforcing password changes for new starters and after resets
  • Not setting static passwords for new starters, ‘Welcome1’ or similar being very common. Set a unique password
  • Using MFA to help mitigate against weak passwords, but do beware of social engineering for those token values
  • Biometric authentication has potential for domain authentication, though watch out for weak backup PINs and the requirement for a TPM