The ransomware playbook is outdated. Fewer attackers are dropping malware at the door — they're walking in through it, using stolen credentials and session tokens that look exactly like legitimate users.

In 2024, the Verizon Data Breach Investigations Report found that 38% of breaches used stolen credentials as the primary attack vector — up from 19% just five years earlier. CrowdStrike's 2024 Global Threat Report showed that valid account abuse was the primary initial access method in 35% of cloud incidents in H1 2024. These aren't outliers. They're the new baseline.

The implication for SMBs is sharp: the perimeter your team spent years hardening — firewall, endpoint, email filter — has been circumvented by something none of those tools were designed to catch: a logged-in user who looks legitimate because they are legitimate. They just aren't authorized to be there.

This playbook covers the five identity attack patterns dominating 2026, four real-world case studies with documented impact, why your current security stack almost certainly didn't catch them, and the eight behavioral changes that close the gap.

The 5 Identity Attack Patterns of 2026

1. Infostealer-Driven Credential Theft

Infostealer malware — LummaC2, RedLine, StealC — is sold as a subscription service on Russian-language cybercrime forums for $100–$500/month. Attackers don't need to write it themselves. They buy it, configure it, and distribute it via pirated software, fake browser updates, and SEO-poisoned search results for common business tools.

When it lands on an employee's machine, it harvests every credential sitting in the browser: saved passwords, session cookies, auto-fill data. The attacker receives a JSON export of everything. Within hours, they're testing those credentials against corporate VPNs, Microsoft 365, Google Workspace, Salesforce, GitHub, and any SaaS tool that accepts a password.

The operational pattern for SMBs: an employee's home laptop gets infected from a pirated tool download. They connect to the corporate VPN with cached credentials. The infostealer exfiltrates the session cookie. The attacker logs in from an IP in a different country and starts exfiltrating data — or selling access to a ransomware affiliate.

The Snowflake customer breaches in 2024 were the highest-profile example. Attackers used infostealer credentials obtained from a former Snowflake employee to access the company's Atlassian instance, then moved laterally into customer data environments. The credentials worked because Snowflake had no MFA enforcement on Atlassian — a tool most security teams wouldn't think of as a primary target.

2. MFA Bypass via AiTM Phishing

Adversary-in-the-middle (AiTM) phishing attacks position a proxy between the victim and the legitimate login page. When the victim enters their password, the attacker relays it in real time to the real site, obtains the MFA response, and forwards that too — capturing both credentials and a valid session cookie before the victim even realizes what happened.

Standard MFA (SMS OTP, authenticator push, TOTP) does not stop AiTM attacks. The authentication response is relayed through the attacker's proxy — by the time the legitimate server issues the session cookie, the attacker already has it. This technique was used in the majority of high-profile BEC incidents documented in 2024, including a string of accounting-firm breaches where attackers used the CPA's own email account to request wire transfers from clients.

Only phishing-resistant MFA — FIDO2 hardware keys, passkeys, or hardware-backed WebAuthn — stops AiTM, because the cryptographic binding is tied to the legitimate domain and cannot be relayed through a proxy. See our full AiTM deep-dive and defense guide →

3. SaaS Token Theft and Session Hijacking

Modern SaaS applications don't just use passwords — they use OAuth tokens, session cookies, and API keys that persist for days or weeks. Once an attacker obtains a valid session token from any SaaS platform, they can operate inside that environment as the legitimate user, often without triggering any behavioral anomaly detection.

The attack pattern: attacker obtains a token (via infostealer, AiTM, or OAuth app consent phishing). They authenticate to the SaaS API using that token. They export customer data, financial records, or intellectual property. They cover their tracks by deleting their own activity logs, which most SaaS applications allow admin users to do.

The danger for SMBs is amplified by the sheer number of connected SaaS applications. A typical 50-person company uses 40–80 SaaS tools. Each one stores session tokens. Each one is a potential entry point. The blast radius of a single compromised account has never been wider.

4. Help-Desk Social Engineering

Some of the highest-impact identity attacks in the past two years didn't use malware or phishing at all. They called the help desk.

The MGM Resorts breach in September 2023 is the clearest example. A threat actor — later attributed to the Scattered Spider group — called MGM's IT help desk, impersonated an employee, and convinced the support agent to reset the account's MFA. Within minutes, the attacker had corporate email access. Within hours, they had Alinity's casino management system, the slot machine network, and were demanding a ransom on the dark web.

