What a real credential stuffing attack looks like and how to stop it happening to your clients 

Here's the uncomfortable truth about most credential attacks: the attacker doesn't need to be clever. 

They don't need to find a zero-day exploit or build custom malware or spend weeks mapping your client's network. They need a list of email addresses and passwords that someone else already leaked and an automated tool to test which ones still work. 

That list exists. It's been bought and sold thousands of times. And the credentials on it keep working long after the original breach because people reuse passwords across platforms and nobody ever forces them to change. 

This is how a real attack played out for one of our clients. 

How the attack happened: stage by stage 

Stage one: preparation 

The attacker started with a credential database purchased from a 2021 data breach. Not a sophisticated operation. A routine purchase on a dark web marketplace, the kind that costs less than a monthly software subscription. 

From that database, they cross-referenced email domains against known business targets and identified 340 email and password pairs matching our client's domain. Three hundred and forty accounts. All from a breach that happened four years ago. All still potentially active because nobody had checked. 

Stage two: automated testing 

The attacker ran those 340 credential pairs against Microsoft 365 login endpoints using distributed proxies, throttling attempts to two per account per hour to stay well below standard lockout thresholds. 

The result: 12 successful authentications from 340 attempts. A 3.5% success rate that sounds small until you remember that 12 compromised accounts in a single client environment is a serious incident waiting to happen. 

Three of those 12 accounts had MFA. But legacy authentication protocols were still enabled on the tenant and those protocols don't support modern MFA challenges. The attacker bypassed MFA on those three accounts without needing to intercept a code or social engineer anyone. They just used a protocol the tenant should have disabled years ago. 

Stage three: access and enumeration 

The attacker chose the office manager's account to work from. No MFA enforced on legacy protocol. Access granted. 

Within that session they accessed SharePoint, OneDrive and shared mailboxes and downloaded client contracts, financial documents and HR files. They also created an inbox rule forwarding all incoming emails to an external address. 

That last action is important. It's quiet, it's persistent and it means the attacker keeps receiving emails even if the account password is later changed, until someone specifically reviews and removes the rule. 

Stage four: persistence 

With access established, the attacker registered a new MFA device on the compromised account, effectively locking in their access even if the organisation enforced MFA going forward. They created a mail flow rule to delete incoming security alert emails so the account holder wouldn't see any warning notifications. Then they started monitoring email conversations for invoice and payment discussions. 

The attack remained undetected for 11 days. 

What finally caught it 

A SOC analyst reviewing impossible travel alerts flagged a 3am login from a geographic location inconsistent with the employee's normal pattern. 

That single alert, investigated properly, unravelled everything: the inbox forwarding rule, the registered MFA device and the full scope of what had been accessed. 

Without that alert being reviewed and acted on, the attacker would have stayed in the environment indefinitely. They were already positioned to intercept an invoice and redirect a payment. That's typically where attacks like this end up, not in a dramatic data breach announcement but in a fraudulent payment that's very difficult to recover. 

Why this keeps happening to MSP clients 

Credential stuffing attacks succeed for three reasons that are entirely preventable. 

First, password reuse. The office manager had used the same password across multiple platforms since 2021. That's not unusual. It's the default human behaviour when nobody enforces a different approach. The breach that exposed her credentials had nothing to do with your client's environment but the damage landed there anyway. 

Second, legacy authentication. Microsoft 365 still supports authentication protocols that were built before modern MFA existed. Basic authentication, SMTP AUTH, IMAP and POP3 can all be used to authenticate without triggering an MFA challenge. If those protocols are enabled on a tenant, MFA is not the complete protection it appears to be. 

Third, no breach monitoring. The credential database used in this attack came from a 2021 breach. Four years passed between that breach and this incident. Running the client's email domains against breach databases quarterly would have flagged the exposure long before an attacker found it. 

Seven defences to implement across your client base 

1. Disable legacy authentication protocols 

This is the highest-priority action and the one most often overlooked. Go into each Microsoft 365 tenant and block Basic Authentication across all legacy protocols. Use Conditional Access policies to enforce this at the tenant level rather than relying on per-user settings. If a client has a business reason to keep a legacy protocol active for a specific application, isolate it and monitor it closely rather than leaving it open across the board. 

2. Enforce MFA on every account with no exceptions 

No shared mailboxes without MFA. No service accounts without MFA. No exceptions for senior leaders who find it inconvenient. Credential stuffing attacks target the path of least resistance and attackers will find the one account you left unprotected. Enforce MFA at the Conditional Access level so it applies regardless of which protocol is used to authenticate. 

3. Monitor for impossible travel and anomalous login patterns 

Microsoft Entra ID includes impossible travel detection as part of its Identity Protection features. Make sure it's enabled and that alerts are being reviewed, not just logged. An alert that nobody reads is not a defence. Build the review of identity risk alerts into your SOC workflow or your weekly security check for each client. 

4. Run client email addresses against breach databases quarterly 

Services like Have I Been Pwned offer domain search functionality that shows which email addresses from a given domain have appeared in known breach databases. Build a quarterly check into your service delivery for every client. When a match appears, treat it as a live credential risk and force a password reset on the affected account immediately. 

5. Implement conditional access policies 

Block logins from untrusted locations unless there's a documented business reason to allow them. For most SMB clients, their users log in from a handful of locations. A login from an unusual country at 3am should either be blocked outright or trigger a step-up authentication challenge. Configure named locations in Entra ID and build policies around them. 

6. Review inbox rules and mail flow rules weekly 

Attackers who establish access almost always create forwarding rules. They're quiet, persistent and often missed in routine security reviews. Add a weekly check of inbox rules and mail flow rules for all accounts to your managed service baseline. Any rule forwarding to an external address that wasn't created by an administrator warrants immediate investigation. 

7. Alert on new MFA device registration for privileged accounts 

Registering a new MFA device on a compromised account is how attackers lock in access for the long term. Set up alerts for new device registrations on any account with privileged access or access to sensitive data. A legitimate user registering a new device is a 30-second conversation to confirm. An attacker registering a device you don't catch is an 11-day breach. 

The bigger picture 

The breach database used in this attack is publicly available. The credentials from 2021 are still out there and they're being tested against your clients' environments on a regular basis by automated tools that require no human intervention to run. 

This isn't a sophisticated attack. It doesn't require a nation-state actor or a highly skilled threat group. It requires a commodity tool, a cheap database purchase and a Microsoft 365 tenant that still has legacy authentication enabled. 

The seven defences above aren't difficult to implement. Most of them sit inside tools your clients are already paying for. The question is whether they're configured correctly and whether someone is actively monitoring them. 

For MSPs, this is the conversation. Not 'here's a scary attack story' but 'here's what we've already put in place across your environment and here's what we're reviewing every week to make sure it stays that way.' 

That's the difference between being a break-fix provider that responds to incidents and a security-led MSP that prevents them. 

Check your clients' exposure today. The credentials are already out there. The only question is whether the password still works.