Understanding the rhythm of the business and planning Red Team operations

When I first became a manager and led an offensive security team, I was extremely lucky to have an experienced, yet humble, partner at the company to be my manager and mentor. In the past, he had managed a large test organization that shipped a flagship product of our organization with consistently outstanding quality, and he was directly responsible for the quality of what eventually became an 8+ billion-dollar business.

Besides countless stories and analogies he shared with me about people management and software testing, he also helped me understand what it means to run an offensive security team through the angle of running a business.

I'm certain most of you have not looked at it that way, but, as a manager, it's critical to think about managing a budget, demonstrating impact, and justifying the existence of the team and program. If you have a team with a handful of offensive security engineers, you are running a business that is worth beyond a million dollars annually. Exciting, right? So, roll up your sleeves, get the team together, and highlight those areas and deficiencies in the organization that need investments to improve and put everything into a more secure state.

Planning cycles

It's beneficial to create a rough plan for the upcoming months and align it with other business verticals to ensure offensive investments and operations provide valuable improvements to the organization. Keeping the independence and freedom to change priorities is critical and will occur regularly. At times, other stakeholders might have great ideas or actively seek help. The manager of the offensive program must stay in touch with various business stakeholders and, ideally, have recurring meetings to stay in touch and learn about changes to systems, organization, and business.

As a manager, you have to deal with justifying investments and providing insights if more or fewer resources are required to fulfill the business objectives. A key aspect to fulfill this is to find somewhat meaningful ways to measure investments and returns.

Offsites

A great way to spec out a planning document for an upcoming cycle is to perform an offsite with the team. This improves the collaboration and coherence of the team and helps rally everyone behind the mission. I found that regular offsites to get the team together are invaluable. An offsite does not imply that you must travel far or spend a bunch of money. If your company has multiple buildings, just book a meeting room for a couple of hours in a different building. The idea is to not be in the same environment or follow the same routine that you do every day. If your organization can afford something fancier, that's also great – but it's not necessary. However, do try to get management to pay for lunch.

As a manager, build a high-level structure around offsites. There are a few goals to consider. Let's go over them now.

Improving team coherence and identity

It is good to kick off an offsite with a simple game that everyone participates in and that breaks the ice. It allows team building and gets their mind off the regular workday. The winner gets to decide where the team eats lunch!

Sharing information

One part of the offsite is that everyone should share some challenge related to people, a process, or technology that they learned about recently. This can be an example of how someone developed a complex exploit for a buffer overflow, or maybe a summary of a recent security conference, and things along those lines. The goal is that everyone shares some new information.

Sharing a new external tool or technique that can help others is another great way to encourage information sharing and ignite some new ideas for better tools or to improve existing ones.

Brainstorming ideas for the future

The goal is to develop strategies and an understanding of what to do in the next planning cycle. For example, an outcome that I witnessed once was that the offensive security team should revisit every single defect that was opened and then closed in the past 12 months, to validate if the issue was indeed addressed.

Also consider brainstorming around tools and attacks that your team might want to develop and build out for future operations, possibly based on the information that was shared from the information-sharing sessions. Other areas should be explored to ensure that the mission of the team is still accurate.

Wrapping up offsite sessions early!

To leave an overall positive feeling behind (which an offsite usually has anyway) is by trying to end early, although my personal experience has been mostly that individuals are so passionate about ideas and brainstorming, and how processes and systems could be improved, that time usually runs out.

The result of the offsite will be a short planning document that can be shared with leadership and guide your team over the next couple of cycles

Encouraging diverse ideas and avoiding groupthink

A great story is told in the book Red Team – How to succeed by thinking like the enemy from Micah Zenko around Weighted Anonymous Feedback. The basic idea behind this is to hand out cards to the team and ask participants to write down three ideas. Then, you collect the cards, shuffle them, and hand them out to the participants again. Afterward, ask them to give points to the suggestions on their card. Finally, aggregate all the ideas and present the results. The story told in Micah Zenko's book highlighted that, in their particular case, not a single idea from the most senior members were chosen or awarded high points. All the ideas that were ranked highly were those of the most junior participants.

Planning operations – focus on objectives

There are different ways to approach planning for future engagements and operations. For pure red team-based engagements, it makes sense to brainstorm around specific objectives to achieve, such as gaining access to secure environments such as PCI boundaries. The following are some examples of how to structure thinking about objective-driven planning.

Impacting system availability

One objective of adversarial behavior is to impact system availability. This is done in a concerted fashion via orchestrated distributed denial-of-service attacks, or by targeted app-level vulnerabilities and weaknesses that denial-of-service (DOS) applications have with a limited amount of effort by an adversary.

Some offensive teams explicitly scope DOS testing out of their objectives. Denial-of-service itself, especially when it comes to load testing, is technically a performance problem, and its implications to the business are probably one of the most substantial ones. No service, no business. So, getting this kind of testing on the radar beyond pure load testing but from an adversarial view is recommended.

You might even go as far as to think that a data breach is less impactful to the bottom line of a business compared to availability issues.

Simulating data/system deletion

Along the lines of denial-of-service is also the threat of data loss an organization must entertain. This includes intentional malicious activity but can also help protect from human mistakes. You must validate and ensure that backups are in place and can be restored quickly. A test like this is a great candidate for a table-top exercise.

Data exfiltration

With the advent of General Data Protection Regulation (GDPR), which puts big fines on organizations for mishandling customer data, testing your data exfiltration detections and prevention tactics are important. Multiple companies in the United States, for instance, have lost sensitive customer information about millions of citizens without any financial implications for the companies involved.

