How attackers exploit identity: the identity attack surface

by
Dawid Winiarski
Last update:
July 17, 2026

The perimeter is gone. Most environments now spread across cloud platforms, SaaS applications, remote endpoints, and contractor portals. What holds them together is identity. And identity has become the primary target.

This guide is for IT leads, security managers, and anyone responsible for an organization's access environment. It does not assume a dedicated security team or enterprise tooling. It assumes you want to understand how the attacks actually work, what to look for, and what stops them.

Each section covers one attack type: how it works in practice, the signals it tends to produce, and the control that most directly addresses it. The guide ends with the thread that connects all of them: you cannot defend an attack surface you cannot see.

  • Identity has replaced the network perimeter as the primary attack surface. Most breaches begin with a compromised credential, not a network exploit.
  • The use of stolen credentials was involved in 36% of breaches (Verizon DBIR). Attackers follow the path of least resistance, and unprotected accounts, weak MFA, and stale access are consistently that path.
  • Each attack technique produces observable signals. The problem is usually visibility, not the absence of signals.
  • Most controls are not exotic. MFA, least privilege, session limits, monitoring, and clean offboarding address the majority of the techniques here. MFA blocks more than 99.2% of account-compromise attacks (Microsoft).
  • The common factor across nearly every technique is access that exists when it should not: former employees with live credentials, service accounts with broad permissions, admin accounts used for daily tasks.
  • Visibility comes first. A risk map of your identity environment is the prerequisite for prioritizing any of the controls in this guide.

why identity is the primary attack surface

The network perimeter has fragmented. Work happens across SaaS applications that live outside the corporate network, cloud infrastructure in environments the perimeter never touched, and contractor portals that were never fully under IT control. What connects all of these environments is identity: a username and password, a session token, a federated assertion.

Verizon's DBIR puts the use of stolen credentials as a factor in 36% of breaches. Credentials are the most reliable and reusable path into an environment. A stolen credential works on every system the account has access to. It does not set off network alarms. It looks like normal user activity until it does not. Identity is now where attacks begin, where they propagate, and where defenses need to concentrate.

phishing and credential theft

How it works. Phishing is the most common starting point. An attacker sends a message that appears to come from a trusted source and persuades the target to enter credentials into a fake login page, download malware, or take an action that grants access. More targeted variants, known as spear-phishing, are crafted with personal detail. The most targeted campaigns focus on executives and finance staff.

Warning signs. Login events from unusual geographies or devices shortly after a credential-entry event. Authentication from two locations within a physically impossible time window. Accounts attempting logins to systems they have not accessed before.

The control. Phishing-resistant authentication removes the credential as a takeable object. FIDO2 and passkeys bind the authentication response to the specific legitimate domain, so a credential captured on a fake page does not work on the real one. MFA blocks more than 99.2% of account-compromise attacks (Microsoft). Security awareness training reduces success rates, but is not a substitute for technical controls.

credential stuffing

How it works. When data breaches expose username and password pairs, those credentials are sold and reused systematically against other services. Bots iterate through lists of stolen credentials against a login endpoint until a match is found. The attack works because many people reuse passwords across accounts. At scale, even low success rates produce significant numbers of compromised accounts.

Warning signs. High volumes of failed logins against the same endpoint over a short period. Multiple failed attempts from geographically distributed IP addresses. Successful logins from IP ranges previously associated with failed attempts.

The control. Bot detection and rate limiting make automated iteration impractical. MFA breaks the attack even when the password is correct. Checking your domains against breach databases identifies accounts with credentials currently in circulation.

brute force and password spraying

How it works. Direct brute force tries every possible password combination. More practical variants matter more. Password spraying tries one commonly used password against many accounts, moving slowly enough to stay beneath per-account lockout thresholds. Offline brute force applies when an attacker has obtained a hashed password database and can attempt to reverse the hashes at high speed on their own systems, with no lockout policy in play.

Warning signs. A pattern of single failed login attempts spread across many accounts, often at off-hours. For offline attacks, the warning sign is the underlying data breach that exposed the hash file.

