// 01.1 / Read
What is
Identity
Before you can defend an identity, you need to understand what it actually is and why it became the primary attack surface in cloud environments.
Definition
Identity in a Cloud Context
An identity is any entity that needs to authenticate to access a resource. In Microsoft Entra ID this includes users, devices, applications, and service principals. Every identity has attributes, credentials, and permissions. The combination of those three things is what attackers target not the network, not the firewall.
Type 01
Human Identities
Your users. Employees, contractors, admins, guests. They authenticate with passwords, MFA, passkeys. They make mistakes, get phished, approve push notifications they should not approve.
Type 02
Non-Human Identities
Service accounts, app registrations, managed identities, API keys, certificates. They authenticate with secrets or certificates. They outnumber humans 144:1 in the average enterprise. Nobody watches them.
Type 03
Device Identities
Entra-joined or hybrid-joined machines. They receive Primary Refresh Tokens that enable SSO to cloud resources. A compromised device identity can be a launchpad to Microsoft 365 without any password.
Type 04
Workload Identities
Applications and services that need to access other resources. Managed identities are the preferred type they have no secret to steal. Service principals with client secrets are the risky ones.
Why identity became the perimeter: Traditional security assumed threats came from outside. Firewalls, VPNs, network segmentation. Cloud collapsed that model. Every user, every app, every service now authenticates directly to cloud APIs. The only thing standing between an attacker and your data is whether they have a valid identity token.
// Real World // MGM Resorts 2023
$100M breach via helpdesk call
Attackers used LinkedIn to find an MGM IT employee, called the helpdesk impersonating them, and convinced an agent to reset MFA on the account. No malware. No vulnerability. Just identity. The breach cost MGM over $100 million and disrupted operations across their hotel and casino properties for weeks.
Start here
// 01.2 / Read
How Tokens
Work
Tokens are the currency of cloud identity. Understanding what they are, how long they last, and what they allow is fundamental to understanding how attackers operate after initial access.
Core Concept
The Token Exchange Model
When you authenticate to Entra ID, you do not get direct access to resources. You get tokens. Those tokens are presented to APIs to prove who you are. The key insight: once a token is issued, the password that produced it is irrelevant. Changing your password does not invalidate tokens already in circulation.
Token Type 01
Access Token
Short-lived (60-90 minutes). Presented directly to APIs like Microsoft Graph. Contains claims about who you are and what you can do. Cannot be revoked mid-lifetime without CAE support.
Token Type 02
Refresh Token
Long-lived (up to 90 days, renewed on use). Used to get new access tokens without re-authenticating. If an attacker has your refresh token they have persistent access. Password resets alone do not revoke them.
Token Type 03
Primary Refresh Token (PRT)
Issued to Entra-joined devices. Valid for 14 days. Enables SSO to all Azure and M365 resources. Stored in LSASS memory. Extractable with tools like Mimikatz. Bypasses MFA because it already satisfied it at device join.
Token Type 04
ID Token
Contains identity claims about the user. Not used for API access directly. Used by applications to understand who authenticated. Contains the scp claim (delegated scopes) or roles claim (application permissions).
The scp vs roles distinction matters: If a token has claims in the scp field, a user delegated access they were involved. If claims are in the roles field and scp is empty, it is an application permission no user, no sign-in event, no MFA. This is a critical detection gap most blue teams miss.
Key Takeaway
Why Token Theft is So Effective
A stolen token is as good as the real thing. It does not matter how strong the password was. It does not matter that MFA was enabled. If the attacker has a valid token they have access until that token expires or is explicitly revoked. Conditional Access evaluated at issuance, not per request. The token already passed all the checks.
// 01.3 / Read
What MFA
Actually Does
MFA is necessary but not sufficient. Understanding exactly what it protects and what it does not protects you from overconfidence the most dangerous vulnerability in any security program.
What MFA Stops
Credential Stuffing
Attacker has your username and password from a data breach. Without MFA they are in. With MFA they need the second factor. This is the core use case MFA was designed for.
What MFA Stops
Password Spray
Attacker guesses common passwords across many accounts. Even if they find a matching credential, MFA blocks the sign-in without the second factor. High-value control for this attack type.
What MFA Does NOT Stop
AiTM Phishing
Attacker proxies the real login page. User completes MFA successfully. Attacker captures the post-auth session token. MFA was satisfied the attacker gets the token anyway. Only phishing-resistant MFA (FIDO2) mitigates this.
What MFA Does NOT Stop
Token Theft and Replay
Once a token is issued, MFA is irrelevant. An attacker with a stolen access or refresh token can use it from anywhere. MFA only runs at authentication time, not at every API call.
What MFA Does NOT Stop
Consent Phishing
User authenticates with MFA legitimately then grants a malicious OAuth app delegated permissions. MFA was completed correctly. The attacker gets persistent delegated access via token that survives password resets.
What MFA Does NOT Stop
MFA Fatigue
Attacker has credentials, floods user with push notifications until they approve. MFA was technically completed by the legitimate user. Number matching largely mitigates this blind push approvals do not.
// Real World // Uber 2022
MFA defeated via push bombing
An 18-year-old attacker obtained Uber contractor credentials, then bombarded the contractor with MFA push requests for over an hour. The contractor eventually approved one to make it stop. The attacker then gained access to Uber's internal systems including their Slack, HackerOne reports, and cloud infrastructure. Uber had MFA enabled. It did not matter.
// 01.4 / Read
Non-Human
Identities
The fastest growing and least governed attack surface in enterprise security. 144 machine identities for every human in the average organisation. Most of them unmanaged, over-privileged, and never rotated.
The Problem
Nobody Is Watching the Machines
Human identities have managers, access reviews, offboarding processes, and MFA. NHIs have none of that. A service account created three years ago for a project that ended still has active credentials and permissions. It does not complain when compromised. It does not trigger behavioral alerts. It just keeps working for whoever has the credentials.
NHI Type 01
Service Principals
App registrations with a corresponding identity in Entra ID. Authenticate with client secrets or certificates. Can have API permissions granted directly. Frequently over-privileged and under-monitored.
NHI Type 02
Managed Identities
Azure-managed identities for resources like VMs and Function Apps. No secret to steal or rotate credentials are managed by Azure. The preferred approach. But permissions still need to be scoped to least privilege.
NHI Type 03
Client Secrets and Certificates
NHI Type 03
Credentials attached to app registrations. Secrets expire but are frequently not rotated. Certificates can have multi-year validity. Both can be added by attackers as backdoors they survive password resets entirely.
NHI Type 04
OAuth Tokens and API Keys
Bearer tokens from consent grants and API keys from integrations. Often stored in repos, CI/CD logs, Slack messages, and spreadsheets. 44% of all exposed secrets are found outside source code repositories.
The numbers in 2026: NHIs outnumber human identities 144:1. 71% are not rotated within recommended timeframes. 97% carry excessive privileges. 43% of organizations lack full visibility into their NHI landscape. This is not a niche problem it is the primary unaddressed attack surface in most environments.
// 01.5 / Read
Anatomy of
a Token
A JWT is just a base64-encoded JSON object. Every token that grants access to Azure and M365 resources is one. Knowing how to read it is one of the most practical skills a blue teamer can have.
Structure
What a Decoded Token Actually Looks Like
A JWT has three parts separated by dots: header, payload, claims. The payload is where everything interesting lives. Paste any token into jwt.ms to decode it instantly. Here is what the key claims mean and why they matter.
Claim // iss
Issuer
Who issued the token. For Entra ID tokens this will be a Microsoft STS URL containing your tenant ID. An unexpected issuer means the token did not come from your identity provider.
Claim // aud
Audience
What resource this token is valid for. A token issued for Microsoft Graph cannot be replayed against another API. Attackers cannot reuse a Graph token to access Azure Resource Manager and vice versa.
Claim // exp
Expiry
Unix timestamp when the token expires. Access tokens typically expire in 60-90 minutes. Refresh tokens up to 90 days. A token with a very long exp is worth scrutinizing.
Claim // scp
Scopes (Delegated)
Space-separated list of delegated permissions a user consented to. If this is populated, a human was involved in issuing this token. Mail.Read, User.ReadWrite, etc. This claim is absent in application permission tokens.
Claim // roles
App Roles (Application)
Application permissions granted to a service principal. If roles is populated and scp is empty, no user was involved. The action will appear as the service principal in audit logs, not as a user. Critical detection gap.
Claim // oid
Object ID
The unique identifier of the user or service principal the token was issued to. This is what appears in audit logs. If you see an oid in a log you do not recognize, look it up immediately. It may be a backdoor service principal.
Claim // tid
Tenant ID
The Entra tenant the token was issued from. If you see a tid in a log that does not match your tenant, a cross-tenant token is being used. Sometimes legitimate, sometimes an attacker using a guest account or multi-tenant app.
Claim // amr
Authentication Methods
How the user authenticated. Values include pwd (password), mfa, wia (Windows Integrated Auth), rsa (certificate). If a token shows only pwd with no mfa and has access to sensitive resources, that is a misconfiguration worth flagging.
Practical move: Go to jwt.ms and paste any Entra ID token. You can get one by opening the browser dev tools on any Microsoft 365 page, going to Application, Cookies, and copying a token value. Decode it and identify each claim listed above. This takes five minutes and you will read logs differently afterwards.
// Why This Matters in IR
Token analysis caught what logs missed
In several 2025 IR engagements, analysts found service principal tokens with Mail.ReadWrite in the roles claim and an empty scp field being used to exfiltrate mailbox data. The actions appeared as the service principal in audit logs and triggered no user-centric DLP alerts. Knowing to look for empty scp with populated roles was the difference between finding the breach and missing it entirely.
// 01.6 / Read
Credential
Exposure Paths
Credentials do not just get stolen through phishing. Most of the time they leak. Understanding where they leak tells you where to look and what to fix.
Exposure Path 01
Git Repositories
Client secrets, API keys, and connection strings committed to source code. Even in private repos, even briefly. Git history preserves everything. A secret committed and immediately deleted is still in the commit history and must be treated as compromised.
Exposure Path 02
CI/CD Pipeline Logs
Secrets passed as environment variables that get printed to build logs during debug output or error messages. GitHub Actions, Azure DevOps, and Jenkins all have cases where secrets leak into logs that are visible to anyone with repo access. Secrets in logs should be rotated immediately and logs scrubbed.
Exposure Path 03
Collaboration Tools
Credentials shared in Slack, Teams, or email for convenience. Copy-pasted into a message channel "just temporarily." Stored in pinned messages or channel history indefinitely. A credential shared in Slack is a credential with an unknown blast radius. Treat it as compromised.
Exposure Path 04
Hardcoded in Application Code
Connection strings, API keys, and passwords embedded directly in source code. Common in legacy applications and scripts. Frequently deployed to environments where the code is accessible to anyone with server access. Use Azure Key Vault or environment variables, never hardcode credentials.
Exposure Path 05
Cloud Storage and Backups
Configuration files, .env files, and backup archives stored in misconfigured blob storage or S3 buckets. Publicly accessible storage containing credentials is one of the most common initial access vectors in cloud environments. Every publicly accessible storage container should be assumed to have been read by someone.
Exposure Path 06
Infostealer Malware
Malware that silently harvests saved browser credentials, session cookies, and application tokens from an infected device. IBM X-Force recorded 180% more infostealer delivery in early 2025 versus 2023 baseline. Stolen credentials from personal devices used for work are sold on dark web markets within hours of infection.
The 44% rule: According to GitGuardian research, 44% of all exposed secrets are found outside source code repositories. Scanning only your code misses nearly half the problem. Collaboration tools, CI/CD logs, and cloud storage all need to be in scope for any secrets management program.
// 01.7 / Reinforce
Flashcards
Click the card to reveal the answer. Mark it as known or review it again. Unknown cards resurface at the end.
Card 1 of 11
// Tap to reveal answer
// Answer
Click card to flip
// 01.8 / Reinforce
Spot the
Risk
Look at the scenario below as if you are reviewing it in your environment. Identify what is wrong and why it matters.
Display Name
BackupService-Legacy
Application ID
a4f2c891-3b7d-4e12-9c0f-88124d5e7831
Owner
None assigned
Client Secret Expiry
2028-06-15 (never rotated)
Last Sign-in
2026-04-28 03:14 UTC Kyiv, Ukraine
API Permissions
Owner /providers/Microsoft.Management/managementGroups/root
Last Known Use
Project decommissioned 14 months ago
What is the highest-severity finding in this service principal and what does it enable?
Owner on the root management group is a tenant takeover primitive. The secret expiry, the geographic anomaly, and the missing owner are all serious but they are secondary to the permission scope. An attacker who obtains this secret has full control over every Azure subscription in the tenant. The sign-in from Ukraine at 3am while the project has been decommissioned for over a year is a near-certain compromise indicator. This principal should be disabled immediately and the secret revoked. Investigate the Ukraine sign-in as an active incident.
// 01.9 / Reinforce
Spot the
Risk 02
A GitHub Actions workflow from a production repository. Find the issues.
Trigger
push to main
Step 1
az login --service-principal -u $APP_ID -p $CLIENT_SECRET --tenant $TENANT_ID
CLIENT_SECRET value
AbC3~dEfG9hIjK2lMnOp1qRsT7uVwXyZ (hardcoded in env block)
Service Principal Role
Owner on subscription /subscriptions/a1b2c3d4...
Log level
debug (all environment variables printed to job log)
Repo visibility
Private, 14 contributors
Secret last rotated
Never
There are multiple issues here. Which combination represents the highest severity finding?
The hardcoded secret combined with debug logging means the credential is visible in plain text in the job logs to all 14 contributors. Owner on the subscription means whoever reads that log has full control over every resource in the subscription. Rotation schedule is a secondary concern when the secret is already fully exposed. The fix is workload identity federation (no secret at all), least-privilege role scoped to what the pipeline actually needs, and debug logging disabled in production workflows.
// 01.10 / Test
Module
Quiz
Five questions covering everything in this module. Explanations shown after each answer whether right or wrong.
out of 17