Top 10 Identity Attacks

Most serious intrusions now start by logging in rather than breaking in, using a stolen password, a replayed session, a tricked help desk or a leaked machine credential. This list ranks the ten identity attacks defenders meet most often, from phishing that defeats one-time codes to secrets leaked from code and pipelines. For each one it gives the defensive view: what the attack achieves, the signals that reveal it and the controls that prevent it, mapped to MITRE ATT&CK. It is written for identity, SOC and security architecture teams and contains no attacker procedures.

The Top 10 at a glance

The ranking weighs how often each attack appears in government advisories and in the incidents recorded on NHI Mgmt Group, and how much access a single success gives. Human and non-human identities are both covered, because attackers move freely between them.

1. Adversary-in-the-middle phishing

The attack: a phishing page relays the real sign-in in real time, so the victim completes MFA and the attacker captures the resulting session. One-time codes and push approvals do not stop it.

Detect: sign-ins from an IP or ASN that differs from the session's later use, Entra ID Protection risk detections such as anomalous token and unfamiliar sign-in properties, and newly created inbox rules after a sign-in.

Prevent: CISA identifies FIDO/WebAuthn and PKI-based MFA as phishing-resistant because the credential is bound to the real site. Require them for administrators first. See the AiTM Phishing Guide and Phishing-Resistant MFA Guide.

2. Help desk and voice social engineering

The attack: a caller impersonates an employee or IT staff and persuades the service desk to reset a password or MFA method. The CISA and FBI advisory on Scattered Spider (AA23-320A) describes exactly this against large companies and their outsourced help desks.

Detect: password and MFA resets followed within minutes by a sign-in from a new device or location, resets of privileged accounts, and repeat calls about the same user.

Prevent: verify callers through a channel the attacker does not control (manager approval, video check against ID, call back to a registered number), and require in-person or stronger proof for privileged accounts. The Marks and Spencer cyberattack began with impersonation of a third-party user. See the Account Recovery and Help Desk Security Guide.

3. MFA fatigue and push bombing

The attack: with a valid password, the attacker sends repeated push prompts until the user approves one, sometimes with a phone call claiming to be IT.

Detect: many denied or timed-out push requests for one user in a short window, followed by an approval; users reporting unexpected prompts.

Prevent: CISA states that push without number matching is vulnerable to push bombing, and that number matching resists it. Turn number matching on, rate-limit prompts, give users a "report suspicious" option, and move to phishing-resistant MFA. The Uber breach and Cisco breach both involved repeated prompts. See the MFA Fatigue and Bypass Guide.

4. Credential stuffing and password spraying

The attack: stuffing replays username and password pairs leaked from other sites; spraying tries a few common passwords across many accounts to stay under lockout limits.

Detect: spikes in failed logins across many accounts from few sources, or from many residential IPs; the OWASP Credential Stuffing Prevention Cheat Sheet also recommends alerting on a correct password followed by a failed MFA check.

Prevent: MFA on every externally reachable sign-in, including legacy protocols and service portals; breached-password checks; graduated responses (CAPTCHA, throttling) rather than IP blocking alone. The Snowflake breach used infostealer credentials on accounts without MFA, and the 23andMe breach was credential stuffing. See the Password Spraying and Credential Stuffing Defence Guide.

5. Session token and cookie theft

The attack: infostealer malware, AiTM kits or appliance flaws take session cookies or refresh tokens. Microsoft's token theft playbook notes that a replayed token carries the MFA the user already completed, so no new challenge appears.

Detect: one session used from two distant locations, unfamiliar non-interactive sign-ins, and on Windows, suspicious access to the Primary Refresh Token.

Prevent: bind tokens to devices (Conditional Access token protection), continuous access evaluation, shorter session lifetimes for sensitive apps, and endpoint protection against infostealers. The CitrixBleed incident showed stolen sessions bypassing MFA. See the Token and Session Security Guide.

6. Leaked NHI secrets and API keys

The attack: access keys, tokens and connection strings committed to repositories, baked into container images or left in .env files are found and used. No phishing is needed and MFA does not apply.

