What are identity based attacks and how do you defend against them?

Identity based attacks gain access by using real credentials, tokens or sessions rather than exploiting software flaws. The attacker signs in, and so looks like a user. Defend with phishing resistant multi-factor authentication, short lived tokens, least privilege and monitoring of how accounts behave.

What do they look like?

MITRE ATT&CK describes Valid Accounts as adversaries obtaining and abusing credentials of existing accounts for initial access, persistence, privilege escalation or defense evasion. Compromised credentials can bypass access controls and give persistent access to remote services such as VPNs, web mail and remote desktop. The technique has sub-techniques for default, domain, local and cloud accounts.

Credentials are obtained in several ways. Brute force techniques, including password guessing, spraying and credential stuffing, try passwords against live services. Keylogging captures them as they are typed. Phishing tricks people into entering them. Leaked credentials from another breach are reused.

What about tokens and sessions?

Stealing a password is not the only route. ATT&CK describes Use Alternate Authentication Material, in which adversaries use password hashes, Kerberos tickets and application access tokens to move laterally and bypass normal system access controls. The sub-techniques are application access token, pass the hash, pass the ticket and web session cookie.

The reason is that systems cache proof that someone has authenticated, so they do not ask repeatedly. If an attacker holds the proof, the system does not ask for the password or the second factor. ATT&CK's Steal Web Session Cookie entry makes the same point: an adversary can gain access to web applications as an authenticated user without needing credentials, and cookies are often valid for a long time even when the app is not in use.

Adversary-in-the-middle techniques sit between a user and a service to capture credentials or tokens in transit, and are a route to both.

What defenses work?

ATT&CK's mitigations for Valid Accounts are a good checklist:

• Multi-factor authentication across all account types, including default, local, domain and cloud accounts, which significantly reduces the risk of abusing valid accounts even if credentials are compromised.
• Account use policies, such as conditional access that blocks sign-ins from non-compliant devices or outside defined ranges.
• Disable legacy authentication, which does not support MFA.
• Keep credentials out of code and storage, since published credentials in repositories or public cloud storage are a common source.
• Change default passwords on applications and appliances.

For session theft, ATT&CK suggests hardware tokens that include the target domain in the login negotiation, which blocks theft through proxy methods, conditional access that allows sign-in only from trusted devices, and monitoring for impossible travel and anomalous behavior. Shortening the life of tokens and cookies narrows the window.

A constructed example

An attacker buys a list of leaked email and password pairs and tries them against a company's cloud email. One employee reused a password, and sign-in succeeds because no MFA is required on legacy mail protocols. The attacker creates a forwarding rule and reads invoices. Blocking legacy authentication and requiring MFA would have stopped the sign in. Monitoring for new forwarding rules would have surfaced it within hours.

What about machine identities?

Service accounts, API keys and workload tokens are identities too, and they rarely have MFA. Give each its own scoped credential, rotate or expire them, avoid sharing them between systems and log their use. A key in a repository is an open door to whatever it can reach. Secrets scanning on code and pipelines catches many of these before they leave the building, and the same principle applies to AI agents that act with credentials.

How to check or apply this

1. Inventory human and machine identities and who owns each.
2. Require MFA everywhere, starting with admin, email and remote access, and prefer phishing resistant methods.
3. Block legacy authentication protocols.
4. Set token and session lifetimes as short as users can tolerate.
5. Add conditional access based on device and location.
6. Scan code and pipelines for secrets, and rotate any that leak.
7. Alert on impossible travel, new forwarding rules and unusual privilege grants.

Quick check

Sources

• MITRE ATT&CK T1078, Valid Accounts
• MITRE ATT&CK T1550, Use Alternate Authentication Material
• MITRE ATT&CK T1539, Steal Web Session Cookie
• MITRE ATT&CK T1557, Adversary-in-the-Middle

Last reviewed: 18 October 2026.