What Red Teaming Actually Means
Red teaming is a simulated attack against your organization that tests your defences the way a real adversary would. Unlike a penetration test, which focuses on finding as many vulnerabilities as possible in a defined scope, a red team engagement has a specific objective. Steal the CEO’s email. Exfiltrate customer records. Gain access to the production database. The red team then uses whatever combination of techniques will get them there.
This includes tactics most penetration tests never touch. Phishing employees with custom pretexts. Calling the help desk to social engineer a password reset. Dropping USB devices in the parking lot. Chaining a low-severity web vulnerability with an internal misconfiguration to reach a domain controller. Red teaming tests the full kill chain, from initial access to objective completion.
The concept comes from military war gaming, where a “red team” plays the enemy force to expose weaknesses in plans and defences. In cybersecurity, the principle is the same: put your security program under realistic pressure and see what breaks.
How Red Teaming Differs from Penetration Testing
People use these terms interchangeably. They shouldn’t. The differences affect what you learn, what you spend, and how you should use the results.
| Penetration Testing | Red Teaming | |
|---|---|---|
| Goal | Find as many vulnerabilities as possible within scope | Achieve a specific objective while testing detection |
| Scope | Defined targets (a web app, a network range, a cloud environment) | The entire organization, or agreed-upon exclusions only |
| Duration | 1-3 weeks typically | 4-8 weeks or longer |
| Stealth | Not a priority. Testers may be noisy | Core requirement. Simulating real attacker behaviour |
| Techniques | Technical exploitation, configuration review | Technical exploitation, social engineering, physical access, custom tooling |
| Who knows | IT and security teams are fully aware | Limited to a small group. Most staff don’t know it’s happening |
| Output | Vulnerability list with severity ratings and remediation steps | Narrative of attack paths, detection gaps, and response evaluation |
| Tests what | Technical controls | Technical controls, detection capability, incident response, security culture |
A penetration test answers: “Where are we vulnerable?” A red team engagement answers: “Can an attacker actually compromise us, and would we catch them trying?”
Both have value. They answer different questions.
What a Red Team Engagement Looks Like
Red team engagements follow a progression that mirrors how real attackers operate. Each phase builds on the last.
Reconnaissance
The team starts by gathering information about your organization without touching your systems directly. LinkedIn profiles of employees and their roles. Technology stacks mentioned in job postings. Subdomain enumeration. Email address patterns. Leaked credentials in breach databases. Office locations and physical security details visible from public sources.
This phase can take a week or more. Real attackers spend time here, and so does a good red team.
Initial Access
Using what they learned in recon, the team attempts to gain a foothold. This might be a spear phishing email crafted for a specific employee, exploiting a vulnerability on an internet-facing system, or social engineering someone on the phone.
The initial access vector depends on what’s most realistic for your threat profile. If your organization’s biggest risk is spear phishing from a motivated adversary, that’s where the test should start. If you’ve already established that phishing awareness is strong, the team might focus on technical entry points instead.
Post-Exploitation and Lateral Movement
Once inside, the red team works to expand their access. They move laterally through the network, escalate privileges, and work toward the agreed-upon objective. This phase tests your internal segmentation, Active Directory security, endpoint detection, and monitoring coverage.
The red team operates with the same constraints a real attacker faces: limited initial access, need to avoid detection, patience to find the right path forward. They’re not running every exploit in the book. They’re picking the path of least resistance toward the objective.
Objective Completion
The engagement reaches its conclusion when the red team either achieves the objective or exhausts their allotted time without getting there. Both outcomes are useful. If they reach the objective, you know exactly what failed and where. If they don’t, you learn which controls held up and what slowed them down.
Reporting and Debrief
The final report reads like a story, not a spreadsheet. It walks through each phase: what the team did, what worked, what was detected, and what wasn’t. Detection gaps get as much attention as technical vulnerabilities, because a vulnerability your SOC catches and responds to is far less dangerous than one they miss entirely.
The debrief typically includes the security team, IT leadership, and sometimes executive stakeholders. Purple team sessions, where the red team walks through their actions with the blue team watching the corresponding logs and alerts, are one of the most valuable parts of the engagement.
When You Need Red Teaming vs Penetration Testing
Red teaming isn’t for everyone, and that’s fine. Start with penetration testing.
If you haven’t had a penetration test in the past year, you’re not ready for a red team. You need to find and fix the obvious vulnerabilities first. Running a red team engagement against an environment full of unpatched systems and default credentials is a waste of money. The red team will walk right in, and you won’t learn anything you couldn’t have found with a standard penetration test.
Red teaming makes sense when:
- You’ve been doing regular penetration testing and have addressed the major findings
- You have a security operations capability (SOC, SIEM, EDR) that you want to validate
- Your threat model includes sophisticated adversaries like nation-state groups or organized crime
- You need to test incident response procedures under realistic conditions
- Executive leadership wants to understand real-world risk, not just a list of CVEs
- Your industry has regulatory expectations around adversary simulation, such as financial services or critical infrastructure
If you’re earlier in your security maturity, put the budget toward external and internal network penetration testing, web application testing, and a phishing engagement. These give you more actionable findings per dollar at that stage.
Common Red Team Attack Paths
Every environment is different, but patterns emerge. Here are attack paths red teams use repeatedly because they keep working.
Phishing to Domain Admin
A spear phishing email delivers a payload to a single employee. The payload establishes command and control. From the compromised workstation, the team discovers cached credentials or Kerberos tickets. They use those to move laterally to a server with a domain admin session. Game over.
This path works because organizations invest heavily in perimeter security but leave internal networks relatively flat. Once past the email gateway, the path from one workstation to domain admin is often disturbingly short.
Help Desk Social Engineering
The red team calls the IT help desk posing as an employee who can’t access their account. With enough background detail from LinkedIn and corporate website reconnaissance, they convince the help desk to reset a password or disable MFA. Now they have valid credentials and walk through the front door.
Cloud Misconfiguration Chain
A forgotten staging environment in AWS has an S3 bucket with overly broad permissions. The bucket contains configuration files with database credentials. Those credentials work on the production database because the staging environment was cloned from prod and nobody rotated the secrets.
This one shows up constantly since the shift to cloud. Credentials and secrets scattered across cloud environments are one of the most common red team findings.
Physical Access
In organizations where physical security is in scope, the red team may tailgate into an office, find an unlocked workstation, and plug in a device that gives them network access. Or they find a network jack in a conference room that lands them on the corporate VLAN with no authentication required.
Organizations with strong digital security often have surprisingly weak physical controls. A locked server room doesn’t help if the network drop in the lobby puts you on the same subnet.
The Blue Team’s Role
The offensive side of red teaming gets most of the attention, but the defensive evaluation matters just as much.
Your blue team (SOC analysts, incident responders, detection engineers, security operations staff) should be evaluated throughout the engagement. Did they detect the phishing email? Did they notice lateral movement? When the red team triggered an alert, how quickly did the team investigate? Did they escalate appropriately?
The best red team engagements end with a purple team exercise. The red team replays their attack timeline alongside the blue team’s detection logs. Every action gets mapped: was it detected? If yes, was it investigated? If investigated, was the response correct? If not detected, why not? Missing log source? Alert rule gap? Alert fatigue causing analysts to miss it?
This purple team phase turns the engagement from a pass/fail exercise into a training opportunity. Your SOC analysts get to see real attack techniques against their own environment, with the red team explaining their decision-making at each step.
How to Scope a Red Team Engagement
Getting the scope right determines whether you get useful results or an expensive exercise with limited takeaways.
Define Clear Objectives
“Test our security” is not an objective. Good objectives are specific and tied to real business risk:
- Can an external attacker gain access to the customer database?
- Can a phishing attack lead to unauthorized wire transfers?
- Can an attacker reach the production environment from the corporate network?
- Would our SOC detect and respond to a targeted attack within 24 hours?
Set Rules of Engagement
Agree in advance on what’s in and out of bounds. Can the red team phish any employee, or only certain departments? Is physical access testing included? Are production systems fair game, or should the team avoid anything that could cause an outage? What about third-party systems?
Clear rules of engagement protect both sides. The red team knows their boundaries, and your organization avoids unexpected disruption.
Decide Who Knows
Most red team engagements operate on a “need to know” basis. Executive sponsors and a small trusted group know it’s happening. The SOC and IT teams don’t. This tests whether your detection and response works under realistic conditions.
Some organizations run “announced” red team engagements where the blue team knows an exercise is underway but doesn’t know the timing or methods. This works well for organizations new to red teaming who want to reduce risk while still testing detection capabilities.
How DarkPoint Approaches Red Team Engagements
DarkPoint Security runs red team engagements that simulate real-world adversaries against Canadian organizations. Our approach covers the full attack chain: reconnaissance, social engineering including phishing campaigns and phone pretexts, technical exploitation of external and internal networks, web applications, and cloud environments. Physical penetration testing is available when physical access is in scope.
Every engagement includes purple team sessions where our team works directly with your defenders to review the attack timeline, identify detection gaps, and build better alert rules. Findings are mapped to the MITRE ATT&CK framework so you can track your detection coverage against known adversary techniques.
We also include complimentary remediation retesting. After your team addresses the findings, we re-test to confirm the fixes work.
If you’re not sure whether your organization is ready for a red team engagement, we can help you figure that out. Many clients start with a penetration test and move to red teaming once they’ve built up their security operations capability. Our guide to choosing a penetration testing company covers what to look for in a provider for either type of engagement.
Ready to find out how your defences hold up against a realistic attack? Contact us to discuss a red team engagement scoped to your organization’s threat profile.