The control. Account lockout addresses direct brute force. Detection rules for the one-attempt-per-many-accounts pattern address spraying. MFA renders a guessed password insufficient on its own.

initial access brokers

How it works. Initial access brokers gain access to organizations and sell that access rather than exploiting it themselves. They focus on repeatable techniques, particularly legacy remote access systems, unpatched VPNs, and MFA bypass paths. The access is then sold to other actors, often ransomware operators. The buyer purchases a working credential or session and begins from there.

Warning signs. Authentication from unusual times, devices, or locations that do not match established patterns. Access to systems the account has not previously used. Credential use that cannot be correlated with a known user action.

The control. Patch public-facing systems promptly. Require MFA on all remote access paths. Restrict VPN access to enrolled and managed devices. Monitor authentication from outside established patterns.

MFA fatigue and bypass

How it works. An attacker with a valid password initiates repeated MFA push requests, generating a stream of notifications until the target approves one by accident or frustration. Adversary-in-the-middle (AiTM) proxies capture both the credential and the session token in real time, bypassing MFA entirely. SIM swapping redirects a phone number to an attacker-controlled SIM, exposing SMS-based codes.

Warning signs. Multiple MFA push requests in rapid succession the account owner did not initiate. Authentication completions at unusual times or from unusual locations.

The control. Number-matching push authentication requires the user to confirm a displayed code before approving, making accidental approval much harder. FIDO2 hardware keys and passkeys are not vulnerable to AiTM proxies because authentication is bound to the origin domain. Replace SMS MFA with an authenticator app or hardware key to remove the SIM-swap attack path.

session hijacking and token theft

How it works. After a successful authentication, systems issue tokens or cookies that represent the active session. If an attacker obtains one, they can access systems without the original credentials or MFA. Tokens can be stolen from browser storage through malicious extensions, intercepted on untrusted networks, or extracted from compromised endpoint memory. Token theft is post-authentication: it operates within a session that was already legitimately established, which is why MFA alone does not fully address it.

Warning signs. Session activity from locations that do not match prior patterns. Tokens in use well after the expected activity window. Concurrent sessions from multiple distinct locations for the same account.

The control. Short-lived tokens reduce the window during which a stolen token is useful. Binding tokens to device or IP context makes them invalid from a different context. HTTPS and HSTS headers reduce interception risk in transit. Endpoint security that detects malicious browser extensions addresses the theft vector at source.

privilege escalation and misuse

How it works. Privilege escalation moves from a lower-privilege account to a higher one by exploiting misconfigurations, excessive permissions, or using one compromised account to reach another with broader rights. Privilege misuse is different: an attacker operating within the bounds of what a compromised account already has can cause significant damage if that account was over-privileged. An analyst account that retained admin rights from a previous role, or a contractor account with write access to production, represents misuse risk without any escalation step. MITRE ATT&CK documents privilege escalation as one of the most reliably observed tactics in real breaches, typically appearing shortly after initial access.

Warning signs. Access to resources outside the account's normal activity. Multiple access-denied errors followed by successful access to the same resource via a different path. Changes to role assignments made by accounts not normally involved in access management.

The control. Least privilege: assign only the permissions required for the current role, and remove them when the need ends. Regular access reviews identify accumulated excess. Separating daily-use accounts from admin accounts prevents a compromised daily account from immediately reaching admin-level access.

federation and SSO abuse

How it works. Federated authentication lets users authenticate once at an identity provider and be trusted across multiple connected systems. If an attacker compromises the identity provider, or exploits a misconfigured trust relationship, they gain access across everything connected to the federation. Common implementation flaws that enable token forgery or replay include failing to validate token expiration, not checking the issuer field, failing to validate signatures, and not mapping subject identifiers precisely. Weaker federation partners in a supply chain are also a documented entry point.

Warning signs. Authenticated sessions that cannot be correlated with an actual login event at the identity provider. Assertions with unusual issuer values or timestamps. Authentication events from unexpected federation partners.

