An identity-based attack is an attempt to gain unauthorized access by compromising or misusing human or non-human identities, credentials, authentication mechanisms, or active sessions. Attackers may target passwords, multifactor authentication (MFA) approvals, service credentials, authentication tokens, or active browser sessions. Account takeover is one possible outcome, but identity attacks also include unsuccessful attempts to obtain or abuse access.
Identity security therefore extends beyond employee passwords. It covers administrators, service accounts, service principals, managed identities, application credentials, and authenticated sessions.
Key Takeaways
- Identity-based attacks target human and non-human identities by stealing or misusing credentials, authentication tokens, sessions, and access privileges.
- Common attack methods include phishing, credential stuffing, password spraying, MFA fatigue, session theft, Kerberoasting, and service-credential abuse.
- Warning signs include unusual sign-ins, repeated MFA prompts, unexpected privilege changes, suspicious sessions, and abnormal service-account activity.
- Prevention requires layered controls, including phishing-resistant MFA, conditional access, least privilege, credential management, and continuous monitoring.
- Incident response should focus on containing unauthorized access, revoking compromised sessions, rotating credentials, removing persistence mechanisms, and verifying recovery.
What are identity-based attacks?
Identity-based attacks exploit the systems and information used to decide who or what may access a resource. Instead of attacking an application vulnerability directly, an attacker may sign in with stolen credentials, persuade a user to approve an MFA request, or reuse an authenticated session.
The attacker’s goal and level of access vary. A compromised employee account might expose email and cloud files. An administrator account could enable security-policy changes or the creation of new privileged users. A service identity might provide automated access to databases, application programming interfaces (APIs), or production workloads.
The central problem is that activity performed through a valid identity can initially resemble legitimate use. Defenders must evaluate not only whether authentication succeeded, but also whether the device, session, location, permissions, and subsequent behavior are expected.
Common identity-based attack methods
Phishing, credential stuffing, and password spraying
These methods can all lead to unauthorized sign-ins, but they work differently:
- Phishing attempts to trick a person into disclosing credentials, visiting a fraudulent sign-in page, or approving an attacker-initiated action.
- Credential stuffing tests username-password combinations obtained from previous data exposure. It is most effective when people reuse passwords across services.
- Password spraying tests a small number of likely passwords against many accounts. Spreading attempts across accounts can reduce the likelihood of triggering controls based only on repeated failures for one user.
CISA distinguishes credential stuffing from password spraying, which matters during investigation. A large number of failed passwords for one account suggests a different pattern from low-volume failures spread across many accounts.
MFA fatigue and stolen sessions
MFA fatigue, also called push bombing, uses repeated unsolicited authentication prompts to pressure or confuse a user into approving one. Users should deny and report any request they did not initiate. Repeated prompts may mean an attacker already has the password and is attempting to satisfy the remaining authentication step, according to a joint cybersecurity advisory on brute-force and MFA push-bombing activity.
Session theft takes a different route. If an attacker obtains a valid session cookie or token, the service may accept it because authentication requirements were satisfied when the session was created. The attacker may not need to enter the password or complete MFA again at that moment. Tokens still have limits—such as audience, scope, expiration, and platform enforcement—but their theft can provide immediate access to the resources they authorize. Microsoft’s token theft playbook recommends investigating associated devices, credentials, IP addresses, authentication changes, and privileges rather than treating the event as a password-only incident.
Privileged accounts, Kerberos abuse, and service credentials
Privileged identities create disproportionate risk because they can change configurations, grant access, manage devices, or administer identity systems. Organizations should separate routine user activity from administrative work and minimize standing privileges.
In applicable Microsoft Active Directory environments, attackers may also use Kerberoasting. An attacker with valid domain access can request Kerberos service tickets for accounts associated with service principal names (SPNs). Information from those tickets may then be subjected to offline password cracking, particularly when service-account secrets are weak or older encryption is in use. MITRE ATT&CK documents Kerberoasting as a Kerberos-specific technique; it does not apply to every service account or cloud identity system.
Non-human identities require equal attention. Service accounts, service principals, and managed identities perform automated work and may operate without direct user interaction. They should have a named owner, a documented purpose, minimal permissions, controlled credential handling, and a recurring review cycle. Where the application and platform support it, managed credentials can reduce dependence on manually maintained secrets. Microsoft’s service-account governance guidance emphasizes ownership, least privilege, credential management, and periodic review.
How one compromised identity becomes an organizational risk
The impact of a compromised identity depends on its privileges, reachable resources, session scope, and the organization’s ability to detect abnormal behavior.
An attacker who gains initial access may attempt to:
- Read email, files, messages, or application data available to the account.
- Add an authentication method, register a device, create a forwarding rule, or establish another form of persistence.
- Search for credentials, access tokens, sensitive records, or information useful for social engineering.
- Abuse group memberships, delegated permissions, or application consent.
- Move into connected applications or systems that trust the same identity.
- Target administrators, finance personnel, endpoint managers, or service identities with broader access.
A low-privilege account does not automatically create organization-wide compromise. Its blast radius depends on what the identity can reach and whether the attacker can obtain additional privileges. However, even limited mailbox or collaboration access can support impersonation and more convincing attacks against other users.
Warning signs to investigate
No single sign proves compromise. The strongest cases often come from correlating sign-in data, device information, authentication changes, session activity, and actions taken after access.
Unusual sign-ins, repeated MFA prompts, and password-spraying patterns
Investigate signals such as:
- Sign-ins from unfamiliar devices, locations, IP addresses, or user agents.
- Travel or timing patterns inconsistent with the user’s normal activity.
- Many failed sign-ins spread across multiple accounts from the same or related IP addresses, devices, user agents, or time window.
- A successful sign-in during or shortly after a password-spraying window.
- Unexpected MFA prompts, especially repeated requests.
- A user reporting an unfamiliar sign-in or an MFA request they denied.
- Successful access using an authentication method that is unusual for the account.
Microsoft’s password spray investigation guidance recommends correlating failures and successes with IP addresses, devices, users, and MFA reports. A successful sign-in hidden among many failures deserves particular attention.
Unexpected sessions, privilege changes, and service-account activity
Post-authentication changes may reveal activity that sign-in logs alone do not show. Review:
- Newly registered authentication methods or devices.
- Unexpected active sessions or token activity.
- New role assignments, group memberships, delegated permissions, or application grants.
- Mail forwarding, inbox, or deletion rules that the user did not create.
- Access to high-value applications that is unusual for the identity.
- Service accounts signing in interactively when they normally run only through an application or workload.
- Service-ticket requests, source systems, or usage times outside a service account’s established pattern.
- New credentials or certificates added to service principals.
Behavior must be judged against the identity’s purpose. An automation account may legitimately operate at unusual hours, but a new source host, interactive sign-in, or unexpected privilege change still warrants review.
Which defenses help against each attack method?
Identity attacks require layered controls because no single safeguard covers credential theft, authentication abuse, session theft, and privilege misuse.
| Attack method | Preventive controls | Detection and response focus | Important limitation |
|---|---|---|---|
| Phishing | Phishing-resistant MFA, user reporting, and controls that restrict weak authentication | Suspicious sign-ins, reported messages, new authentication methods, and post-sign-in activity | User awareness alone cannot prevent every convincing or automated attack |
| Credential stuffing | Unique passwords, exposed-credential controls, MFA, and sign-in throttling | Repeated attempts using known usernames, unfamiliar IP addresses, and successful access after failures | MFA reduces risk but does not address every session-theft or social-engineering path |
| Password spraying | Weak-password restrictions, smart lockout or rate limiting, MFA, and disabling legacy authentication | Low-volume failures spread across many accounts, followed by successful sign-ins | Controls focused on repeated failures for one account may miss distributed sprays |
| MFA fatigue | Phishing-resistant authentication and MFA methods that require stronger user intent | Repeated prompts, denied requests, and successful approval after several attempts | Simple approve-or-deny push prompts remain susceptible to user error |
| Session or token theft | Endpoint protection, device-aware access policies, short and appropriate session lifetimes, and secure application design | Token use from new devices, IP addresses, or user agents; privilege and persistence changes | A password reset may not immediately invalidate every application-controlled session |
| Privileged-account abuse | Separate administrator identities, minimal standing privilege, and tightly scoped role assignment | Role changes, unusual administrative actions, and access from unexpected devices | Strong authentication cannot prevent misuse after valid privileged access is obtained |
| Service-credential abuse | Named ownership, minimal permissions, controlled secrets, rotation, and managed identities where supported | New credentials, unusual source systems, interactive use, and out-of-pattern API activity | Credential-management options depend on the application and hosting platform |
| Kerberoasting | Strong service-account secrets, modern encryption where supported, managed service accounts, and least privilege | Unusual service-ticket requests and follow-on authentication activity | This mitigation applies to relevant Active Directory and Kerberos environments, not every identity platform |
Authentication controls and their limits
Prefer phishing-resistant MFA for sensitive and privileged access where the identity platform and applications support it. Push-based MFA is still stronger than relying on passwords alone, but repeated prompts can be socially engineered. Weak or legacy authentication paths can also undermine stronger methods if they remain available.
Password controls should address both reuse and guessing. Use unique passwords, prevent known weak or exposed passwords where the platform supports it, and apply rate limiting or smart lockout. Monitor for distributed attempts rather than relying only on per-account lockouts.
Authentication is only the start of the session. MFA does not prevent every form of endpoint compromise, token theft, malicious application consent, or misuse performed after a legitimate sign-in.
Least privilege, account reviews, and session monitoring
Limit the damage an identity can cause if it is compromised:
- Use separate accounts for routine work and administration.
- Minimize standing privilege and grant elevated access only for the required role and duration where supported.
- Review privileged roles, group membership, delegated permissions, and application grants regularly.
- Assign owners to service accounts and service principals.
- Remove unused accounts, credentials, permissions, and application integrations.
- Set credential expiration and review cycles appropriate to the platform and workload.
- Monitor sign-ins together with session, privilege, mailbox, application, and workload activity.
Access reviews should verify business need rather than simply confirm that an account still exists. For a non-human identity, reviewers should know which workload depends on it, who can modify it, where its credentials are stored, and what would break if access were removed.
How to prioritize protection across human and non-human identities
Do not assign every identity the same priority. Start with identities whose compromise could change security controls, expose sensitive resources, or provide a path to other accounts.
Prioritize identities using five factors:
- Privilege: Can the identity administer the identity provider, endpoints, cloud environment, security tools, production systems, or financial processes?
- Reach: Which applications, data, APIs, networks, and workloads can it access?
- Credential exposure: Does it use a user-managed password, a long-lived secret, a certificate, a managed credential, or an active session on a high-risk endpoint?
- Ownership and lifecycle: Is there a named owner, documented purpose, expiration date, and removal process?
- Monitoring coverage: Would the security team detect unusual sign-ins, new credentials, permission changes, or out-of-pattern activity?
The first protection tier should normally include identity-system administrators, highly privileged cloud and endpoint administrators, accounts that approve payments or access sensitive data, and non-human identities with broad API or production permissions. An unused service principal with a long-lived credential and no owner may deserve higher priority than an actively monitored employee account.
What to do when an identity may be compromised
Treat unexpected MFA approvals, suspicious token activity, unexplained privilege changes, and confirmed unauthorized sign-ins as potential active-access incidents. Follow the organization’s incident-response process and preserve relevant evidence.
Confirm and contain active access
- Contact the user or account owner through a trusted channel. Do not rely on the potentially compromised mailbox or messaging account for verification.
- Review recent sign-ins and alerts. Correlate times, devices, IP addresses, user agents, MFA results, and applications accessed.
- Block or disable access when the evidence and business impact justify it. Emergency actions should follow platform-specific procedures.
- Revoke refresh tokens and sign-in sessions where supported. Do not assume this reaches every application-controlled session.
- Reset passwords or rotate service credentials. Replace exposed secrets, keys, or certificates and update dependent workloads securely.
- Remove unauthorized authentication methods, devices, credentials, and delegated permissions. Check for attacker-created recovery or persistence mechanisms.
- Isolate affected endpoints when endpoint compromise or session theft is plausible. A clean password is insufficient if the device can steal the replacement credential or session.
Microsoft’s guidance for revoking user access in an emergency notes that applications may issue their own session tokens. The identity provider may not be able to revoke those cookies directly, so responders may need application-specific session termination or deprovisioning steps.
Scope affected accounts and privileges, then verify recovery
A password reset is a containment action, not proof that the incident is resolved. Review:
- Sign-ins before and after the first known suspicious event.
- Active sessions, refresh tokens, and application-controlled sessions.
- Authentication-method and device-registration changes.
- Role assignments, group memberships, delegated permissions, and application consent.
- Mail forwarding and inbox rules where relevant.
- Files, records, applications, and administrative resources accessed.
- Related accounts targeted from the same IP address, device, or attack window.
- Service credentials, certificates, API keys, and automation connected to the affected identity.
- Endpoints that may have exposed credentials or tokens.
Before closing recovery, responders should confirm that known unauthorized access and persistence have been removed, affected credentials have been replaced, dependent services have been validated, and monitoring has returned to expected patterns. Continue heightened monitoring for related accounts and resources according to the incident’s scope.
Once unauthorized access is contained and recovery is verified, organizations should strengthen the controls that can limit similar incidents. Scalefusion OneIdP supports this preventive approach through device-aware conditional access for configured applications and Just-in-Time (JIT) Admin capabilities for temporary privilege elevation on supported Windows and macOS devices. These controls complement authentication, access monitoring, and incident-response practices by helping IT teams apply contextual access policies and reduce unnecessary endpoint privileges.
FAQs
1. Is an identity-based attack the same as an account takeover?
No. Account takeover is one possible outcome. Identity-based attacks also include attempts to steal credentials, manipulate MFA, obtain authenticated sessions, abuse service credentials, or misuse access already granted to a valid identity.
2. Can an attacker get in without knowing a password?
Yes, in some circumstances. A stolen authenticated token or browser session may be accepted without the attacker entering the password again. A service identity may also authenticate with an exposed key, certificate, or other non-password credential. MFA fatigue is different: it often follows password compromise and attempts to obtain the remaining approval. None of these methods defeats every authentication control.
3. Who should investigate repeated MFA prompts?
The user should deny and promptly report any unexpected prompt. The security or identity team should then review the account’s sign-ins, MFA results, active sessions, registered authentication methods, devices, and subsequent activity. If a prompt was approved, responders should treat it as possible active compromise.
4. Why do service accounts need different oversight from employee accounts?
Service accounts perform automated work and may use long-lived permissions or credentials without routine human interaction. Each service identity needs a named owner, a defined purpose, minimal permissions, controlled credential handling, behavior-based monitoring, and a recurring review or expiration process. Unneeded access should be revoked without leaving dependent workloads in an unknown state.
