The Anatomy of an Identity Breach

The Valid Login That Starts an Identity Breach

It’s 02:17 AM.

There’s a login to your tenant. Nothing unusual on the surface, just another successful authentication through Microsoft Entra ID. No malware. No exploit. No endpoint alert. Just a successful login.

If anything, it looks cleaner than most legitimate logins.

But this one matters.

Because this is where many breaches begin, sometimes leading to a data breach involving personal information, sensitive records, or worse.

And unless you understand how to detect it, not just technically, but contextually, you will likely miss every stage that follows.  It rarely starts with malware anymore.

There’s no flashing red alert, no ransomware notes, no dramatic system outage tied to a ransomware attack. Instead, it begins quietly, with a simple login. A perfectly valid one. The right username, the right password, perhaps even the right multi-factor authentication response using stolen login credentials.

From the system’s perspective, nothing is wrong.

And that’s precisely the problem.

Identity has become the connective tissue that enables an organization to operate, sometimes referred to as the new perimeter. In a world of cloud-first architectures, SaaS sprawl, remote work, and API-driven ecosystems, attackers no longer need to break in. They log in to gain unauthorized access. The anatomy of an identity breach is not defined by technical exploitation alone, but by how attackers exploit trust, permissions, and identity pathways.

To understand how to defend against it, we must first understand how it unfolds.

Stage 1: Reconnaissance – Mapping the Identity Attack Surface

Every identity breach begins long before the first successful authentication.

Attackers invest significant effort into reconnaissance, building a detailed map of identities, access patterns, and authentication mechanisms. This includes harvesting personal information, such as employee details and sometimes even sensitive identifiers like Social Security numbers, from breach datasets.

The goal is simple: reduce uncertainty. The more an attacker understands, the easier it is to gain unauthorized access later.

What Attackers Are Looking For

• Employee data from LinkedIn and company websites
• Email formats and login portals
• Exposed services, such as VPNs, O365, and SSO portals
• Valid usernames through authentication responses
• OSINT and prior breach datasets

From a technical standpoint, this phase often involves:

• Password spraying against federated identity providers
• OAuth application enumeration in cloud environments
• Tenant discovery attacks against platforms like Microsoft Entra ID

Long before that successful login, there was noise. I call them tiny ripples in the water, hard to notice, but they are the start of a breach. Not enough to trigger alarms. Not aggressive enough to lock accounts. Just enough to test the edges of your organization’s infrastructure and services.

Across your logs, scattered over hours or days, are failed authentication attempts. These are early threat signals, but they are rarely acted on with urgency.

Individually, they look harmless.

Together, they tell a story.

How Attackers Test the Environment

• Test known usernames
• Perform password spraying
• Identify accounts without MFA
• Map authentication responses

What Defenders Should See

• In your Windows logs, Event ID 4625 repeats.
• In Kerberos logs, 4771 failures stack up.
• In cloud logs, failed sign-ins quietly accumulate.

Stage 2: Initial Access – The First Valid Credential

This is where identity breaches diverge from traditional attacks. 

Instead of exploiting a vulnerability, attackers authenticate.

What’s critical here is that no exploit is required. The attacker is now an authenticated user.

Eventually, one of those attempts works.

• Maybe it’s credential reuse.
• Maybe it’s a weak password.
• Maybe it’s MFA fatigue.

But now the attacker has something far more dangerous than access:

They have legitimacy and trust.

How Attackers Get the First Valid Login

• Credential stuffing using previously breached passwords
• Phishing campaigns targeting MFA fatigue or token theft
• Adversary-in-the-middle (AiTM) frameworks that intercept session cookies
• Abuse of legacy authentication protocols that bypass MFA

Technically, successful access often results in:

• A valid session token (e.g., OAuth or SAML assertion)
• A persistent browser session cookie
• Conditional access bypass if controls are misconfigured

In environments using Microsoft Entra ID or similar platforms, attackers frequently target:

• Legacy protocols
• Misconfigured Conditional Access policies
• Weak MFA implementations (SMS, push fatigue)

What Changes After the First Valid Credential 

The logs go quiet.

No more failures. No brute force. Just a clean 4624 successful login.

From a SOC perspective, this is where many investigations stop because the successful logon is assumed to be a valid user.