Detect: secret scanning alerts, use of a key from an unexpected IP or region, and first use of a long-dormant credential.

Prevent: GitHub push protection blocks secrets before they reach a repository, but repository-level push protection is off by default and must be enabled. Replace static keys with short-lived, workload-issued credentials and rotate on exposure. See the exposed .env files campaign, the Secrets Management Guide and the Leaked Credential Response Playbook.

7. OAuth consent phishing and token abuse

The attack: users are tricked into granting a malicious app access to mail or files, or attackers steal the OAuth tokens of a trusted integration. Password resets do not revoke the grant.

Detect: new consent grants with high-impact scopes, apps from unverified publishers, and integration tokens used from new infrastructure.

Prevent: in Entra ID, Microsoft recommends allowing user consent only for verified publishers and low-impact permissions (policy microsoft-user-default-low), with the admin consent workflow for everything else; existing grants must be reviewed separately. The Salesloft Drift breach used stolen integration tokens. See the SaaS and OAuth App Governance Guide.

8. Kerberoasting

The attack: any domain user can request service tickets for accounts with service principal names and try to crack the service account password offline. Weak, old service account passwords and RC4 encryption make it practical.

Detect: Microsoft documents event IDs 4768 and 4769 on domain controllers, with ticket encryption type 0x17 indicating RC4. A burst of 4769 requests with RC4 from one account is a strong signal.

Prevent: group managed service accounts, long random passwords for remaining service accounts, and AES only through the "Network security: Configure encryption types allowed for Kerberos" policy. Microsoft says Windows Server 2025 domain controllers do not issue RC4 TGTs and planned to stop assuming RC4 by default by the end of the second quarter of 2026. See the Kerberos Security Guide.

9. Golden tickets, DCSync and forged tokens

The attack: once an attacker holds domain replication rights or signing keys, they can pull password hashes (DCSync), forge Kerberos tickets with the krbtgt key, or forge SAML tokens with a stolen token-signing certificate. Access then survives password resets.

Detect: directory replication requests from non-domain-controller hosts, tickets with abnormal lifetimes, and federated sign-ins with no matching IdP authentication event.

Prevent: treat domain controllers, AD FS and signing keys as Tier 0, limit replication rights, store signing keys in HSMs, and reset krbtgt twice after any compromise. The SolarWinds compromise used forged SAML tokens. See the Golden Ticket, Silver Ticket and DCSync Guide.

10. MFA and device registration persistence

The attack: after initial access, attackers register their own MFA method or device, or add a federated identity provider, so they keep access after the password is changed. CISA lists both MFA token registration and adding a federated IdP in AA23-320A.

Detect: new MFA methods or devices registered shortly after a risky sign-in or a help desk reset, and any change to federation or domain trust settings.

Prevent: require strong authentication or a Temporary Access Pass to register methods, restrict device join, alert on every federation change, and include method and device review in every compromise response. See the Identity Incident Response Playbook.

Mapping to MITRE ATT&CK

Map detections to these IDs in your SIEM so coverage gaps are visible. NIST SP 800-53 IA-2(1) (MFA for privileged accounts), IA-5 (authenticator management) and AC-7 (unsuccessful logon attempts) cover the core preventive controls.

Where to start

1. Phishing-resistant MFA for administrators and help desk staff: it addresses attacks 1, 3 and part of 4 for the accounts that matter most.
2. Fix the reset process: strong caller verification and alerts on resets followed by new-device sign-ins.
3. Close MFA gaps: legacy protocols, service portals and third-party platforms without MFA.
4. Scan for secrets and enable push protection: then rotate what you find and move workloads to short-lived credentials.
5. Lock down consent and Kerberos: restrict user consent, review existing grants, remove RC4 and convert service accounts to gMSAs.
6. Build identity detections: see the ITDR Guide and the Identity Attack Paths Guide.

Related NHI Mgmt Group resources: Top 10 Phishing Techniques · Top 10 MFA Mistakes · ITDR Guide · Top 10 Secrets Management Mistakes