Identity-first attacks are now a practical security problem because attackers do not always need to “break in” anymore. Industry threat reporting consistently describes a broader shift away from expensive, one-off intrusion techniques and toward higher-efficiency abuse of trusted access, with stolen session tokens emerging as a higher-return option than many traditional exploit paths. Microsoft’s token theft guidance describes the same pattern from the defender side: once a token is stolen and replayed, the attacker can gain access even if the user already satisfied MFA.

This tutorial covers the identity-first attacks most teams are now seeing in real environments: adversary-in-the-middle phishing, session cookie theft, token replay, support-path impersonation, and the “logging in” style of intrusion where the attacker abuses trusted identity and SaaS access rather than noisy malware or obvious brute force. Modern AiTM campaigns are especially dangerous because they can steal credentials and session cookies in real time, replay the session, and then establish persistence by modifying MFA methods or inbox rules.

By the end, you will have a practical hardening plan: identify the accounts most likely to be targeted, require stronger authentication, reduce session replay opportunities, tighten support workflows, add useful monitoring, and rehearse the response to a stolen-session incident. If you are also planning a broader workforce rollout of stronger authentication, this tutorial pairs well with How to Roll Out Enterprise Passkeys and Phishing-Resistant MFA.

Step 1: Identify Your Highest-Risk Identities

The fastest way to improve identity security is not to harden every account equally. It is to start with the accounts attackers are most likely to exploit first. Recent threat research frames the current landscape as “high-trust exploitation,” which is exactly why admin, developer, finance, help desk, and third-party identities deserve special treatment.

Build a risk inventory

Create a small file that maps identity types to risk, privileges, and likely abuse paths.

admins:
  examples:
    - cloud-admins
    - idp-admins
    - email-admins
  risks:
    - tenant-wide compromise
    - privilege escalation
    - policy tampering
  priority: critical

developers:
  examples:
    - ci-cd-maintainers
    - repo-admins
    - secrets-managers
  risks:
    - source tampering
    - secret exposure
    - supply-chain abuse
  priority: high

finance_hr:
  examples:
    - payroll
    - accounts-payable
    - hr-ops
  risks:
    - bec-fraud
    - payroll diversion
    - pii exposure
  priority: high

help_desk:
  examples:
    - password-reset-agents
    - identity-support
  risks:
    - social-engineering pivot
    - mfa reset abuse
    - account recovery hijack
  priority: critical

third_party_access:
  examples:
    - contractors
    - vendors
    - managed-service-accounts
  risks:
    - weak endpoint hygiene
    - unmanaged-device access
    - supply-chain identity exposure
  priority: high

Map real permissions, not just job titles

Do not assume “finance” is high risk and “project manager” is not. Look at actual permissions:

who can reset MFA
who can approve payments
who can manage mail flow
who can create app registrations
who can access customer data exports
who can publish code or artifacts

A spreadsheet or YAML file is enough as long as it reflects reality.

Include shared and dormant access

Also inventory:

break-glass accounts
shared admin devices
service accounts with interactive sign-in
dormant privileged users
third-party support accounts that are still enabled

Tip

The accounts most likely to be abused are the ones with high trust, broad access, and weak friction around recovery or approval paths.

You should now have a list of the identities that deserve stronger controls before the rest of the workforce.

Step 2: Harden Authentication

The goal here is not “more MFA prompts.” It is to make phishing and token abuse materially harder. Microsoft’s current identity guidance explicitly says passkeys provide phishing-resistant authentication that attackers cannot phish, intercept, or replay, and it recommends phishing-resistant methods for privileged accounts and Conditional Access policies that enforce strong authentication for sensitive applications.

Require phishing-resistant MFA for the right users first

Start with IdP admins, cloud admins, finance approvers, help desk staff, developers with production or CI/CD privileges, and frequently targeted executives. Block SMS, voice call, and push-only MFA for these users. Require passkeys or security keys and set a 90-day migration target for standard high-risk users.

Enforce device trust for sensitive access

Combine stronger authentication with compliant-device requirements and risk-based Conditional Access, rather than relying on authentication alone. High-value apps should require managed or compliant devices, sign-in risk checks, and step-up auth for sensitive actions.

