Red Team
Engagements
An adversary with one stated objective works your application, identity and cloud layers. Your team is not told it is happening.
A penetration test tells you what is broken. This tells you what your detection did about it: what was logged, what alerted, who acted, and how long each took.
What you are buying
A simulation of one specific adversary. Instead of enumerating a system, we pick a goal and pursue it by whatever route the rules of engagement permit, staying quiet for as long as we can.
Coverage is deliberately incomplete. A red team finds one path and takes it. If your question is "what is wrong with this application" rather than "would we notice", a penetration test returns more per unit of budget.
Scope is application, identity and cloud. Physical intrusion is outside it, and endpoint-evasion tradecraft against a mature EDR deployment is not sold here as a headline capability. Where an objective depends on either, that gets said during scoping rather than after.
What gets measured
- → Whether the activity was logged at all
- → Whether logging produced an alert
- → Whether the alert was actioned or dismissed
- → Time from action to detection to containment
- → Whether containment actually removed our access
Example objectives
- → Read one record from the production customer store
- → Obtain a valid administrative session
- → Reach the source repository or artifact registry
- → Establish persistence that survives 14 days
- → Move from a development account into production
Techniques on the table
Every technique below needs written authorization. Anything not listed in the rules of engagement is not used.
Initial access
- →Exploitation of internet-facing applications and APIs
- →Credential stuffing and password spraying against exposed auth
- →Authentication bypass in SSO, OAuth, and token issuance
- →Exposed CI/CD, admin, and management interfaces
- →Credentials and keys recovered from public sources
- →Credential phishing, where authorized in writing
Identity and privilege
- →IAM role and policy escalation paths
- →Service account and machine identity abuse
- →Token theft, replay, and scope confusion
- →Session and refresh token lifecycle abuse
- →Cross-account and cross-subscription trust abuse
- →Secrets reachable from a compromised workload
Lateral movement
- →Pivoting through compromised application hosts
- →Reuse of credentials recovered in transit
- →Movement between environments: dev to staging to production
- →Container and orchestration escape paths
- →Internal service exploitation behind the perimeter
- →Data store access from an application foothold
Persistence
- →Cloud persistence via IAM keys, roles, and trust policies
- →Application-layer implants and web shells
- →OAuth application and API key persistence
- →Scheduled workload and pipeline persistence
- →Backdoored deployment paths
Objective actions
- →Demonstrated reach to production data stores
- →Source repository and artifact registry access
- →Document and mailbox access
- →Egress path validation without exfiltrating real data
Not in scope, stated plainly
Physical intrusion, destructive action, denial of service, and exfiltration of real customer data are never performed. Social engineering against employees is only in scope with explicit written authorization covering legal and HR.
How it runs
Steps 03 through 05 loop. A blocked path returns to step 03 with what we learned. A detected action returns to step 06.
01
Set the objective
The adversary goal is stated as an outcome, not a system: read a record from the production customer store, obtain a valid administrative session, reach the artifact registry. Vague objectives produce vague reports. Then boundaries, prohibited actions, windows, and who inside your organization is deliberately not told.
Output: Written objective set, signed rules of engagement, and named safety contacts.
02
Collect intelligence
Exposed infrastructure, technology in use, third-party dependencies, identity provider configuration, credentials already public. Agents collect across more sources than a person could work through. Ranking the entry candidates is a human call. Nothing here touches your systems, so nothing here will alert you.
Output: External surface picture with entry candidates ranked.
03
Get in
Attempts against the ranked candidates until a foothold exists or the surface is exhausted. Failed attempts are recorded as carefully as successful ones. A vector that failed because a control worked is a result worth having.
Output: Access attempt log: what was tried, what worked, what stopped us.
04
Escalate and move
Privilege escalation, credential recovery, movement across trust boundaries. Actions are timed to a realistic operational tempo rather than rushed, because detection that only fires on speed is not detection.
Output: Attack path graph from entry point to current position.
05
Stay and finish
Access is held using techniques appropriate to the emulated adversary, which is the phase that most reliably surfaces logging gaps. The objective is then demonstrated and stopped: a screenshot, a record count, a hash, a timestamp. Nothing is exfiltrated and nothing is left behind after cleanup.
Output: Persistence record, and an evidence package per objective with the timestamp it was reached.
06
Measure the defence
At agreed points we escalate deliberately to see what fires. Where activity went unnoticed, we go back through your logs with you to establish whether the data was absent, present but unmonitored, or alerted and dismissed. Then the report, the debrief, and a retest once detections change.
Output: Detection timeline per action (logged, alerted, actioned, and how long each took), ATT&CK mapping, debrief, retest report.
Two timelines, side by side
What we did, and what you saw. The gap between them is the product.
Executive summary
- Objectives set and whether each was reached
- Compromise timeline against detection timeline
- What the access would have meant, in business terms
- The three changes that matter most, ordered
Attack narrative
- Full path from reconnaissance to objective
- Every technique mapped to MITRE ATT&CK
- Proof-of-concept evidence per step
- Paths attempted and blocked, and what blocked them
Detection gap analysis
- Per action: logged, alerted, actioned, or none of the three
- Where telemetry was absent versus present but unmonitored
- Alerts that fired and were dismissed
- Specific detection rules to add, with the data source
Response evaluation
- Time to detect, escalate, and contain per event
- Whether containment removed access or only appeared to
- Playbook steps followed and skipped
- Escalation and communication path as it actually ran
Purple team option
After the debrief, techniques that went undetected can be re-run openly alongside your defenders, so detection rules are written and validated against live activity rather than documentation.
What we need to quote
The scoping conversation for this engagement is confidential by default and typically involves only the security lead and one executive sponsor.
- →The objective: what an attacker reaching it would mean for the business.
- →What you already have: SIEM, EDR, identity provider, cloud provider, and who watches them.
- →Prior testing: what penetration tests have been run and what came out of them.
- →Who may know: which named individuals are read in, and who must not be.
- →Whether social engineering against employees is authorized, and by whom.
- →Off-limits systems and any change freeze or high-traffic window.
- →Duration you can support, and whether a live incident should pause the engagement.
When to buy something else
This measures detection. With nothing to measure, it is an expensive penetration test with worse coverage.
Red teaming fits
- → Someone is responsible for watching alerts
- → You have logging, and a SIEM or EDR consuming it
- → You have run penetration tests and fixed what they found
- → You want to know whether your response plan works
- → An executive sponsor accepts an unannounced exercise
Start elsewhere if
- → You have never had a hands-on assessment: Penetration Testing
- → Nobody is monitoring, so there is no detection to measure
- → You need compliance evidence rather than a capability test
- → Your concern is a trusted insider rather than an intruder: Insider Threat Simulation
- → Leadership is not prepared to be surprised
The usual sequence
Penetration testing to find and close what is exploitable, then monitoring built against what was found, then red teaming to check whether the monitoring works. Running the last step first tells you something you already know.
Before scoping
Two tools worth running first
Both produce an output you can bring to the scoping call, and either may tell you this is not yet the right engagement.
Common questions about red team engagements
Still have questions about red team engagements? Book a discovery call
How to start
Send the objective you want tested and what you currently have watching for it. The first conversation is confidential and its most useful outcome may be that this is not yet the right engagement.
Direct: hello@principlebreach.com
Sequence
- Confidential discovery call
- Objective definition and threat model
- Rules of engagement and authorization
- Execution window
- Report, detection gap analysis, debrief
- Remediation retest or purple team follow-up