Running an identity-first attack simulation that actually tests defences

Planning your first red team exercise feels a bit like organizing a heist against yourself. You want drama without disaster, insight without chaos, and a final report that moves the needle rather than gathers dust. The good news is that a well-designed exercise pays off quickly, primarily when you treat identity as the modern attack surface and focus on how attackers move through cloud environments, SaaS, and non-human identities.

Security leaders need to plan and run their first red team exercise with an identity-centric approach that reflects how real attackers operate today.

“I love it when a plan comes together.”
- John ‘Hannibal’ Smith, The A-Team [1983]

Start With “Why”

Before talking tactics, decide what success looks like. A first red team exercise should have two or three clear goals. Keep them simple and measurable, for example:

• Can an attacker turn one compromised SaaS or SSO account into meaningful cloud privileges?
• How quickly can the blue team detect and contain suspicious identity behavior?
• Are service accounts, automation tokens, or CI/CD identities creating hidden attack paths?

These questions force the exercise towards cloud identity security, where most modern breaches begin. Attackers prefer valid credentials and privilege escalation over noisy exploits, so your objectives should reflect that reality. When your “why” is nailed down, write success criteria that sound like this:

“Identify at least three high-risk identity attack paths and validate detection and response to a compromised user escalating to cloud admin.”

That statement keeps everyone aligned and prevents scope creep later.

Check You’re Actually Ready

A red team is not a substitute for basic hygiene. Before running your first red team exercise, make sure:

• You already run regular vulnerability scans and fix the obvious flaws.
• Identity logs from your IdP and cloud providers are flowing somewhere central.
• Your team knows where the “crown jewels” live: the privileged roles, critical apps, and sensitive data stores.

If those pieces aren’t in place, with the likes of privileged access management, start smaller with a penetration test or purple-team workshop. A red team exercise should test resilience, not catalog low-hanging fruit.

Decide Who Will Run It

For a first exercise, most organizations bring in an external partner. They bring credibility, specialist skills, and a neutral point of view. Others run a hybrid model: an external red team, with internal engineers shadowing to facilitate knowledge transfer.

Whoever you choose, prioritize expertise in identity. Many offensive teams are strong on phishing and Windows lateral movement but weaker in cloud IAM, role assumptions, SaaS admin misconfigurations, and non-human identity abuse. A modern red team needs fluency across Okta, Entra ID, Google Workspace, AWS IAM, Azure RBAC, GCP IAM, and CI/CD pipelines. If the attacker model doesn’t understand cloud roles and automation identities, they’ll miss your real weaknesses.

Scope it Properly

The Rules of Engagement (RoE) make or break a safe and valuable exercise. Scope your first red team exercise so identity and cloud are unambiguously in play.

In scope:

• SSO/IdP (Okta, Entra ID, Google Workspace)
• Cloud IAM (AWS, Azure, GCP)
• CI/CD identities, service accounts, secrets, access keys
• SaaS systems that grant privilege, like HR and ITSM platforms

Out of scope:

• Destructive actions such as deleting users or rotating production secrets
• Anything that risks data loss, customer impact, or downtime

Decide whether the SOC is “blind” (treat it as real) or “informed” (purple-team style). Both models work, but blind exercises reveal how your monitoring behaves under pressure.

Build Identity-Centric Scenarios

A first red team exercise only needs two scenarios. The aim is depth, not quantity.

Scenario 1: Compromised user → cloud admin

This path mirrors real incidents. The red team attempts to phish or gain OAuth consent from a normal user, bypass MFA, then escalate through cloud roles and group memberships. The blue team should spot unusual sign-in patterns, odd role assumptions, new admin assignments, or privilege elevation.

Scenario 2: Service account or CI/CD abuse

Here the red team steals a pipeline token, GitHub deploy key, ordsc automation credential and enumerates what it can access. The goal is to test whether service accounts are over-privileged, long-lived, or poorly monitored.

Scenario 3 (optional): Cross-cloud pivot

If your environment is hybrid, test whether trust relationships allow a hop from on-prem AD or one cloud tenant into another.

Treat each scenario as a story with a beginning (initial access), middle (privilege escalation), and end (an objective the red team could complete if not stopped). You’re not testing noise; you’re testing whether an attacker with a valid identity can reach your crown jewels.

Get Your Telemetry in Order

Identity attacks are quiet. To learn anything from your first red team exercise, you’ll need visibility into:

• IdP events: sign-ins, MFA prompts, risk scoring, conditional access outcomes
• Cloud audit logs: role assumptions, IAM policy changes, token usage
• SaaS admin logs from your most privileged apps
• Identity-first analytics or ITDR to correlate user accounts, service accounts, and their effective permissions

This is where platforms that map entitlements and model attack paths earn their keep. If you can pull a graph showing how a single user can reach cloud admin through nested groups, you’ll know exactly what the red team will try.

Plan the Execution

Split the exercise into phases:

• Recon: Mapping identity attack paths, exposed credentials, public repos, and SaaS misconfigurations.
• Initial access: Phishing, OAuth consent, or assumed breach.
• Privilege escalation: Chaining permissions, exploiting misconfigurations, abusing service accounts.
• Persistence: New OAuth apps, long-lived tokens, backdoor roles.
• Objective: Simulate exfiltration or control of a sensitive system.
• Clean-up: Remove accounts, keys, logs, and reset any artifacts.

During the exercise, track which alerts fired, which were missed, and how long each detection and response took. The point isn’t to “win”; it’s to learn.

Turn Findings Into Real Improvements

The value of your first red team exercise is the remediation backlog. Focus on identity-driven fixes:

• Remove unused or over-privileged roles
• Replace standing access with approval-based just-in-time access
• Reinforce MFA and conditional access
• Reduce long-lived tokens and service accounts
• Improve detection for anomalous role assumptions, admin changes, and token misuse
• If you haven’t already, adopt just-in-time access (JIT) to automate zero trust enforcement and strengthen identity protection. For a good start, grab our free trial.

You should finish with a clear narrative: how the attack unfolded, what you saw, what you missed, and what will stop it next time.

A first red team exercise isn’t about catching your team out; it’s about seeing your environment the way an attacker would and fixing the gaps before someone else finds them. Start small, focus on identity, learn from the exercise, and make it a regular part of your security rhythm. It’s the closest thing you’ll get to a controlled breach, and the lessons are worth their weight in incident reports.