The Anatomy of a Breach: How One Spreadsheet Exposed an Entire Business (And How SASE Could Have Stopped It)

It started, as so many stories do, with good intentions and bad habits.

The breach wasn’t the result of advanced persistent threats or zero-day exploits. It wasn’t some masterstroke of technical wizardry. It began with a spreadsheet, a routine process, and a series of very human mistakes—each small on its own, but together enough to unlock the front door of an organisation.

This is the story of how a fictional—but very plausible because it’s based somewhat on a real-world example—security incident unfolded inside a mid-sized professional services firm, and how the right architecture—specifically a Secure Access Service Edge (SASE) approach—could have disrupted the sequence of events before any real damage was done.

Chapter 1: A Spreadsheet with Secrets

The IT helpdesk team was stretched thin. With a growing user base and an ageing access management platform, onboarding new hires and resetting credentials had become a manual and time-consuming process. To reduce internal delays and avoid the inevitable “have you raised a ticket?” conversations, one technician created a spreadsheet listing temporary usernames and default passwords for commonly used systems.

It was supposed to be a stopgap—a quick-reference tool for use during onboarding or when new contractors needed urgent access.

The file was stored on the internal company intranet and named user_credentials_internal.xlsx. It wasn’t encrypted. It wasn’t protected with a password. And over time, more and more credentials were added to it—some of them active and in use. Eventually, it contained hundreds of entries across email, finance, HR, and project management tools.

Everyone in the IT team knew it wasn’t a best practice. But with bigger fires to fight and a password manager project delayed until the next budget cycle, it remained in use.

Chapter 2: Misplaced Convenience

Several months later, an employee in the Finance department—who had recently transitioned from IT support—needed to provide information to an external auditor on short notice. The request came in late in the day, and the systems needed to generate the audit data required credentials that the user didn’t have. Frustrated, the employee remembered the old internal spreadsheet.

They found it easily through a search of the company intranet. Sure enough, the required credentials were listed. But when they tried to share them with the external auditor, they hit a roadblock—emailing the file directly was blocked by the company’s mail gateway due to content restrictions.

To work around this, the employee uploaded the file to a personal cloud storage account they sometimes used for convenience—specifically a “free-tier” object storage service that allowed link sharing. They copied the link, emailed it to the auditor, and thought nothing more of it.

The storage bucket was public by default.

And now, user_credentials_internal.xlsx was on the open internet.

Chapter 3: Found and For Sale

A few weeks later, a small-time data scavenger running automated scripts to find exposed buckets across public cloud providers came across the file. These hobbyist “leak hunters” aren’t penetration testers or security researchers. They trawl for interesting documents, corporate intel, and credential files—looking to trade, sell, or sometimes simply show off what they find.

The filename alone was compelling. A quick preview of the contents confirmed it: a list of usernames and passwords, some with notes like “Outlook only” or “Cloud login”.

Recognising its potential value, the scavenger uploaded the file to an anonymous sharing site and posted a sample on an underground forum. Within days, it was being offered for sale to anyone willing to pay in crypto.

Unlike nation-state actors or large cybercrime syndicates, these buyers don’t perform reconnaissance or carefully map target networks. They spray and pray—using credential stuffing and login scripts to see what sticks.

This time, something did.

Chapter 4: The MFA Gap

The attacker targeted the company’s Microsoft 365 webmail portal. They tried a few dozen logins using the credentials from the spreadsheet. For many accounts, passwords had been changed or the users were no longer with the company. But for others, the details still worked—and the company’s webmail was externally accessible.

Fortunately, the company had implemented multi-factor authentication (MFA) across core services, including email.

Unfortunately, the implementation was flawed.

Users were required to accept a push notification on their corporate mobile phone whenever a login attempt was made. While this offered more security than passwords alone, the prompt was simplistic: “Accept” or “Deny”. No detail. No context. No indication of whether the request came from their device or a suspicious location.

And users were exhausted by it.

Due to poor SSO integration and overlapping cloud apps, some users received these prompts 20 to 30 times per day. Many had grown numb to them—clicking “Accept” reflexively just to make them go away.

The attacker initiated a flood of login attempts—sending push notifications every few seconds. After a few minutes, one user, assuming the prompt was for a legitimate session they’d just started, tapped “Accept”.

Access granted.

Chapter 5: Email, Exfiltration, and Escalation

Now inside the user’s mailbox, the attacker began their search. They didn’t need to use any exploits or evade endpoint protection. Everything they needed was sitting in plain sight—attachments in Sent Items, sensitive conversations with clients, internal financial spreadsheets, and reports on pending projects.

The user was a senior manager in the Operations team. Their role gave them access to privileged information across multiple departments. They also routinely sent documents to third-party suppliers and clients—many of which contained confidential data.

The attacker downloaded several gigabytes of attachments and forwarded a handful of messages to an external address for good measure. By the time the company’s security team noticed the unusual mailbox activity and triggered a containment protocol, the data was gone.

No ransomware. No defacement. No warning.

Just silence.

Chapter 6: Culture and Complacency