The total impact: $100 million in costs, class action lawsuits, SEC investigation, and an SEC fine for the CISO who had to publicly confirm the breach scope. The initial access cost for the attacker: one phone call and a convincing voice.

The same technique worked against Caesars Entertainment the same month, and has been documented against healthcare organizations, law firms, and financial services companies across 2024. The common denominator: help-desk agents who were trained to be helpful, not to verify caller identity against a secondary channel.

5. Supply-Chain Identity Compromise

Attackers increasingly compromise the identity infrastructure of vendors and partners rather than targeting the victim directly. If you trust your SaaS vendor's Okta instance, and someone compromises that Okta instance, your organization is compromised by extension.

The Okta support case files breach in October 2023 is the canonical example: attackers accessed Okta's support case management system and obtained session tokens for Okta customers. Okta's own Security Operations team had visibility into the initial compromise but failed to act on the alerts — a failure that cost Okta a $4 million FTC consent order.

Microsoft's Midnight Blizzard breach in January 2024 was similar in mechanism: a legacy non-production Microsoft tenant with a weak password was compromised via password spray. Attackers used the foothold to access Microsoft corporate systems and — critically — exfiltrate internal source code and internal developer documentation. They then used that code to craft more targeted attacks against Microsoft's customers, including a successful breach of HPE's Microsoft 365 tenant.

The lesson: your supply chain's security posture is your security posture. The weakest link in the vendor ecosystem you trust is often the one you know nothing about.

Test Your Team Against Real Phishing Templates

Download the free Phishing Test Kit — 5 templates, click-tracking sheet, and debrief script. Run it today.

No spam. Unsubscribe anytime.

Four Verified Case Studies

Snowflake (2024): Infostealer + No MFA

The Snowflake breach wasn't a sophisticated zero-day. It was a former employee whose personal device had an infostealer. That device had saved credentials for the Atlassian tool Snowflake used for internal project management. Atlassian had no MFA enforcement. The attackers had a way in.

From there, they accessed Snowflake's customer support portal and extracted session tokens for over 100 Snowflake customers — including Ticketmaster, AT&T, and Santander. The downstream impact: millions of customer records, regulatory notifications, and a months-long forensic investigation.

The fix Snowflake eventually implemented: enforced MFA across all admin access. The attack vector had been open for months before it was discovered. No malware, no phishing, no zero-day — just one employee laptop with an infostealer and a SaaS tool with no MFA enforcement.

Change Healthcare (February 2024): Citrix Portal Without MFA

UnitedHealth Group's Change Healthcare subsidiary was breached through a Citrix remote access portal that lacked MFA. The attackers obtained credentials, logged in, and spent two weeks inside the network before deploying ransomware.

The impact was catastrophic: $2.45 billion in direct costs per UHG's SEC 8-K disclosure, including $872 million in patient impact remediation. The disruption cascaded across the US healthcare system — pharmacies couldn't verify insurance, imaging centers couldn't process claims, and physician practices couldn't get paid for weeks. It was the largest healthcare data breach in US history.

The initial access vector: a Citrix remote access portal without MFA on an internet-facing interface. That's it. One misconfiguration. One missing control. The entire US healthcare payment system felt it.

MGM Resorts (September 2023): Help-Desk Vishing by Scattered Spider

The MGM breach has become the definitive case study for help-desk social engineering. Scattered Spider's initial access cost: one phone call. They called MGM's IT help desk, claimed to be an employee who had lost access, provided enough information to pass the caller's identity check (information scraped from LinkedIn and data brokers), and convinced the agent to add a new MFA device to the account.

From there, the attackers spent roughly 72 hours enumerating MGM's internal network before deploying the ALPHV/BlackCat ransomware. The total downtime lasted weeks. Total cost, including incident response, lost revenue, regulatory fines, and the SEC settlement: over $100 million.

The CISO's post-mortem was direct: the attacker didn't need a zero-day. They needed the IT team's willingness to be helpful. The fix would have been a callback verification protocol — call the employee back on a known number before processing MFA resets via phone.

Microsoft Midnight Blizzard (January 2024): Password Spray on Legacy Tenant

Microsoft's own security posture wasn't sufficient to prevent the Midnight Blizzard compromise. The initial vector: a legacy Microsoft tenant used by Microsoft's internal team for testing and demos. The tenant had a weak password. Attackers ran a password spray campaign — automatically testing common passwords against the tenant — and found one that worked.

