Red team assessment
An objective-led exercise in which testers act as a realistic attacker against goals you set. The point is to learn how far they get, what your monitoring detects and how your team responds — with clear rules of engagement written before anything starts.
- Objective-led
- Rules of engagement first
- Purple-team debrief
-
Written objectivesSigned before testing
-
Detection measuredDetected versus missed
-
Purple-team debriefWith your defenders
-
Emergency stopNamed contacts throughout
Who this is for
A good fit
- Organisations that already run monitoring and want to know whether it works against a determined attacker.
- Read the assumed-breach case study before you ask for a red-team label.
Worth knowing
- Less useful if you have little detection yet — in that case an internal network test or an assumed breach assessment usually gives more value first.
What we test
Objectives
Reach named systems, data or business processes
Details
- Reach named systems, data or business processes
- Agreed “crown jewel” targets
- Detection and response goals (for example: was the SOC alerted?)
- Time-boxed success criteria written before the test
Threat-led scenarios
Scenarios based on threats relevant to your industry
Details
- Scenarios based on threats relevant to your industry
- Assumptions about attacker skill and starting knowledge
- What is in and out of scope for people, premises and production
Initial access
External: no prior access, from the internet
Details
- External: no prior access, from the internet
- Assumed breach: a standard user or device you provide
- Phishing or social engineering as a starting point, where agreed
- Cloud or Microsoft 365 identity paths
Command and control and presence
How the tester maintains access once inside
Details
- How the tester maintains access once inside
- Whether that traffic is noticed
- Avoidance of destructive or noisy techniques unless approved
Lateral movement and privilege
Credential and identity abuse
Details
- Credential and identity abuse
- Privilege escalation on workstations and servers
- Movement to Active Directory, cloud control planes or SaaS
- Access to the agreed objectives
Detection measurement
What was detected, and when
Details
- What was detected, and when
- What was missed
- Timeline mapped to your alerts and tickets
- Purple-team debrief with your defenders
Physical intrusion (optional)
On-site entry under a signed authorisation letter
Details
- On-site entry under a signed authorisation letter
- Tailgating, badge and access-control paths
- Reception pretexting and rogue device drops
- Hand-off into the digital red team once inside
- See also the dedicated physical penetration testing page
Rules of engagement
Named contacts and emergency stop
Details
- Named contacts and emergency stop
- Allowed hours, networks, buildings and accounts
- Data that must not be exfiltrated for real
- How findings are reported during the test
- Signed authorisation letter when physical is in scope
About this scope
Each engagement is built around objectives and rules of engagement, not a vulnerability checklist. Methods draw on public guidance such as NIST SP 800-115 and common threat frameworks (for example MITRE ATT&CK tactics) so your defenders can map what happened to their detections.
What you receive
- An attack narrative and timeline showing each step.
- A comparison of detected versus undetected activity.
- Technical findings with evidence and remediation guidance.
- An executive summary for leadership.
More about the report
- A purple-team debrief with your defenders.
- Optional replay of key steps so your team can tune detections.
Common findings (examples)
- Initial access that never generated an alert.
- Privilege escalation that your endpoint tooling did not see.
- Lateral movement using legitimate admin tools that look like normal work.
- Cloud or Microsoft 365 paths that bypass on-premises monitoring.
- Response playbooks that exist on paper but were not followed in time.
What we need from you
- Written objectives and rules of engagement, signed before testing.
- A trusted contact available during the test window.
- Starting credentials or devices if the engagement is assumed-breach.
- Agreement on whether phishing is in or out of scope.
- Access to detection timelines after the test for the purple-team debrief.
Typical timeline
Duration depends on objectives, starting point and how much of the attack surface is in play. A focused assumed-breach exercise against a few objectives is often shorter than a full external-start engagement that includes phishing and cloud. Dates and check-in points are agreed in the rules of engagement.
Standards and method
Planning and reporting draw on NIST SP 800-115 and on common threat frameworks (for example MITRE ATT&CK tactics) so your defenders can map each step to detections. Objectives and rules of engagement are written before any testing. We do not claim CREST STAR, CBEST or CERT-In empanelment; if a contract requires a named scheme, say so at scoping and we will be plain about what we can and cannot sign.
Engagement shapes
- External start. No prior access. Testers work from the internet toward the objectives.
- Assumed breach. You provide a standard user or device. The exercise starts inside and measures how far it goes and what is detected.
- Identity-led. Focus on cloud and Microsoft 365 paths, token theft and consent abuse.
- With phishing. Social engineering as the agreed initial access, often booked with the social engineering assessment.
- Physical start. On-site intrusion under a signed authorisation letter, then continue on the network if the rules allow. Often booked with the physical penetration testing page.
- Purple-team heavy. Shorter attack window, longer joint debrief and detection tuning.
What stays out of scope by default
- Destructive actions, ransomware deployment or data destruction.
- Attacks on third parties you do not own (suppliers, customers) without their written approval.
- Exfiltration of real personal data beyond a minimal proof file you approve.
How this differs from continuous or crowd testing
This is a scoped, human-led engagement with named objectives and a debrief — not an always-on platform subscription and not an open crowd test. If you need continuous external probing, say so at scoping and we will be plain about what PoCForge does and does not run.
Evidence handling
Screenshots, logs and any proof files stay on encrypted storage. Real personal data is avoided; when a minimal proof file is needed you approve it first. At the end of the retention period we delete or return the evidence as the agreement says.
Scope and rules
- Scoping. Objectives, starting point, rules, limits and a trusted contact who knows the test is running.
- Threat modelling. Scenarios that match your industry and the assets you named.
- Reconnaissance. Within agreed sources only (for example public OSINT, not illegal access).
- Initial access or assumed-breach start. As written in the rules.
- Movement towards objectives. With check-ins at agreed points so there are no surprises for production.
- Detection review and purple-team debrief. Side-by-side walkthrough of the timeline with your security team.
- Report. Attack narrative, detected versus undetected activity, findings and fixes.
Red team assumed-breach engagement
Anonymised assumed-breach red team pattern: multi-surface objectives, detection gaps and board-ready narrative without TTP dumps.
Read the case study →- Objective-led
- Rules of engagement first
- Purple-team debrief
Related
Frequently asked questions
How is this different from a penetration test?
A penetration test aims to find as many issues as possible in a scope. A red team works towards set objectives and measures detection and response.
Is it safe for production?
Actions are controlled and agreed in advance. Anything destructive is out of scope. An emergency stop is always available.
Do we need a mature security team?
It helps. If you have little monitoring, an internal test or assumed-breach test usually gives more value first.
Can phishing be the starting point?
Yes, where agreed in writing. That is often combined with a social engineering assessment.
Will you tell the SOC the test is running?
That is your choice. Some clients keep the SOC unaware; others tell a small trusted group. Either way, a stop contact must know.
Do you use real malware?
We use controlled tooling and techniques. Anything that would cause lasting harm stays out of scope.
Is physical intrusion included?
Yes, when you ask for it. Physical work needs a signed authorisation letter, named sites and rules of engagement. It can sit inside this red team or be booked as a dedicated physical penetration test.
Do you claim CERT-In empanelment?
No. PoCForge does not claim CERT-In empanelment. Reports can still support evidence requests that ask for adversary simulation.
Ready to scope this?
Tell us what is in scope and what you want to learn. We reply with a suggested approach.
Request a free scope review →