The post-incident review revealed more than just technical shortcomings. It highlighted systemic cultural and behavioural issues that had chipped away at the company’s defences over time. The Role of Security Training

The company did provide mandatory security awareness training. In fact, all staff completed an annual e-learning course that covered:

  • Password hygiene
  • Phishing awareness
  • Use of public Wi-Fi
  • Reporting suspicious activity

So how did this happen?

Because like so many compliance-driven exercises, the training was seen as a tick-box activity. It lacked relevance to day-to-day tasks. It was filled with generic scenarios and jargon. And it didn’t adapt to changing user behaviours or real-world risks.

In other words, the information was technically delivered—but it didn’t sink in.

Users weren’t malicious. They weren’t reckless. They were under pressure, working fast, solving problems. In that moment, they prioritised convenience over caution—not because they didn’t know better, but because their environment made it easy to forget.

Security had become noise. Not value.

Breaking Down the Breach

This breach didn’t occur because of a lack of security tools. It happened because controls weren’t consistent, the user experience was poor, and the organisation relied on behaviour alone to enforce policy. Key Failings:

1. Unprotected Credential Storage

  • Sensitive usernames and passwords stored in plaintext with no access control.

2. Lack of Data Governance

  • No controls on where sensitive files could be uploaded or shared.

3. Inadequate Cloud Monitoring

  • No CASB or visibility into employee use of unsanctioned cloud services.

4. MFA Fatigue and Poor UX

  • Security prompts delivered with no context, leading to “approval fatigue”.

5. Flat Access to Sensitive Information

  • No segmentation or tiered access to sensitive content in user mailboxes.

6. Training Not Reinforced by Design

  • Awareness training not backed up by contextual policy enforcement.

How SASE Could Have Stopped This

Secure Access Service Edge (SASE) offers a fundamentally different approach to security—combining networking and security into a unified, cloud-delivered service. At its core, SASE is about enabling secure access based on identity, context, and continuous risk assessment.

Had SASE been implemented, this breach would have been stopped at multiple points.

🛡️ 1. Zero Trust Network Access (ZTNA)

ZTNA applies least-privilege access to every user, device, and application—regardless of whether they’re inside or outside the network perimeter.

Impact:

  • The internal spreadsheet could have been tagged as sensitive and restricted to IT-only access.

  • The Finance employee would not have been able to access or download the file at all.

  • Access to internal systems would be evaluated based on role, device trust, location, and time.

☁️ 2. Cloud Access Security Broker (CASB)

A CASB monitors cloud application usage and enforces policies for sanctioned and unsanctioned apps—preventing data from flowing to insecure platforms.

Impact:

  • Uploading a sensitive file to a non-corporate storage service would be blocked or flagged.

  • CASB could automatically encrypt or redact sensitive files before sharing.

  • Shadow IT usage could be detected and addressed proactively.

🧠 3. Data Loss Prevention (DLP)

DLP engines analyse content for sensitive data patterns (e.g. passwords, personal information) and apply real-time controls to prevent data leaks.

Impact:

  • The spreadsheet would have been detected and either blocked, encrypted, or quarantined.

  • Email and file-sharing systems would restrict transmission of such files.

  • DLP policies could have enforced granular controls based on user intent and risk level.

🔐 4. Adaptive Multi-Factor Authentication

Instead of static prompts, adaptive MFA uses contextual signals—like geolocation, login patterns, and device posture—to assess risk.

Impact:

  • Repeated login attempts from unknown IP addresses would trigger step-up authentication.

  • Contextual information (e.g. “Login from Poland – accept?”) could alert users to suspicious activity.

  • Excessive login attempts could be throttled or blocked before reaching the user.

✉️ 5. Email Security and Posture Management

SASE includes inline email protection and granular controls over content stored in mailboxes and file attachments.

Impact:

  • Sensitive attachments in email accounts could be encrypted or redacted automatically.

  • Access to Sent Items could be monitored for anomalous download behaviour.

  • Suspicious forwarders or forwarding rules could be automatically removed or quarantined.

🌐 6. Centralised Visibility and Policy Enforcement

With SASE, security policies follow the user—across devices, networks, and applications. Every connection is evaluated in real-time.

Impact:

  • The organisation could have correlated access to the credential file, cloud uploads, and login attempts.

  • Real-time alerts could surface behavioural anomalies before the breach escalated.

  • Forensics and remediation would have been faster and more accurate.

Conclusion: When Technology Meets Reality

Security doesn’t fail in a vacuum. It fails when people are rushed, distracted, tired, or overloaded. It fails when tools are disjointed, policies are unclear, and friction outweighs support.

In this story, every failure was human—and every failure was preventable.

But what this story really highlights is that prevention isn’t about blaming people for clicking the wrong thing or forgetting their training. It’s about designing systems where the right behaviours are the default, not the exception.

That’s what SASE delivers.

By embedding security into every edge of your network—users, devices, apps, and data—you reduce the dependency on perfect human behaviour. You minimise attack surfaces, detect anomalies early, and apply controls intelligently.

Because the question isn’t if someone will make a mistake. It’s whether your security architecture is ready when they do.