Red team diaries: Post-engagement

I’m a red teamer, hired to help my clients understand their own readiness to prevent, detect, and respond to targeted attacks focused on cyber attacks, physical attacks or both. Over the last three days I had broken into my client’s office, stolen a laptop, and penetrated their environment to steal valuable intellectual property.

Wrapping up

My team reconvened on Monday for a short post-mortem. We discussed the tactics, techniques, and procedures that we used and why we used them. We reflected on the indicators of compromise that the client’s security team could have been monitoring for. These, we hypothesized, could have stopped the attack progressing or at least would have given away some aspects of the attack that would have allowed detection by the defenders (otherwise called the blue team). However detection is only the first step; knowing what to do, as well as when and how to do it, is a crucial part of containing a targeted attack and limiting its impact.

Our recommendations were pragmatic and empathetic. We aimed to provide short- and long-term defensive measures that would buy the client time to tackle the deeper root causes and potential mitigation paths for detecting and containing similar attacks. We made sure to discuss the potential impacts of the proposed changes on the day-to-day use of IT systems and the company culture; cyber security is about people and the processes they follow as much as it is about technology.

Results workshop

The following day, I sat at a large glass table with the client’s white and blue teams (who were in charge of refereeing the engagement and defending the environment, respectively). Another red teamer had joined me to provide additional thoughts on the outcome of the test. Although I was excited to share the findings of the engagement, I understood the gravity with which they would reach the ears of the attendees.

Walking through the attack scenarios in detail, I explained every technical action and decision, inviting questions as I went.

The client asked some good questions, including some that we get in almost every workshop. They asked:

How did we perform compared to other organizations in our sector?
What was your plan B if your techniques had not worked?
Where do you think our strengths lie?
What did we do defensively that slowed you down or made you concerned about being detected?
What would you choose as your primary target if you were to run another engagement?
Are our physical security and network security teams collaborating?
Is our cyber security department collaborating with our network department?
Are our third-party products increasing our risk?
Did our security products stop you or slow you down?
Did you notice a security culture or a sense of shared responsibility among our colleagues?

I answered these questions fully while describing my general approach to the attack narrative, including the attack paths I took, the obstacles I observed and how they were circumvented, and how each attack was performed and structured.

Recommendation

Make the most of having your consultants in the room with you. Ask how the recommendations they are making will affect your business, including how long they will take to implement and what the next targets should be.

Ensure you leave the meeting with a good understanding of where the real root causes lie when it comes to the things the red team saw and experienced.

Ultimately, every technical vulnerability is a process problem. So ask questions that are focused on how processes can change to increase resilience against targeted attacks.

This was followed by a deep-dive analysis of the attacks I’d prepared but not attempted (and thus could be input for a follow-up simulation or remediation project, should there be a risk of exploitation). I presented my analysis of the client’s security posture and awareness, as well as observations of the actions taken by the blue team around detection, containment, and the time frames in which responses were received.

A strong overall security posture is one in which security controls are working with each other and not against each other. We look for a culture of security, where best practices are considered and defensive actions are based on accurate information and well-defined priorities.

Finally, we gave an overview of remaining attack artefacts, including what data was accessed and where, how the data was kept safe and secure during and after the test, and how the anonymity of individual employees or departments had been upheld.

Some of the findings we discussed immediately gained traction, and several good ideas were put forward as solutions to the problems we had identified, including:

Removing the availability of certain services and ensuring they can only be used after a VPN connection had been established on internal networks as well as internet facing hosts and services
Ensuring that successful access attempts are logged and acted upon as much as unsuccessful ones
Setting up network security controls inside the building in a way where a breach is assumed and where your physical location (such as meeting rooms, the CEO’s office, or the IT administrators’ department) does not automatically dictate your network or application privileges
Enabling multi-factor authentication for internal and relevant services
Ensuring that application servers and virtualization services are segregated as much as possible based on risk and threat modelling.

Some of our other findings, however, were less well received. Some post-engagement briefings can involve heated conversations, especially when there is political tension within the client organization. It’s not every day you experience a targeted attack simulation that shows just how disastrous a real attack can be. But ultimately, it’s my job to align the room behind a common goal, because improving the client’s security posture is always a team effort.

The workshop became increasingly collaborative as we progressed, with everyone at the table talking through the indicators of compromise that could have been identified, what measures could be built for future detection, and where the client could create additional strategic detection choke points to obtain greater transparency across network activity.

Red teamer job satisfaction comes from everyone learning from each other, where everyone’s daily work and lives become a little bit easier, and when everyone can focus on relevant threats and what it takes to reduce risk while helping the organization grow.

Recommendation

Not every recommendation is fit for every organization; there are many paths towards lowering risk, so make sure you get tailored recommendations from your consultant and understand how they address your specific needs while understanding the impact those recommendations will have on your technical landscape and the company culture.

My timeline of events was compared with the client’s, and all measures and tactics were debated in the context of the organization’s risk appetite, technical roadmap, and upcoming developments in the business.

Final thoughts

Whatever a client expects from the results, the outcome of a red team engagement is never ‘pass’ or ‘fail’. It’s a stress test designed to highlight how much control is really present across the organization and how fast a targeted attack can be detected and contained, and the attacker eradicated. The only way to really understand your own security posture is to perform these stress tests regularly so that you can compare your results over time.

Red teaming provides a unique opportunity to test critical assets in production, as well as how well security controls, training and processes can work together to defend your business so that a breach, downtime or ransomware attack can ultimately be just another Tuesday and not a newspaper headline with long term impact.