The goal for an offensive operation in this regard is to evaluate and perform direct exfiltration but also indirect exfiltration via proxies and unexpected protocols.

Ransomware

The most famous example of this threat was the WannaCry ransomware, which automatically spread a vulnerability in the SMB protocol on Windows machines and encrypted data to hold victims ransom and demand payment of cryptocurrency to unlock the data again.

Throughout the last few years, ransomware has become a common threat in the industry, and being prepared and emulating such attacks should be on the agenda of every organization.

Cryptocurrency mining

Crypto jacking is a rising threat that many organizations are victims of. Attacks can range from browser-based scripts that employees surf to, employees using company resources (computers and electricity), or employees being compromised externally. A crypto jacking operation can validate detections for miners in your organization. There is more information on how to run such operations in Chapter 4, Progressive Red Teaming Operations. This can also be used to measure the red team's persistence and power by looking at the acquired hash rate over time.

Testing for account takeovers and other client-side attacks

Depending on the business model of your organization, it might also be that an adversary is not directly targeting your business but is targeting your clients. A vulnerability such as Cross Site Scripting might be exploited by an adversary by targeting certain customers directly. Such an operation might be focused on identifying application-level flaws, as well as weak password policy enforcements and similar threats. In a large organization, these attacks can sometimes be simulated end to end by targeted internal users/clients of the system. Targeting external customers will certainly violate rules of engagements and laws.

Planning operations - focus on assets

Another way to tackle threat simulation is by brainstorming around what assets are the most valuable in the organization and plan operations by asset types. For instance, an operation might focus on all Jumpboxes or all security cameras in the company. Another approach is to give special attention to a particular service or business vertical.

Another idea here is to run operations that focus on software or hardware provided by third parties to help mitigate and/or emulate the threat of a compromised supply chain.

Planning operations - focus on vulnerabilities

The Open Source Security Testing Methodology Manual (OSSTMM) and Open Web Application Security Project (OWASP) have great and comprehensive lists on vulnerabilities and methodologies. There's no need to repeat them all, but the following links are for your reference:

One category worth highlighting, however, is business logic flaws. Static and dynamic analysis are often not capable of finding business-specific issues. There might be vulnerabilities that require a more complex sequence of steps in a workflow to modify state and lead to unexpected outcomes. Manual code inspection or testing are the only ways to identify some of them.

Planning operations – focus on attack tactics, techniques, and procedures

These operations are often focused on close collaboration with the blue team to improve detections for each TTP. These are ideal candidates for purple teaming, where red and blue collaborate with each other as well. These operations can also be done in small chunks, which allows better planning as it involves cross organization collaboration.

Frameworks such as MITRE's Common Attack Pattern Enumeration and Classification (CAPEC) as well as ATT&CK™, can help approach such testing in a structured manner. We will cover the ATT&CK framework a bit closer in in the Tools and Techniques section of this book.

For reference, you can find more information here:

Planning operations – focus on STRIDE

If you have done threat modeling before, it's likely that you ran across or used the STRIDE framework, which helps brainstorm threats. As far as I know, STRIDE was created in the late 90s by Microsoft. It defines possible threats to be as follows:

  • Spoofing
  • Tampering
  • Repudiation
  • Information disclosure
  • Denial of service
  • Elevation of privilege

Given these categories, brainstorming sessions can lead to great ideas for red teaming operations with a focus on a particular STRIDE class. More information about STRIDE can be found here: https://cloudblogs.microsoft.com/microsoftsecure/2007/09/11/stride-chart/.

Spoofing

A spoofing operation could be as simple as a phishing campaign to steal passwords and two-factor authentication tokens from employees.

Tampering

Tampering (as well as denial-of-service) is tricky, as it needs to be performed in a very controlled fashion and typically needs special authorization to avoid business impact. For tampering, you could add a cryptographic string in the comments of HTML pages or use a predefined red team string pattern that highlights that the target data was indeed modified in a non-malicious way.

Repudiation

Most interesting of them all might be repudiation, which is not well understood. Repudiation threats frequently revolve around lack of auditing, and forensic capabilities that need to be tested and validated.

A good example of a repudiation operation would be to compromise developers and subsequently perform code check-ins on their behalf to see if anyone notices any changes. Similarly, in the real world, a developer might, at one point, claim that a given change was not actually performed by them. So, what is the truth? Can the blue team figure out who is, in fact, responsible for the check-in?

Information disclosure

One idea for an offensive security operation that focuses on information disclosure rather than compromising things is to look for sensitive information in places that are widely accessible. For instance, are there secrets in the source code? Is there any customer Personal Identifiable Information accidently being exposed on the intranet that shouldn't be?

Another area, of course, is to understand if there are any services being exposed that do not leverage encryption and enable an adversary to sniff the network traffic easily.

DOS

Targeted and authorized DOS testing is something that needs to be assessed. Availability is one of the key pillars for any business and understanding how easy or difficult it is for an adversary to cause service disruption can help with future investments to improve performance and scalability.

Elevation of privilege

For elevation of privilege, the focus might be to find clear text credentials of valuable administrative accounts or to focus on remote code execution via lack of patching across all machines on the network. The focus might not be limited to administrative permissions; for instance, identifying misconfiguration where accounts that should have read permissions are able to write data can be of interest.

In Part II of this book, there will be an exhaustive chapter around hunting for credentials!

上一章目录下一章