But from an attacker’s perspective, this is where everything begins.

The Critical Detection Opportunity

A successful login after a pattern of failures is one of the highest signal indicators of compromise.

Stage 3: Establishing Persistence – Living Beyond the Password

Once inside, the attacker’s next priority is persistence.

Passwords can be reset. Accounts can be locked. Even if credentials are reset, attackers can retain privileged access through tokens, OAuth apps, or session abuse.

At this stage, the attacker is no longer dependent on the original compromise vector. Even if the password changes, access persists.

At this point, many organizations feel protected. “MFA is enabled.”

But attackers have adapted.

They don’t bypass MFA. They manipulate it.

How Attackers Keep Access Alive

• Registering new MFA methods
• Creating or modifying OAuth applications with delegated permissions
• Adding backdoor accounts or service principals
• Generating long-lived refresh tokens
• Abusing Kerberos Golden/Silver Tickets in hybrid environments

Why Password Resets May Not Be Enough

• OAuth abuse allows attackers to maintain access without re-authentication
• Refresh tokens can remain valid for weeks or months
• API-based access often bypasses traditional monitoring controls

How MFA Abuse Shows Up

• Push notification fatigue
• Social engineering approval requests
• Adversary-in-the-middle frameworks
• Session cookie theft

What Defenders Should See in Logs

• Multiple MFA prompts in a short window
• Failed attempts followed by a success
• Authentication from a new device immediately after

Stage 4: Privilege Escalation – Expanding the Blast Radius

With persistence established, attackers begin to move laterally, not across networks, but across identities.

They identify over-permissioned accounts and escalate privileged access, often targeting identities with access to sensitive systems and data.

The key business impact here is exponential. One compromised identity can become many. Eventually, it can become control over the environment.

The attacker now asks a simple question:

“What can this identity reach and what can it do?”

And the answer is often: more than it should.

How Attackers Expand Access 

Privilege escalation in identity breaches often involves:

• Identifying misconfigured roles and excessive permissions
• Exploiting role chaining in IAM systems
• Targeting high-value accounts (admins, service accounts)
• Abusing Just-In-Time (JIT) access mechanisms
• Leveraging token impersonation

Where Privilege Escalation Happens 

In cloud environments, attackers may:

• Assign themselves elevated roles
• Abuse automation accounts or CI/CD pipelines
• Extract secrets from vaults or configuration stores

In hybrid Active Directory environments, this may involve:

• Kerberoasting service accounts
• Dumping LSASS for credential material
• Exploiting delegation misconfigurations

What Defenders Should Detect

The attacker:

• Discovers overprivileged roles
• Assigns themselves elevated access
• Targets administrative identities
• Exploits role inheritance and misconfigurations

In Active Directory:

• 4728 / 4732 / 4756 – Group membership changes

In cloud environments:

• Role assignment changes in audit logs

Stage 5: Lateral Movement – Identity as the Network

Traditional lateral movement relied on network access. Today, identity is the transport layer.

Attackers move between:

• SaaS applications (CRM, finance, HR systems)
• Cloud platforms (Azure, AWS, GCP)
• Internal systems via federated authentication

This is often achieved through:

• Token reuse across services
• API access using stolen credentials
• Federation trust abuse (SAML/SSO misconfigurations)

A single compromised account can unlock multiple services, increasing exposure to cyber threats across SaaS and cloud environments.

At this stage, the breach is no longer contained; it’s systemic.

There was a time when lateral movement meant pivoting between machines.

Now it means pivoting between identities.

How Access Spreads Across Systems 

• Access to email → password resets → SaaS takeover
• Access to collaboration tools → internal phishing → broader compromise
• Access to cloud IAM → infrastructure control

What the Attacker Does

• Accesses SaaS platforms
• Moves into email systems
• Uses APIs for automation
• Leverages SSO trust relationships

What Defenders Should See

• Multiple logins across different applications
• New IP addresses and locations
• Increased authentication volume

Stage 6: Deep Access – Extracting Credentials, Secrets, and Data

The end goal is rarely just access. It is the impact: disruption, financial gain, or both.