Treat passkeys and security keys as the default destination

Make passkeys the preferred method and security keys the strong fallback for privileged or shared-device scenarios. For the full enrollment plan, rollout models, recovery design, and adoption metrics, see How to Roll Out Enterprise Passkeys and Phishing-Resistant MFA.

Warning

Identity-first attackers target whatever path remains easiest. If weak MFA methods stay available forever for high-risk users, they remain part of the real attack surface.

You should now have a prioritized authentication baseline that raises the cost of phishing and credential replay for the accounts that matter most.

Step 3: Reduce Session Theft Exposure

Even strong authentication is not enough if the attacker can steal or replay the resulting session. Microsoft’s token theft playbook is explicit: a token theft attack works because the attacker reuses a token issued to a user who already completed MFA. Microsoft’s token protection guidance also says token protection reduces replay by requiring device-bound sign-in session tokens, though current platform support is still limited and browser-based applications are not supported by that control today.

Shorten risky session lifetime where appropriate

Do not shorten every session blindly, but review these cases first:

admin consoles
finance and payroll apps
help desk and recovery tooling
sensitive document repositories
email admin and mailbox management
custom internal admin apps

A simple session policy baseline:

admin_apps:
  max_session_hours: 4
  sign_in_frequency_hours: 4
  require_reauth_for_sensitive_actions: true

finance_apps:
  max_session_hours: 8
  sign_in_frequency_hours: 8
  require_reauth_for_wire_or_payroll_changes: true

standard_apps:
  max_session_hours: 12
  sign_in_frequency_hours: 12
  require_reauth_for_profile_security_changes: true

Require reauthentication for sensitive actions

Do not rely on the original session for:

MFA method changes
password reset for another user
export of large datasets
payment detail changes
inbox rule changes
admin role assignment

This matters because modern AiTM and token theft campaigns often pivot into persistence by changing MFA methods or adding account-recovery paths after the initial compromise. Microsoft’s AiTM case study explicitly documented attackers adding a new MFA method after replaying a stolen session and recommended requiring MFA re-challenge for MFA updates.

Use token protection or binding where available

If your identity platform supports device-bound tokens or token protection, enable it first for the applications and devices it actually supports. Microsoft documents token protection as a Conditional Access session control that reduces replay by ensuring only device-bound sign-in session tokens are accepted, and recommends rolling it out with a pilot group and report-only validation first.

Note

Token binding or token protection is valuable, but it is not universal. Treat it as a defense-in-depth layer, not your only replay defense.

Clean up browser and extension risk

AiTM and session theft defense is weaker if users browse from unmanaged endpoints full of risky extensions. At minimum:

restrict extension installs for privileged users
block unmanaged browsers from admin apps
require secure, supported browsers for sensitive access
review browser session persistence settings

{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": [
    "aapocclcgogkmnckokdopfmhonfmgoek",
    "ghbmnnjooekpmoecnnnilnnbdlolhkhi"
  ],
  "PasswordManagerEnabled": false,
  "BrowserSignin": 0
}

You should now have lower-value sessions for attackers, tighter protection around session replay, and less browser-based exposure on sensitive accounts.

Step 4: Block AiTM and Phishing Workflows

AiTM attacks succeed because they fit inside normal-looking workflows: email link, trusted vendor message, cloned login page, MFA prompt, stolen session, then silent replay. Microsoft’s 2023 campaign write-up showed exactly that pattern, including the use of trusted vendors, legitimate services as lures, fake Microsoft sign-in and MFA pages, session cookie replay, and follow-on BEC activity.

Strengthen email controls for identity abuse, not just malware

Tune the email stack to focus on:

vendor and partner impersonation
suspicious login-themed lures
trusted-platform abuse like cloud file shares
newly seen domains and odd redirect chains
campaign correlation across multiple users

For sensitive applications and SSO paths:

use only your official IdP domains
reduce alternate login surfaces
block direct legacy auth where possible
ensure users are trained on the real sign-in experience
favor origin-bound phishing-resistant methods so fake login pages cannot complete the flow successfully

Update user education to match current attacks

Teach users current patterns, not just “look for typos”:

