Cloud Misconfiguration: The Breach You're Already Having

There's a kind of security incident that never makes the news. No alarms. No ransom note. It just sits there, quietly leaking data, until someone stumbles across it or an attacker decides to make use of it.

Cloud misconfiguration. The most common cause of cloud data breaches, and the one most businesses never notice they have.

If your company uses Microsoft 365, Azure, or AWS, and you set things up, ticked the boxes to get it working, and moved on, there is a decent chance something in your environment is misconfigured right now. Not because you're careless. Because the defaults aren't designed to protect you.

99% of cloud failures are your fault

Gartner predicted that by the end of 2025, 99% of cloud security failures would be the customer's fault.Not the cloud provider's. Not a nation-state actor's. The customer's.

That number lands differently when you realise what it actually means. Most cloud breaches happen because someone left a storage container open, gave a user account too many permissions, or never turned on a setting that was sitting right there in the admin panel.

These aren't clever attacks. They're configuration oversights. And they're happening constantly.

The door frame problem

Here's where most small and medium businesses get caught out: the shared responsibility model.

When you move to Microsoft 365 or spin up Azure resources, Microsoft handles the physical data centres, the power, the networking. They secure the platform itself. That's their half of the deal.

Your half is everything on top. User accounts. Permissions. Storage settings. Authentication policies. Logging. Data classification. Every toggle, dropdown, and policy configuration inside your tenant.

I've heard it put this way: Microsoft gives you the door frame. You have to build the door.

Most SMEs don't know they're supposed to be building a door. They assume Microsoft took care of it. Microsoft didn't. AWS didn't. Google didn't. The provider secures the infrastructure. You secure the configuration. When nobody does that second part, things go wrong quietly.

What “misconfigured” actually looks like

These are the specific things we find when we review cloud environments for small and medium businesses.

Legacy authentication is still switched on

Microsoft 365 supports older authentication protocols that were designed before multi-factor authentication existed. These protocols let users log in with just a username and password, bypassing MFA entirely. They're enabled by default in many tenants.

An attacker who gets hold of a password, through phishing, a credential dump, or a reused password from another breach, can log straight into your email without triggering a single MFA prompt. They use a legacy protocol because they know it's probably still open.

Once inside, they create inbox rules that quietly forward emails to an external address. Financial approvals, client communications, invoices with bank details, all silently copied out. We've seen this run undetected for weeks.

MFA is available but not enforced

There's a difference between turning MFA on and enforcing it. Plenty of businesses have MFA enabled as an option but haven't set a policy requiring every user to complete enrolment. Staff who never bothered to register still log in with just a password.

Some tenants have MFA enforced for admin accounts but not standard users. Better than nothing, but it misses the point. Attackers don't need admin access to read email or download files from SharePoint. A compromised standard account is plenty.

Unmanaged devices connect freely

By default, Microsoft 365 lets any device connect using nothing more than a password. Somebody's personal laptop, a hotel business centre PC, a phone with no pin code. Any of them can pull up your company data if the password is right.

Without conditional access policies restricting which devices can connect and from where, there's no boundary between managed, trusted hardware and everything else.

Storage is publicly accessible

This affects Azure and AWS more than Microsoft 365, but it's the most exploited cloud misconfiguration worldwide. Storage containers (Azure Blobs, AWS S3 buckets) set to public or anonymous access during initial setup or testing, then never locked down.

Sensitive files sitting on the internet, accessible to anyone who knows or guesses the URL. Admin scripts with credentials in them. Client data. Database exports. Backup files.

This is the misconfiguration that caused the Capital One breach. A web application firewall role with far too many permissions, a server vulnerable to a well-known request forgery technique, and 100 million customer records walked out the door. The attacker wasn't running custom exploits. They used a known technique against a misconfigured environment. The company's total cost: over 300 million dollars.

Nobody turned on the logs

Many cloud environments have logging disabled or set to minimal retention. AWS CloudTrail, Azure Activity Logs, the tools that record who did what and when, are often left in their default state. In some cases that means they're not capturing anything useful.

When a breach is eventually discovered, the first question is always: what did they access? Without proper logs, you can't answer it. You know something happened but you can't say how far it went. That makes incident response harder, regulatory notification harder, and insurance claims harder.

What this costs when it goes wrong

The average cost of a data breach globally is 4.4 million dollars. In the US it's closer to 7 to 9 million. Capital One's misconfiguration bill came to over 300 million dollars. The attacker was fined 250,000. The company paid the other 299.75 million.

Those are big-company numbers, but the mechanics scale down. A large enterprise can absorb a breach and keep operating. For a small business, the combination of incident response costs, legal fees, regulatory fines, and lost client trust can close the door permanently.

There's a time cost too. Post-breach remediation doesn't take days. It takes months. Leadership time gets eaten by forensic investigations, regulatory inquiries, insurance negotiations, and client damage control. Six months of the business running in crisis mode, not because of some advanced attack, but because a setting was wrong.

What to do about it

You don't need a transformation programme for this. You need a configuration review and a set of habits.

Lock down identity

Disable legacy authentication in Microsoft 365.This should have been turned off years ago. If you're not sure whether it's still active, assume it is.

Enforce MFA for every user, not just admins.Use conditional access policies to block logins from unrecognised devices and unexpected locations. And if you're still using SMS-based MFA, consider moving to something stronger. Hardware security keys and passkeys resist the token-theft attacks that can bypass traditional MFA.

Review admin privileges. Nobody needs Global Admin rights on the account they use for daily email. Cut permissions back to what each person actually needs. This one change limits how far an attacker can move if they compromise a single account.

Harden your cloud resources

Block public access on every storage container, blob, and bucketunless there's a documented business reason for it to be public. If you use Infrastructure as Code tools like Terraform, scan your templates before deployment. Roughly half of all Terraform files analysed in industry studies contain errors that open security gaps.

Get rid of long lived access keys.If you're running services on AWS with permanent IAM credentials baked into scripts, those keys are one GitHub push or one compromised laptop away from being in someone else's hands. Use federated identities and short lived credentials instead.

Switch on visibility

Enable Microsoft Defender's foundational Cloud Security Posture Management.The basic tier is free and will score your environment against benchmarks like CIS and NIST. It won't fix anything, but it will tell you where the gaps are.

Turn on activity logging and set a retention policy. Three years is a reasonable minimum. If something happens eighteen months from now, you want to be able to look back and see what was going on in your environment today.

Stop treating security reviews as an annual event. Cloud configurations drift. Someone changes a setting to fix a problem, forgets to change it back. A new service gets spun up without the same policies applied. A contractor gets temporary access that quietly becomes permanent. Annual audits miss all of this. Quarterly reviews catch most of it. Continuous monitoring catches the rest.

Go and check

If you take one thing from this, make it this: run a configuration review on your Microsoft 365 tenant and any cloud infrastructure you're running. Not next quarter. Now.

Is legacy authentication actually disabled? Is MFA enforced for every user, or just switched on? What are your conditional access policies doing? Are your storage containers locked down?Could you actually answer the question “what happened?” if something went wrong tomorrow, or would you be staring at empty logs?

Most of what you find will be fixable in an afternoon. The rest is still cheaper than finding out the hard way.

The cloud provider gave you the door frame. Time to check whether you actually built the door.

Bluestone Cyber runs cloud configuration reviews for UK businesses running Microsoft 365, Azure, and AWS. If you're not sure what your environment looks like under the surface, get in touch. We'll show you exactly where you stand.