Because the attacker is authenticated, these actions often blend into normal activity.  The attacker will do everything possible to live off the land (LOTL) and not introduce any additional tools that would generate suspicious activity or noise. 

The goal is to stay as stealthy as possible. 

At this stage, the attacker is no longer exploring. They are extracting value.

What Attackers Seek 

• Customer data and personal information
• Financial systems for fraud
• Identity stores for further expansion or to resell to other threat actor groups
• Backup systems (for ransomware attack execution)

How Attackers Extract Value 

• Large-scale API data extraction
• Email forwarding rule creation
• Silent data staging in cloud storage
• Use of legitimate tools (PowerShell, Graph API, CLI tools)

What Credential Theft Looks Like

• Kerberoasting service accounts
• Dumping credentials from memory
• Event ID 4769 spikes (Kerberos tickets)
• LSASS access attempts
• Suspicious process execution

Stage 7: The Business Impact – When an Identity Breach Becomes a Data Breach

The result is often a data breach involving regulated data, potentially including personal information, financial records, or other regulated data.

From a business perspective, identity breaches are uniquely dangerous:

• They bypass traditional security controls
• They exploit trust, not just technology
• They scale rapidly across environments
• They are difficult to detect and even harder to contain

This is not just a SOC issue; it’s a board-level risk.

The financial and reputational impact is compounded by:

• Regulatory exposure (GDPR, NIS2)
• Loss of customer trust
• Operational disruption
• Intellectual property theft

At this point, access has turned into impact. The attacker now has what they came for.

What Attackers Target 

• Email data
• Customer records
• Intellectual property
• Financial systems

What the Impact Looks Like

• Mailbox forwarding rules
• Bulk downloads
• API-based data extraction

The Missed Opportunity: Defending Against Identity Attacks

Understanding the anatomy is only half the battle. Defending against it requires a shift in mindset, from perimeter security and reactive alerts to proactive identity intelligence.

1. Build Visibility Across Every Identity

You cannot protect what you cannot see.

• Centralize identity logs across all platforms
• Monitor authentication patterns, not just failures
• Correlate activity across identities and services

2. Enforce Strong Authentication the Right Way

MFA is necessary, but not sufficient.

• Eliminate legacy authentication protocols
• Deploy phishing-resistant MFA (FIDO2, hardware tokens)
• Monitor for MFA fatigue and anomalous approvals

3. Control Privileges Continuously – A Zero Trust Mindset

Standing access is a liability.

• Implement least privilege across all identities
• Use Just-In-Time access with strong governance
• Continuously audit role assignments and permissions

4. Detect Identity Abuse, Not Just Intrusions

Shift detection logic toward behavior.

• Impossible travel
• Token anomalies
• Unusual API usage
• Privilege escalation patterns

5. Secure Tokens and Sessions

Sessions are the new credentials.

• Monitor token issuance and reuse
• Shorten token lifetimes where possible
• Revoke sessions aggressively during incidents

6. Build Identity-Centric Incident Response

Your IR playbooks must evolve.

• Focus on identity containment, not just endpoint isolation
• Revoke tokens, not just reset passwords
• Investigate identity relationships and access chains

What’s striking about identity breaches isn’t their sophistication. It’s how many chances there were to detect them.

• During reconnaissance
• At first login
• During MFA abuse
• At persistence creation
• During privilege escalation

Each stage leaves evidence.

Each stage is detectable.

And yet, most breaches are discovered far too late.

Final Thoughts: Stop Treating Identity Signals as Isolated Alerts

Defenders often think in alerts.

Attackers operate in stories.

From phishing attacks to ransomware attacks, from stolen login credentials to privileged access, the journey is connected.

The anatomy of an identity breach is not a single event; it’s a sequence:

• Failure → Success
• Access → Persistence
• Identity → Privilege
• Movement → Impact

If you only look at individual signals, you will miss the narrative.

But if you connect them, you can stop the breach before it becomes a headline.

Connect Identity Signals Before They Become a Breach

A valid login should not be the end of the investigation. It should be the beginning of understanding what that identity can reach, what privileges it holds, and what actions follow.

Segura PAM helps security teams protect privileged credentials, monitor sessions, enforce least privilege, and reduce standing access across critical systems.

See how to bring identity context, privileged access, and high-risk activity under control.