Expert Briefing: Detect, Respond and Recover From Identity-Led Attacks

About this briefing

An attacker who signs in with a valid credential, a stolen session or a consented OAuth application does not trip the alarms built for malware and exploits. The activity looks like a user doing their job. That is why identity-led attacks can stay in an environment for so long, and why most detection programs cannot say how much of this behavior they would actually catch.

This briefing works through the full cycle: what to detect, what response steps remove an attacker who has legitimate access, and what must be rebuilt before identity can be trusted again. It draws on documented incidents and published vendor and government guidance, not on hypothetical threat models.

Why identity is where detection programs run out of road

Verizon’s latest Data Breach Investigations Report finds that vulnerability exploitation has moved ahead of stolen credentials as the most common way into an environment. Identity is no longer the single leading front door. In our assessment it remains the connective tissue: whatever the entry point, an attacker needs credentials, tokens or privileges to move, reach data and stay.

Four documented patterns show how that plays out, and why each one is hard for conventional detection.

Detect: from logs to measurable coverage

Most identity telemetry is collected. Less of it becomes detections, and almost none of those detections is tested. A practical starting point is to list the attacker behaviors above and ask, for each one, which log source shows it, which rule would fire, and when that rule last fired against a test.

Make coverage measurable

Coverage becomes measurable when each rule maps to a technique and each mapping has been tested. MITRE ATT&CK supplies the shared vocabulary: valid accounts (T1078), steal application access token (T1528), web session cookie (T1550.004), multifactor authentication request generation (T1621) and modify authentication process (T1556) cover most of the behaviors in the table. We suggest four measures, offered as a recommendation and not as an industry benchmark:

• The share of in-scope identity providers and SaaS platforms whose audit logs reach the detection platform.

• The share of mapped techniques with a rule that has been exercised by a test in the current review cycle.

• The time from the malicious event to a triaged alert, measured in tests and not estimated.

• The share of identity alerts that analysts close as benign, which is a direct read on rule quality.

Respond: removing an attacker who holds legitimate access

Disabling an account is the instinctive first move and is rarely enough. What survives it depends on the platform, and responders who do not know the answer in advance will find out during the incident.

• Tokens outlive the password. Microsoft’s documentation on continuous access evaluation says standard access tokens last one hour by default, while clients that support continuous access evaluation can hold tokens for up to 28 hours, with revocation enforced on critical events such as account disablement, a password reset or an explicit refresh token revocation. Enforcement typically lands within minutes and can take up to 15. Responders need to know which applications are covered and should revoke sessions explicitly instead of assuming a reset ends access.

• Consent outlives the user. An OAuth grant stays in place after the account that approved it is reset. Containment has to include listing and removing malicious application registrations, service principal credentials and consent grants, and reviewing application-only permissions.

• Identity-layer persistence survives resets. CISA describes attacker-registered MFA methods and added federated identity providers that let the actor sign in as any user after passwords change. The response plan must cover the identity provider’s own configuration, not only the affected accounts.

• The help desk is part of the incident. If the attack began with a social engineering call, the reset procedure that failed is itself an exposure. An interim step is out-of-band verification for credential and MFA resets on privileged and high-risk accounts.

• Assume the attacker is watching. CISA reports Scattered Spider actors monitoring victim email and chat and joining response calls. When identity may be compromised, coordinate the response outside the affected environment.

Recover: rebuilding trust in identity

Recovery is complete when you can show that the attacker’s access paths are closed, not when accounts work again.

1. Rotate every secret the compromised identity could reach. For the Drift campaign, Google advised revoking and rotating integration tokens and credentials and scanning the exposed data for secrets such as cloud access keys, passwords and tokens, because the actor searched for exactly those.

2. Reset the krbtgt password twice after an Active Directory compromise. Microsoft’s guidance is to wait at least the maximum ticket lifetime between resets (10 hours by default) so that tickets and keys issued under the old password stop working.

3. Re-establish MFA through verified, out-of-band identity proofing. Do not let users re-enroll through the same weak process that was abused.

4. Compare federation trusts, application registrations, service principals and conditional access policies with a known-good baseline.

5. Close the gap the attacker used. Enforce MFA on legacy and test accounts, restrict user consent to applications, and move privileged users to phishing-resistant authentication such as FIDO or PKI-based methods, which CISA identifies as resistant to push bombing and SIM swapping.

6. Re-run the detection tests for the behaviors observed. If the rule that should have fired did not, fix it before the incident is closed.

Briefing outline

What readers take away

• A behavior-to-telemetry map covering six identity attack behaviors

• Four coverage measures that can be reported to leadership

• A containment checklist for identity incidents that goes beyond account disablement

• A recovery sequence that ends with tested detection, not just restored access

Questions to bring

• Which identity providers and SaaS platforms feed your detection platform, and which do not?

• When did a rule for token or consent abuse last fire in a test?

• Can your team revoke all sessions for a privileged group without waiting on an approval chain?

• Who verifies a caller who asks the help desk to reset MFA?

Use this briefing to strengthen detection of identity-led attacks. A practical first step is the behavior table above: score each row for log source, rule and last test, and bring the gaps. Teams that want an outside view of that scoring can start a conversation with Cybrilliant’s identity security specialists.

Related Reading

OAuth Abuse and Consent Attacks

Threat analysis of how malicious consent works and what it grants an attacker.

Session Theft: The New Battle After Authentication

Threat analysis of what happens once a valid session is in the wrong hands.

Stolen Credentials in SaaS Environments

Threat analysis of credential abuse against SaaS platforms.

Playbook: Investigating Suspicious OAuth Activity

A practitioner field note for investigating the consent and token behaviors covered here.

After Authentication: What Should Security Monitor?

Technical explainer on the monitoring that has to continue once a user is signed in.

Sources

1. Microsoft Security Blog. Midnight Blizzard: Guidance for responders on nation-state attack. microsoft.com/security/blog

2. Google Threat Intelligence Group. Report on the Salesloft Drift OAuth token compromise (UNC6395). cloud.google.com/blog/topics/threat-intelligence

3. CISA and FBI. Joint cybersecurity advisory on Scattered Spider. cisa.gov

4. MITRE ATT&CK. Techniques T1078, T1528, T1550.004, T1556 and T1621. attack.mitre.org

5. Microsoft Learn. Continuous access evaluation in Microsoft Entra. learn.microsoft.com

6. Microsoft Learn. Active Directory forest recovery: Reset the krbtgt password. learn.microsoft.com

7. Verizon. Data Breach Investigations Report, latest edition. verizon.com/business/resources/reports/dbir