Before we can dive into the technical ideals behind Red Teams, I need to clarify my definitions of Penetration Testing and Red Teams.
These words get thrown around often and can get a little mixed up. For this book, I want to talk about how I will use these two terms.
Penetration Testing is the more rigorous and methodical testing of a network, application, hardware, etc. If you haven’t already, I recommend that you read the Penetration Testing Execution Standard (PTES: http://www.pentest-standard.org) – it is a great walkthrough of how to perform an assessment.
Also Read: Top Hacker’s That makes History
In short, you go through all the motions of Scoping, Intel Gathering, Vulnerability Analysis, Exploitation, Post Exploitation, and Reporting.
In the traditional network test, we usually scan for vulnerabilities, find and take advantage of an exploitable system or application, maybe do a little post exploitation, find domain admin, and write up a report.
These types of tests create a matrix of vulnerabilities, patching issues, and very actionable results. Even during the scope creation, penetration tests are very well defined, limited to a one or two-week assessment period, and are generally announced to the company’s internal security teams.
Companies still need penetration testers to be a part of their secure software development life cycle (S-SDLC).
Nowadays, even though companies have vulnerability management programs, S- SDLC programs, penetration testers, incident response teams/programs, and many of the very expensive security tools, they still get compromised.
If we look at any of the recent breaches http://www.informationisbeautiful.net/visualizations/worlds-biggest- data-breaches-hacks), we see that many of these happened to very large and mature companies.
We have seen in other security reports that some compromises could have lasted longer than 6 months before they were detected (https://en.wikipedia.org/wiki/Sony_Pictures_hack).
There are also some reports that state that almost one-third of all businesses were breached in2017 (https://www.esecurityplanet.com/network-security/almost-a-third-of-all-u.s.- businesses-were-breached-in-2017.html).
The questions I want companies to ask are if these exact same bad guys or actor sets came after your company with the exact same tactics, could you detect it, how long would it take, could you recover from it, and could you figure out exactly what they did?
This is where Red Teams come into play. The Red Team’s mission is to emulate the tactics, techniques, and procedures (TTPs) by adversaries.
The goals are to give real world and hard facts on how a company will respond, find gaps within a security program, identify skill gaps within employees, and ultimately increase their security posture.
For Red Teams, it is not as methodical as penetration tests. Since we are simulating real world events, every test can differ significantly.
Some campaigns might have a focus on getting personally identifiable information (PII) or credit cards, while others might focus on getting domain administrative control.
Speaking of domain admin, this where I see a huge difference between Penetration Tests and Red Team campaigns. For network pentests, we love getting to Domain Admin (DA) to gain access to the Domain Controller (DC) and calling it a day.
For Red Team campaigns, based on the campaign, we may ignore the DC completely. One reason for this is that we are seeing many companies placing a lot of protection around their DCs.
They might have application whitelisting, integrity monitoring, lots of IDS/IPS/HIPS rules, and even more. Since our mission is not to get caught, we need to stay low key. Another rule we follow is that we almost never run a vulnerability scan against the internal network.
How many adversaries have you seen start to perform full vulnerability scans once inside a compromised environment? This is extremely rare. Why? Vulnerability scans are very loud on the network and will most likely get caught in today’s world.
Another major difference in the scope is the timeline. With penetration tests, we are lucky to get two weeks, if not one.
Whereas, Red Teams must build campaigns that last from 2 weeks to 6 months. This is because we need to simulate real attacks, social engineering, beaconing, and more.
Lastly, the largest difference is the outcome of the two types of teams. Instead of a list of vulnerabilities, Red Team findings need to be geared more toward gaps in blue team processes, policies, tools, and skills.
In your final report, you may have some vulnerability findings that were used for the campaign, but most findings will be gaps in the security program.
Remember findings should be mainly for the security program, not IT.
| Penetration Tests | Red Teams |
| Methodical Security Assessments: -Pre-engagement Interactions -Intelligence Gathering -Vulnerability Analysis -Exploitation -Post Exploitation -Reporting | Flexible Security Assessments: -Intelligence Gathering -Initial Foothold -Persistence/Local Privilege Escalation -Local/Network Enumeration -Lateral Movement -Data Identification/Exfiltration -Domain Privilege Escalation/Dumping Hashes -Reporting |
| Scope: -Restrictive Scope -1-2 Week Engagement -Generally Announced – Identify vulnerabilities | Scope: -No Rules* -1 Week – 6 Month Engagement -No announcement -Test Blue teams on program, policies, tools, and skills *Can’t be illegal… |
With Red Teams, we need to show value back to the company. It isn’t about the number of total vulnerability counts or criticality of individual vulnerabilities; it is about proving how the security program is running.
The goal of the Red Team is to simulate real world events that we can track. Two strong metrics that evolve from these campaigns are Time To Detect (TTD) and Time To Mitigate (TTM). These are not new concepts, but still valuable ones for Red Teams
What does Time To Detect (TTD) mean? It is the time between the initial occurrence of the incident to when an analyst detects and starts working on the incident.
Let’s say you have a social engineering email and the user executes malware on their system.
Even though their AV, host-based security system, or monitoring tools might trigger, the time recorded is when the analyst creates that first ticket.
Time To Mitigate (TTM) is the secondary metric to record. This timeline is recorded when the firewall block, DNS sinkhole, or network isolation is implemented.
The other valuable information to record is how the Security Teams work with IT, how management handles a critical incident, and if employees panic.
Ref: Source Hackers Playbook
With all this data, we can build real numbers on how much your company is at risk, or how likely it is to be compromised.