fake MFA steps on a cloned sign-in page
“open this document” links from real vendors
password + MFA capture leading to silent account takeover later
help desk or support impersonation after phishing
mailbox rule abuse and second-stage internal phishing

Detect unusual MFA and session behavior

Do not rely only on “impossible travel.” Microsoft’s own AiTM guidance lists richer detections like suspicious inbox manipulation, unfamiliar sign-in properties, anomalous token use, possible AiTM phishing attempts, and risky sign-ins followed by MFA changes.

You should now have stronger controls around the phishing workflows that typically precede session theft and token replay.

Step 5: Lock Down Admin and Support Paths

Attackers love help desk and admin workflows because they are trusted, urgent, and often under-documented. If the help desk can reset MFA after a weak identity check, your fancy login policy is easy to route around.

Create a real help desk verification standard

password_or_mfa_reset:
  allowed_identity_checks:
    - manager_callback_using_directory_number
    - verified_hr_attribute_plus_ticket_context
    - approved_video_or_in_person_check
  disallowed_identity_checks:
    - caller_knows_email_address
    - caller_knows_employee_id_only
    - incoming_phone_number_match_only
  extra_requirements:
    - second-analyst-approval_for_privileged_accounts
    - mandatory_case_notes
    - alert_to_user_after_reset

Isolate privileged sessions

For privileged access, use:

dedicated admin accounts
privileged access workstations or isolated browsers
no daily email or web browsing from admin sessions
shorter sign-in frequency
stronger method requirements than normal workforce accounts

Add step-up requirements for admin changes

Always require fresh authentication for:

role changes
app registration changes
conditional access edits
mail transport and mailbox access changes
federation and identity provider settings

Protect break-glass accounts

Break-glass accounts should be:

few in number
offline-documented
excluded only where absolutely required
monitored continuously
not used for daily operations

Warning

If your emergency admin account becomes a convenience account, it stops being a resilience control and becomes a prime target.

You should now have fewer easy bypasses through support and admin workflows.

Step 6: Add Monitoring and Response

The point of monitoring is not to collect more sign-in logs. It is to spot identity compromise fast enough to stop persistence. Microsoft’s token protection and token theft guidance emphasizes active monitoring, risk-based Conditional Access, suspicious sign-in analysis, and rapid response because token replay and AiTM activity often require more than a password reset to contain.

Use detections that are better than impossible travel alone

Impossible travel can still be useful, but it is noisy by itself. Better detections include:

unfamiliar sign-in properties
sign-in from a new device plus new network plus sensitive app
same user from unusual IP and user agent combination
MFA method added after risky sign-in
new inbox rules after suspicious session activity
suspicious token reuse patterns
access to mail and files immediately after login from unusual properties

let RiskyWindow = 4h;
let RiskySignins =
SigninLogs
| where TimeGenerated > ago(1d)
| where RiskLevelDuringSignIn in ("medium", "high")
| project UserPrincipalName, RiskySignInTime = TimeGenerated, IPAddress, UserAgent;
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has_any ("Add authentication method", "Update user", "Register security info")
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| join kind=inner RiskySignins on $left.TargetUser == $right.UserPrincipalName
| where TimeGenerated between (RiskySignInTime .. RiskySignInTime + RiskyWindow)
| project TimeGenerated, TargetUser, OperationName, IPAddress, UserAgent

Example KQL: suspicious session reuse pattern

SigninLogs
| where TimeGenerated > ago(1d)
| summarize
    FirstSeen=min(TimeGenerated),
    LastSeen=max(TimeGenerated),
    IPs=make_set(IPAddress, 10),
    UserAgents=make_set(UserAgent, 10),
    Apps=make_set(AppDisplayName, 10)
  by UserPrincipalName
| where array_length(IPs) > 2 and array_length(UserAgents) > 1
| project UserPrincipalName, FirstSeen, LastSeen, IPs, UserAgents, Apps

Build an identity-compromise response playbook

initial_actions:
  - revoke_active_sessions
  - block_sign_in_temporarily
  - require_password_reset_if_password_was_captured
  - investigate_mfa_method_changes
  - review_inbox_rules_and_forwarding
  - review_app_consent_and_tokens
  - review_recent_admin_actions