The control. Strict token validation at every relying party: check issuer fields, validate signatures, reject expired tokens promptly, map subject identifiers precisely. Limit federated trust relationships to what is currently required. Monitor IdP authentication events against downstream session creation to detect forged or replayed assertions.

privileged account takeover

How it works. Admin accounts, cloud console owners, database administrators, and service accounts with broad permissions are the highest-value targets. Gaining control of one provides access across many systems at once. Privileged account takeover can be the endpoint of phishing, credential stuffing, or session hijacking, applied specifically to admin targets. Service accounts are a specific risk: long-lived credentials, broad permissions, and no MFA equivalent in many configurations.

Warning signs. Admin-level actions outside established patterns, particularly at off-hours. Changes to logging settings or audit trail configurations by accounts not normally involved in those tasks. New accounts created with elevated permissions.

The control. Separate admin accounts from daily-use accounts. Apply MFA to every admin account. Keep admin account scope as narrow as the role actually requires. Review privileged accounts regularly. Log all privileged activity. For service accounts, use short-lived and scoped credentials where possible, with IP restrictions and anomaly monitoring.

deepfake-assisted social engineering

How it works. Synthetic audio and video have become accessible enough that attackers use them to impersonate trusted individuals. A finance employee receiving what appears to be a video call from the CFO, a help desk agent processing a password reset for someone who sounds convincing, an identity verification process fooled by a synthetic face: all are documented attack patterns. The verification step becomes the attack target.

Warning signs. Unusual requests arriving through atypical channels. Pressure to act quickly and bypass standard verification. Inconsistencies in video or audio quality.

The control. Out-of-band verification for high-stakes requests: confirm the request through a separate channel using a previously established contact method. For help desk workflows, multi-step verification that relies on something the attacker cannot generate from public sources.

what ties it together: visibility

Every technique in this guide produces signals: unusual authentication times, accounts accessing systems they have not previously used, sessions active after expected expiry, admin actions outside normal patterns. In most environments, these signals exist and go undetected because nobody is positioned to see them.

Visibility is a prerequisite for the controls described here to function. Access reviews depend on knowing what accounts exist. MFA coverage checks depend on an account and application inventory. Anomaly detection depends on a baseline. Offboarding depends on a complete list of systems to deprovision. You cannot defend an identity attack surface you cannot see. The starting point is a complete picture of your identity environment: every account, every application, every permission, mapped against current roles and access needs.

how this maps to SOC 2, ISO 27001, NIS2, and DORA

The identity attack techniques in this guide have direct correspondence to the controls expected by the major frameworks.

SOC 2. The Trust Services Criteria address logical access controls (CC6.1, CC6.2, CC6.3), covering provisioning, modification, and removal of access, plus monitoring and anomaly detection. MFA enforcement, least privilege, access reviews, and offboarding map directly to the criteria auditors check.

ISO 27001. ISO 27001:2022 Annex A includes controls on access management (A.5.15 through A.5.18), authentication (A.8.5), and monitoring (A.8.16). Privileged access management has its own control (A.8.2). The attack techniques here inform what each control is designed to address.

NIS2. Article 21 requires covered entities to implement access control and authentication policies as part of cybersecurity risk management. The identity attack surface is precisely what these requirements are designed to reduce. MFA, access reviews, and privileged account controls are the operational implementation.

DORA. Article 9 specifies ICT security requirements for financial entities, with explicit attention to privileged access management, authentication, and monitoring. The privileged account takeover and session hijacking techniques correspond directly to the risks DORA expects organizations to have controls for. The same controls that reduce your exposure to the techniques in this guide are the ones frameworks expect to see.

Subscribe to unshadowed.

Subscribe to receive the latest blog posts to your inbox and stay up to date with

By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

let's start with a conversation

Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.

Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.

We'll take it from there

Julian Machowski
Head of Technical Sales
+48 783 762 997
julian@unshadowit.com
Let's connect on LinkedIn
Message received. We'll be in touch soon.
Something failed. Try again or call us directly.