Session-Theft Phishing Response Playbook

Phishing attacks are evolving beyond simple credential theft. Services like NovaCookies, costing $320 per month, can hijack active Microsoft 365 sessions in real-time. Your MFA prompt appears, you approve it, and the attacker gains access to your environment.

This playbook provides your security team with a structured response framework for session-theft phishing incidents. It aligns with ISO/IEC 27001:2022 controls 5.24 (Information Security Incident Management Planning and Preparation), 5.25 (Assessment and Decision on Information Security Events), and 5.26 (Response to Information Security Incidents), as well as SOC 2 CC7.3 (Detection of Incidents) and CC7.4 (Response to Incidents).

What This Playbook Covers

This guide offers a step-by-step incident response script for suspected session-theft phishing. It includes triage questions, containment actions, evidence collection requirements, and communication templates. Use it when monitoring flags suspicious authentication patterns, users report credential compromises, or you detect unusual Microsoft 365 session activity.

Prerequisites

Before executing this playbook, ensure you have:

• Identity infrastructure access: Admin rights to your identity provider (Azure AD/Entra ID, Okta, etc.) for session revocation.
• SIEM or logging platform: Centralized authentication logs with at least 90-day retention to support investigation timelines.
• Communication channels: Pre-established incident notification paths to affected users, management, and your incident response team.
• Authority matrix: Clear decision rights for session termination and account lockouts, documented in your incident response plan.

The Response Playbook

Phase 1: Initial Triage (First 15 Minutes)

Triggering indicators:

• User reports receiving an unexpected authentication prompt.
• SIEM alerts on authentication from unusual geolocations.
• Multiple failed MFA attempts followed by successful authentication.
• Session established from unknown IP addresses.

Triage questions:

1. What service did the authentication request target?
2. Did the user approve an MFA prompt during the suspected timeframe?
3. What domain hosted the initial lure?
4. Did the user click through any redirects involving legitimate sign-in endpoints?

Immediate actions:

1. Do not notify the user through potentially compromised channels.
2. Capture current session metadata:
   • Active session IDs
   • IP addresses with active tokens
   • OAuth grants and application permissions
   • Last successful authentication timestamp
3. Screenshot authentication logs before containment.
4. Preserve email headers if the phishing lure is available.

Phase 2: Containment (Minutes 15-30)

Revoke active sessions:

• Navigate to Users > [affected user] > Devices in Azure AD/Entra ID.
• Select "Revoke sessions" to invalidate all refresh tokens.
• Document session IDs terminated in the incident ticket.

For OAuth applications:

• Review "Users can consent to apps accessing company data" in Azure AD.
• Audit recent OAuth grants and revoke suspicious ones immediately.

Reset credentials:

• Force a password reset.
• Require re-registration of MFA methods if the attacker had session access for over 10 minutes.
• Disable the account if you can't reach the user for verification within 1 hour.

Network-level blocks:

• Add attacker IP addresses to deny lists.
• Block identified lure domains at the DNS or web proxy layer.
• Document block actions with timestamps for audit evidence.

Phase 3: Investigation (Hours 1-4)

Evidence collection checklist:

• Authentication logs: 48 hours before and 24 hours after the incident.
• Email message headers from the phishing lure.
• User's browser history, if accessible.
• OAuth application consent history.
• Conditional Access policy evaluation logs.
• Any automated response actions by DLP or CASB tools.
• Session duration and accessed resources during the compromise.

Scope determination:

• Query authentication logs for the lure domain across all users.
• Search email logs for similar sender patterns or subject lines.
• Check if other users clicked the same lure.
• Review accessed resources: mailboxes, SharePoint sites, admin consoles.

Root cause analysis:

• Identify which security control failed.
• Determine if existing controls generated unacted alerts.
• Evaluate if additional controls could've prevented or detected the attack faster.

Phase 4: Communication

User notification template:

Subject: Security Incident - Immediate Action Required

[User name],

We've detected unauthorized access to your [service] account. Your session has been terminated and your password reset as a precaution.

Required actions:
1. Reset your password using this link: [password reset portal]
2. Re-register your MFA device: [MFA enrollment portal]
3. Do not click links in emails claiming to be from [service] without verifying the sender domain
4. Report any unusual account activity to security@[company].com

This incident is being investigated. Do not discuss details outside the incident response team.

[Security team contact]

Management briefing template:

Incident: Session-theft phishing targeting [service]
Affected users: [count] confirmed, [count] potential
Containment status: Complete as of [timestamp]
Data access: [Specify what attacker could have accessed]
Business impact: [Service disruption, if any]
Next steps: [Investigation timeline, control improvements]
Audit implications: [If applicable - e.g., "Documenting as security incident per ISO/IEC 27001 control 5.28"]

How to Customize This Playbook

Adapt to your identity architecture:

• Replace Azure AD steps with your IdP's session revocation process.
• Add steps for on-premises Active Directory if you operate hybrid identity.
• Include your CASB in the containment workflow.

Integrate with your ISMS:

• Reference your specific incident classification scheme.
• Link to your organization's escalation matrix.
• Add notification requirements for specific incident severity levels.

Scale for your team size:

• Organizations under 100 users: Combine Phase 2 and Phase 3 for a single responder.
• Mid-size teams: Assign Phase 1-2 to an on-call engineer, Phase 3 to a security analyst.
• Large organizations: Coordinate with regional SOC teams.

Validation Steps

Test this playbook quarterly through tabletop exercises. Your drill should:

1. Simulate the trigger by sending a test alert to your on-call rotation.
2. Execute containment by performing session revocation on a test account.
3. Measure response time from triage to containment; aim for under 30 minutes.
4. Review evidence collection to ensure you can retrieve the necessary logs.
5. Test communication by sending notification templates to test distribution lists.

Document each test as evidence of control effectiveness for ISO/IEC 27001 control 5.24 and SOC 2 CC7.4. Your auditor will ask for proof you've tested incident response procedures.

After each real incident or drill, update this playbook. The tactics will evolve, but the response structure remains: triage, contain, investigate, communicate, improve.