containment:
  - require_reauthentication_for_sensitive_apps
  - restrict_access_to_managed_devices_only
  - increase_sign_in_risk_enforcement

post_incident:
  - confirm_user_device_health
  - remove_attacker_added_mfa_methods
  - review_affected_contacts_for_follow_on_phishing
  - document_root_cause_and_detection_gaps

Microsoft’s AiTM guidance is clear that password reset alone is not enough when the attacker steals a session and changes MFA settings; session revocation and rollback of attacker-made MFA changes are part of proper remediation.

Tip

The fastest useful question in an identity incident is often not “was the password stolen?” but “was a valid session or refresh path stolen and reused?”

You should now have a monitoring baseline and an initial response flow for identity compromise that goes beyond password resets.

Step 7: Run a Tabletop or Simulation

A tabletop is where you find out whether your controls work together or only look good on slides. Use scenarios that match current identity-first attack chains.

Scenario 1: phishing to session theft

# Scenario: Phishing to Session Theft

1. A finance user receives an email from a known vendor with a cloud-document link.
2. The link leads to a fake SSO login page and a fake MFA prompt.
3. The attacker captures the password, MFA challenge result, and session token.
4. Two hours later, the attacker replays the session from a new network.
5. The attacker creates inbox rules and tries to change payment details.

Questions:
- Which control should have blocked the initial sign-in?
- Which detections should fire after replay?
- Who revokes sessions?
- Who reviews inbox rules and outbound payment changes?

Scenario 2: support impersonation

# Scenario: Support Impersonation

1. An attacker calls the help desk posing as an executive traveling internationally.
2. They claim they lost their phone and cannot complete MFA.
3. They pressure support for a fast reset before a payroll deadline.
4. They ask to add a temporary recovery method.

Questions:
- What verification steps are mandatory?
- Can one analyst approve this alone?
- Is the user notified out-of-band?
- What extra control applies because the target is high risk?

Scenario 3: stolen token with persistence attempt

# Scenario: Stolen Token with Persistence Attempt

1. A developer's session is replayed successfully.
2. The attacker creates a new OAuth app consent and tries to add an MFA method.
3. They access source repositories and CI/CD settings.

Questions:
- Which detections should fire first?
- What gets revoked?
- Which secrets and tokens must be reviewed?
- How do you determine whether code or pipeline changes occurred?

Score the exercise

Track:

time to detect
time to contain
whether sessions were revoked
whether MFA changes were found
whether help desk policy held
whether communications were clear

Common Setup Problems

Requiring MFA but not phishing-resistant MFA

This leaves high-risk users exposed to AiTM capture and token replay even though the org believes “MFA is on.”

Focusing on passwords but not sessions

Teams often reset passwords and stop there, even though the attacker may already have a valid session, a refresh path, or an attacker-added MFA method.

Treating all users the same

Identity-first hardening works best when you prioritize admins, help desk, finance, developers, and third-party access first.

Using impossible travel as the main detection

Impossible travel helps, but it misses too much and generates too much noise to be the only identity-compromise signal.

Leaving support and recovery workflows weak

A strong front-door sign-in policy can still be bypassed through weak MFA reset, account recovery, or break-glass handling.

Wrap-Up

Identity-first attacks work because they abuse trust that already exists: trusted users, trusted devices, trusted sessions, trusted vendors, and trusted support processes. Industry threat reporting describes that broader shift as attackers optimizing for “logging in” and higher-return trusted access, while Microsoft’s token theft guidance shows why a replayed token can defeat defenses that stop at initial MFA.

If resources are limited, improve these first: require phishing-resistant methods for privileged users, force stronger controls on sensitive apps, require reauthentication for account-security changes, harden help desk verification, and deploy a response playbook that revokes sessions and checks for attacker-added persistence. Over time, the maturity target is simple: fewer phishable methods, fewer long-lived powerful sessions, fewer unmanaged paths to sensitive apps, and faster response when an identity is abused.

For a detailed walkthrough of deploying phishing-resistant authentication across your workforce, see How to Roll Out Enterprise Passkeys and Phishing-Resistant MFA. For more on the identity-based ransomware trends driving these defenses, see Identity-Based Ransomware.

Before you begin

What you'll learn