From the legacy tenant, the attackers pivoted to Microsoft corporate systems. They extracted source code from Microsoft's internal repositories and used that code to craft spear-phishing campaigns against Microsoft's customers. HPE was among those compromised, with attackers accessing HPE's Microsoft 365 environment using information derived from the Microsoft source code theft.

The lesson: your security is only as strong as your weakest tenant. Legacy, non-production, test, and demo environments are always less monitored — and attackers know to look for them.

Why Your Security Stack Didn't Catch It

Modern SMB security stacks are built around endpoint detection and network-layer controls: EDR on laptops, firewall rules, email filtering. This architecture is effective against malware-based attacks. It is largely blind to identity attacks, for three structural reasons.

1. EDR sees the endpoint, not the SaaS session. When an attacker logs into your Microsoft 365 tenant using stolen credentials from an IP address in Eastern Europe, no alert fires on your EDR. The laptop they're using might not be the same laptop that was compromised. They might be on a different device entirely, using a session cookie they extracted from an infostealer output. Your EDR sees a browser. It doesn't see an unauthorized user.

2. IdP logs go unreviewed. Most SMBs have Microsoft Entra ID (Azure AD) or Google Workspace for identity management. Both generate detailed sign-in logs — location, device, risk level, application access. Most of these logs are never reviewed. The alerting that could catch impossible travel, first-time sign-ins from new devices, or sign-ins from high-risk countries exists — but it's not enabled, or it's enabled but no one is watching it.

3. The help desk has no callback protocol. When MGM's IT help desk received the call that reset the account MFA, there was no mechanism to verify the caller through a secondary channel. A 30-second callback to the employee's known phone number would have stopped the entire attack chain. Most help desks have no policy for this, no tooling to support it, and no training to make it instinctive.

The structural fix is a layered identity security approach: phishing-resistant MFA for high-risk accounts, IdP log monitoring with automated alerting, conditional access policies that trigger re-authentication on anomalous behavior, and a help-desk callback protocol for all MFA resets.

The Human Firewall Playbook: 8 Behaviors That Change the Attack Surface

Technical controls are necessary but not sufficient. The identity attack surface has a human layer — the behaviors your team does or doesn't do that determine whether a stolen credential becomes an active breach. These eight behaviors, practiced consistently, materially reduce the probability that an identity attack succeeds.

1. Phishing-resistant MFA everywhere it matters. Standard MFA (SMS, TOTP, push) doesn't stop AiTM attacks. Migrate high-risk accounts — CEO, CFO, anyone with financial system access, IT admins, anyone with access to the primary email tenant — to FIDO2 hardware keys or passkeys. This is the single highest-leverage change an SMB can make. A YubiKey costs $20–$50. The breach it prevents costs millions.

2. No push approval without a visible context code. Number matching (where the user must see a code on the login screen and enter it in the authenticator app) closes the MFA fatigue attack window. Even without phishing-resistant keys, number matching prevents the "just approve one" attack pattern that compromised MGM, Uber, and dozens of other organizations. Require number matching for all push-based MFA.

3. Help-desk callback protocol for all phone-based MFA resets. Before processing any MFA reset or account recovery request made by phone, the help desk agent must call the employee back at the number on file in the HR system. Document this as a written policy, configure your help-desk ticketing system to enforce it, and test it quarterly. This is the single control that stops the MGM attack pattern.

4. Session-token hygiene after travel. Require re-authentication for all cloud applications after employees return from international travel. Implement this as a conditional access policy in Microsoft Entra ID or Google Workspace — it's automatic and requires no user action. Travel is a high-correlation indicator of compromised credentials.

5. OAuth grant review quarterly. Every third-party app that has access to your Microsoft 365 or Google Workspace tenant is a potential entry point. Review OAuth grants monthly for users with admin roles, and quarterly for all users. Remove any app that the user doesn't actively use. Attackers use OAuth app consent phishing to establish persistent access that doesn't depend on a stolen password.

6. Password manager + breach monitoring. A password manager ensures that every account has a unique, strong password. Combined with a breach monitoring service (HaveIBeenPwned, Google Workspace alerts), this stops the infostealer credential reuse chain. When an employee downloads a pirated tool that runs an infostealer, the infostealer grabs whatever passwords are saved in the browser. If each password is unique, the attacker can't reuse them across your other accounts.

