Anatomy Of A Red Team Exercise

What is a Red Team exercise? If you ask that question to 10 people in the cybersecurity business, you will get 10 different answers. The most succinct definition of a red team exercise and how it plays out in the field with organisations is as follows: ‘An adversarial simulation that allows organisations to detect and respond to targeted attacks.’

Learnings span the gamut from detecting a breach to stopping it, investigating it and preventing future breaches.  The first goal of a red team is to look at people and technology controls in the organisation throughout the exercise.

A secondary goal is to allow organisations to tailor their solutions to real world attacks; it helps them identify their crown jewels and the path that attackers will take to get to them.  For organisations, this might mean optimised use of security solutions they already have, so they are better prepared to defend against real attacks.

Practical examples are always helpful in understanding how such concepts play out in real life. To better outline and explain the approach and outcomes of a red team exercise, let’s imagine a scenario with a customer referred to as AnonCorp.

AnonCorp is a mature organisation that invests multiple millions of dollars in security, much of it in perimeter and endpoint. They migrated most of their most sensitive data – their crown jewels – to the public cloud as they moved to a DevOps methodology, pushing code to production. The crown jewels in question were financial records, HR records and customer details.

They wanted to simulate a situation where an adversary would try to breach their public cloud infrastructure to gain access to these crown jewels. On this occasion, AnonCorp insisted the red team start from scratch, completely from the outside. Most organisations start with the assumption of a breach – a foothold within the infrastructure – and go from there.

The red team started with phishing, cloning their email portal. A few of their employees inputted their credentials into the phishing site.  The red team then used those credentials to get code execution externally on their machines via their Outlook profiles.

So, at this point the red team are inside their network, albeit limited in where they can go and what they can access. To counter this, the first thing they did was collect information from within Active Directory. What privileged accounts exist? Who has what type of access within the organisation? What are these privileged accounts currently connected to?

They found that the compromised credentials on one of the machines they got into initially were shared on other machines in the network, so they were able to move laterally to these machines. One of them was an IT staffer’s workstation and on this they found a domain admin account. In other on-premises organisations this might be a ‘game-over’ situation, because at this point the red team had the ability to compromise any other machine in the network and access any crown jewels they have.

The organisation of course, had migrated all their crown jewels to the cloud, or at least the ones the red team were tasked to access.  The problem, then, became how they could pivot from the on-premises access they had achieved to the public cloud infrastructure.

Using newly-acquired domain admin privileges, the red team decided to go after the developers. They used native remote access to execute ‘malware’ on the machine of a DevOps engineer. On the machine they found a remote connection tool used to connect to a remote server – one in the cloud infrastructure. They also found privileged access in the shape of an SSH key stored locally on the machine. They took the SSH key and used it to connect a single machine in the organisation’s public cloud.

They still didn’t have the crown jewels but had proved that they can pivot to the cloud. What would they find there? This quote, from Chris Hoff of Bank of America Merrill Lynch, provides a clue:

“If your security sucks now, you will be pleasantly surprised by the lack of change when you move to the cloud.”

 Cloud providers allow customers to assign certain privileges to cloud resources by creating an identity with specific set of permissions and assign it to different resources. This allows, for instance, a machine to communicate with a storage device. However, those privileges are stored as cloud native API keys, able to be retrieved by any user with almost any level of access to operation system of machine. Assigning the right level of privilege to the identity is therefore crucial.

The red team used their access to that single machine to retrieve those cloud APIs. This gave them full control over the environment and access to our objective. They backed up and copied every single server that AnonCorp owned – 375 of them – and attached them to a new account that they had created with the same public cloud provider.

The organisation didn’t even know that their environment got stolen.

All that was required to copy their whole environment was access to a single server with the right API access.

The misuse of privilege runs throughout the engagement, from the initial compromised machine that allowed us to eventually find a domain-wide privileged account, which in turn allowed the red team to jump to the cloud and finally to use an over-privileged cloud native API to access and copy the whole cloud environment.

How could they have been stopped? At the outset, enforcing least privilege on the initial compromised machine – on all endpoints, in fact – would have contained the red team. Using the same privileged credentials in the on-premises environment meant they could move laterally; this should not be the case. SSH keys stored on the user machine allowed them to make the jump from on premise infrastructure to cloud environment. Finally, cloud API keys were set with unrestricted access with allowed us to take control over the entire cloud infrastructure. Securing these is not the responsibility of the cloud provider; the same rigour applied to on-premises security must also applied to the cloud environment, treating it as extension to the existing environment not something separate that someone else should secure. It’s your data, secure it properly.

Privilege will continue to play a role in nearly every attack scenario, whether the goal is to spread a crypto miner bot, to exfiltrate proprietary data or to steal money from company accounts. Privilege will always be sought after in order to execute these attacks and Red Team exercises help organisations understand this better.