Incident Response Runbook: Credential Compromise & Session Hijack

Credential compromise rarely announces itself. Ransomware comes with a note; credential theft comes with a successful login from an unexpected IP, an invoice approved by someone who was asleep, or a customer calling to ask why you sent them a strange email. Session hijack is even quieter: the adversary does not need the password because they have the authenticated session cookie. By the time a SOC analyst sees the anomaly, the threat actor has typically been inside for days or weeks.

This is the runbook for credential compromise and session hijack incidents. It is structured for the Indian enterprise or mid-market SaaS environment. If you are running this during an active incident, start at containment and loop back for preparation and post-incident work.

What counts as credential compromise vs session hijack

The two overlap but are distinct in response.

• Credential compromise: The adversary has the username and password. Typical vectors: phishing, infostealer malware, credential stuffing, password reuse from a third-party breach. The attacker can authenticate from scratch.
• Session hijack: The adversary has a valid session token or cookie, not the password. Typical vectors: stolen browser cookies, token theft from compromised endpoints, adversary-in-the-middle phishing frameworks that relay tokens, OAuth consent grant attacks. MFA was already satisfied at the time of session creation; the attacker inherits that authenticated state.

A session hijack that results in persistent access (for example, establishing a new OAuth refresh token or enrolling an attacker-controlled MFA method) effectively becomes a credential compromise. Treat the two as a spectrum with shared containment primitives.

Preparation: controls that make response possible

• Single identity provider (Okta, Azure AD, Google Workspace, Ping) as the source of truth for all production access.
• Phishing-resistant MFA (FIDO2, WebAuthn) for at least privileged users. SMS and push-based MFA is bypassable by modern AitM phishing.
• Short token lifetimes and refresh constraints. Access tokens minutes, not hours. Refresh tokens require re-authentication periodically.
• Centralized authentication logs in a SIEM with retention of at least 12 months.
• Detection rules for impossible travel, unfamiliar device, unfamiliar IP ASN, new OAuth consent, new MFA method enrollment.
• Device posture checks for high-trust applications: require managed device, up-to-date OS, active EDR.
• Privileged access management for admins: separation of daily-use and admin accounts, just-in-time elevation.
• Break-glass admin accounts stored offline, used only during incidents.

Detection signals

A credential or session compromise typically produces one or more of these signals. Your SIEM or IdP should alert on them.

• Successful authentication from a country or ASN the user has never used.
• MFA bypass attempt or unusual MFA challenge fatigue pattern.
• Sign-in with a new device for a privileged account.
• New MFA method enrolled shortly after a sign-in from an unfamiliar location.
• OAuth application consent granted to an unknown or newly registered app.
• Inbox rule created that forwards mail to an external address or deletes alerts.
• Password reset for a privileged account followed by unusual activity.
• User reports their session ended unexpectedly or they see unfamiliar active sessions.
• SIEM detection: concurrent sessions for a user from disparate geographies.

Hour 0 to 1: Triage and declaration

1. Analyst correlates signals. Determine whether this looks like credential compromise, session hijack, or both.
2. Escalate to the incident commander. Open an incident channel.
3. Freeze the account immediately. Disable in the IdP; do not merely force a password reset, because a session hijack survives password resets in many systems.
4. Revoke all active sessions for the account across the IdP and critical downstream applications.
5. Capture the user’s own report of what they did or did not do. Note: do not accuse; investigate.

In session hijack incidents, password reset alone is insufficient. You must revoke tokens, end active sessions, and verify no attacker-controlled MFA or OAuth consents remain. Attackers routinely persist through password resets.

Hour 1 to 4: Scoping and containment

What the user did

• Pull sign-in logs from the IdP for the affected account for at least 30 days.
• Identify all IPs, devices, user agents, and locations. Separate legitimate from suspicious.
• List every downstream application the user accessed during the suspicious window.

What the attacker did

• List every action taken by the account from the suspicious sign-in time to containment.
• Check for new MFA methods, new OAuth consents, new app passwords, new personal access tokens, new session cookies issued.
• Check for mail rules, file share accesses, download volumes, external sharing of files.
• Check for any privilege changes: role grants, group memberships, delegated admin.
• Check for any provisioned API keys or service account tokens tied to the user.

Containment

• Revoke all active sessions, everywhere.
• Revoke OAuth consents for the user in IdP and connected apps.
• Remove attacker-added MFA methods; re-enroll the user after identity verification.
• Rotate any API keys, personal access tokens, or app passwords the user held.
• If the user is a developer, rotate any secrets they could have access to (cloud credentials, SSH keys, git tokens).
• If a session was hijacked from a specific device, isolate that device for forensics.

Hour 4 to 24: Lateral movement check and notifications

Lateral movement

A compromised identity rarely stops at one account. Check:

• Any accounts the compromised user could have reset passwords for (helpdesk, manager, delegated admin).
• Any service accounts the user had access to rotate or retrieve credentials for.
• Any shared admin accounts the user could access.
• Cloud and SaaS audit logs for actions taken by the compromised user across all environments.

Regulatory notifications (India)

• CERT-In must be notified within 6 hours of noticing. Credential compromise of a system with significant user base or business impact is reportable.
• If personal data is accessed during the incident, DPDP Act breach notification to the Data Protection Board and affected data principals applies.
• Sector regulator obligations (RBI, SEBI, IRDAI) where applicable.

User notifications

If the compromised user accessed customer data during the attacker’s window, affected customers may need notification depending on data categories and contractual obligations. Work with legal counsel on timing and content.

Day 1 to 7: Eradication and recovery

• Complete identity verification for the user (ideally in person or via video call with ID check) before restoring access.
• Rotate credentials for any secret the user ever touched during the suspicious window.
• Remove any persistence the attacker established: new accounts created, new API tokens, forwarding rules, OAuth apps.
• Restore the user’s access with fresh credentials, fresh MFA enrollment, and device posture re-checked.
• Monitor the user’s account intensively for at least 30 days after incident closure.

Common mistakes in credential incidents

• Password reset without session revocation. The hijacked session often survives the reset.
• Not rotating secondary secrets. API tokens the user held are still valid if not rotated.
• Missing the OAuth persistence. A granted OAuth consent to a malicious app can survive password reset, session revocation, and MFA changes.
• Assuming MFA means the account is safe. Modern AitM phishing relays MFA. MFA bypasses are common.
• Not checking other users. A single credential compromise often reveals a phishing campaign affecting dozens of users.

Post-incident actions

Related reading

• IR runbook — ransomware (enterprise)
• IR runbook — data exfiltration under DPDP
• AWS IAM best practices — least privilege
• Kerberoasting 2026 — practitioner playbook
• DPDP breach notification — 72-hour playbook

Work with RingSafe

RingSafe builds identity incident playbooks, hardens IdP configurations against modern AitM phishing, and runs tabletop exercises for credential compromise scenarios. Founder Manish Garg (Associate CISSP, CEH, CCNP Enterprise) and the RingSafe team have responded to credential incidents in BFSI, SaaS, and regulated industries across India.

If your last phishing test had a double-digit click rate or your IdP still relies on SMS MFA, book a scoping call and we will help you close the identity gaps before an attacker does.