7. Conditional access for SaaS admin roles. Every SaaS application — Salesforce, HubSpot, Box, GitHub — has admin roles with broad access. Add conditional access policies: require MFA, block sign-ins from high-risk locations, and require re-authentication every 4–8 hours. Many organizations enforce MFA on their primary email tenant but leave their CRM, HRIS, or code repository open.

8. Monthly tabletop drill covering the identity attack scenarios. Run your incident response team — or your IT person and a business owner — through the four scenarios in this playbook once a month. How would your team know MGM's attacker had called your help desk? What does the response look like when the CFO's email starts sending wire instructions to your AP team? Our AiTM attack playbook covers the tabletop scenario →

Ready to close the identity attack gap?

SecurEveryone runs live coaching on the 5 identity attack patterns — help-desk vishing, AiTM, infostealer defense, and more.

No spam. Unsubscribe anytime.

What Changes in Your Training Program

If your current training program is a once-a-year video module with a checkbox completion record, your attack surface isn't covered — it's just documented as "trained" on a compliance form. The five identity attack patterns above are specifically designed to exploit behaviors that video modules don't change:

Video modules can't build these behaviors. Interactive, scenario-based training — where the employee is actually put in the decision point and receives immediate feedback — can. SecurEveryone's live coaching format runs teams through these exact scenarios: the help-desk call, the unexpected MFA push, the lookalike login page. Real situations, real responses, measurable behavior change.

Frequently Asked Questions

What is an identity-based attack?
An identity-based attack uses stolen or impersonated credentials — rather than malware or software exploits — to gain initial access to an organization's systems. The attacker uses the victim's own identity (username, password, session token, or MFA approval) to appear as a legitimate user. This makes the activity difficult for traditional security tools to detect, because it looks like normal authorized access. Common forms include credential theft via infostealers, AiTM phishing, session cookie hijacking, and help-desk social engineering.

How is an identity-based attack different from phishing?
Phishing is a delivery method — an attacker sends an email or message to trick a victim into doing something (clicking a link, entering credentials, approving an MFA push). Identity-based attacks are the outcome: the attacker used stolen credentials to access systems as if they were a legitimate user. A phishing email can lead to an identity-based attack, but identity attacks can also start from infostealer infections, purchased credentials from breach dumps, or help-desk vishing calls. Many attacks chain multiple methods.

Does MFA stop identity-based attacks?
Standard MFA (SMS OTP, TOTP authenticator apps, push notifications without number matching) stops many credential-based attacks, but not all. AiTM attacks relay the MFA approval through a proxy, capturing a valid session cookie — standard MFA cannot stop this. MFA fatigue attacks (push notification bombing) rely on a victim approving an unexpected push. Only phishing-resistant MFA (FIDO2 hardware keys, passkeys, hardware-backed WebAuthn) stops both AiTM and MFA fatigue, because the cryptographic binding cannot be relayed. For help-desk vishing, no MFA product helps — only a process change (callback verification) stops it.

What was the Change Healthcare attack vector?
The Change Healthcare breach started with a Citrix remote access portal — an internet-facing application used by employees to connect to the corporate network — that lacked MFA enforcement. Attackers obtained credentials (likely from an infostealer or credential dump), logged in, and spent approximately two weeks inside the network before deploying ransomware. The total cost exceeded $2.45 billion, making it the most expensive healthcare breach in US history. The lesson: MFA enforcement on remote access tools is not optional.

How can small businesses detect identity attacks with limited security staff?
The highest-impact detection measures for SMBs are: (1) Enable Microsoft Entra ID or Google Workspace sign-in risk detection and automated alerts for impossible travel, new device, or high-risk sign-in — this requires minimal ongoing attention and catches most anomalous identity activity. (2) Audit help-desk tickets monthly for MFA reset patterns — spikes in reset requests often indicate an active campaign. (3) Check for mailbox rules you didn't create (rules that delete emails from specific domains or forward to external addresses) weekly. (4) Review your IdP's sign-in logs for locations you don't recognize. Most of this can be done by an IT generalist with the right alerting configured.

Your attack surface isn't static. Neither is your defense. Book a session with SecurEveryone to run your team through the identity attack playbook — live coaching, real scenarios, measurable outcomes.

Related Resources

The identity attack surface grows with every connected SaaS app and every remote worker. Book your team's first session — $900 flat, unlimited users, no per-seat math.