The whole company had access to the secrets vault. One group rule was all it took
The client asked for one thing: a check on whether their Azure cloud is set up the way it should be. All we got to work with was a read-only account.
Within a few days that same set of permissions showed us a production data warehouse open to the entire internet, a secrets vault reachable by every employee, and a disabled account that still held the Owner role.
Here is how a ready-made attack path came together from configuration alone, without a single cracked password, and exactly what we mapped to MITRE ATT&CK.
Context
It started with something we usually praise in reports. The client had moved one of their Azure Key Vault stores to the authorization model Microsoft recommends, Azure RBAC. Exactly as good practice says to.
A moment later we were looking at a dynamic group rule that granted read access to the secrets in that vault. The rule said: any user of type Member. In practice that meant every new employee got access to the secrets and certificates automatically, on the day their account was created. Several hundred people. Nobody had granted it deliberately. The group simply did what its rule told it to.
This is a typical moment in cloud configuration audits. Someone did a thing by the book and still left the door wide open, because two good ideas met in the wrong place. Only afterward did we get to the rest: why the client came to us, what the environment looked like, and why a read-only account was enough to see all of it.
The environment was typical of an organization that grew faster than its housekeeping in the cloud. An Entra ID tenant, one production Azure subscription, several hundred accounts, seven key vaults, two Synapse Analytics environments, a few Azure Storage accounts with production data. We ran the audit against the CIS Microsoft Azure Foundations Benchmark v5.0.0, combining automated tests with a manual review of the configuration.
Challenge
The cloud rarely loses to one spectacular hole. It loses to a stack of small things, each of which on its own seems survivable.
We also had to give the other side its due. The identity controls weren't foolish. Some vaults ran on Azure RBAC, access was at times split into read and admin groups, a backup existed at all. The problem wasn't that nobody had tried. It was that a few individual settings, each set "for later," stripped all the value out of that effort.
Our task came down to the question every CISO asks after a late-night phone call: if an attacker took over one ordinary account, how far would they get before anyone noticed. The answer we found was uncomfortable. Far. And it probably wouldn't have been noticed, because query auditing and threat detection on the warehouse were turned off.
What we did
We were given a single account with three read roles: Reader, Key Vault Reader, Log Analytics Reader. No permission to change anything. From it we enumerated identities in Entra ID, RBAC assignments on the subscription and resources, the network configuration of the services, and the settings of the key vaults and Storage accounts. Then we built the paths an uninvited guest would take.
Three of them are worth showing in full.
The first is the dynamic group for secrets. The key vault sat on the correct RBAC model, but the group with read access had a membership rule that covered every ordinary employee. On top of that, public network access to the vault from all networks. One person's credentials, any person's, used from anywhere in the world, opened the contents of the vault.
The second is the production data warehouse on Synapse Analytics. The firewall rule let in traffic from the entire public address space. The three settings driving the first two paths came down to this:
# Reguła zapory workspace'u hurtowni (Synapse Analytics) name startIP endIP allowAll 0.0.0.0 255.255.255.255 # Reguła członkostwa grupy dynamicznej z odczytem sekretów (Entra ID) user.userType -eq "Member" # trafia tu każde konto pracownika, automatycznie # Uwierzytelnianie środowiska Synapse azureADOnlyAuthentication = False # aktywne lokalne konto administratora SQL
So the warehouse's access interfaces were reachable from any address in the world, and next to them ran a local SQL administrator account. That kind of login bypasses Conditional Access, MFA enforcement, and the whole Entra ID identity apparatus. Anyone who knows or guesses that password walks into production data with no network restriction at all. And since query auditing was off, they walk in quietly.
The third path is dead accounts with active permissions. A former employee's disabled account still held the Owner role on the warehouse workspace and on a Storage account. Add to that the guest accounts of an external subcontractor with access to the production warehouse, with named firewall rules letting in their private addresses, including one account long inactive yet still admitted to the production environment.
We tied it all together with a mapping to MITRE ATT&CK, since that's the clearest language for the blue team on the other side:
Result
The environment failed 60 of 155 CIS controls, and another 82 came back with a warning. We flagged two things as critical, to fix within seven days: the production warehouse's firewall open to the entire internet, and the dynamic group handing the whole company access to secrets. The project's overall risk landed in the upper half of the scale, but the point here is something other than a number. None of these findings needed a zero-day. They were all switches, on or off, that someone once left in the default position.
We translated the risk into the language the board uses to talk about money. A secrets vault open to everyone means one compromised laptop stands between an attacker and the keys to integrations and databases. A warehouse with no network limits and a local SQL login is a road to production data that skips MFA. A backup without Locked mode and without multi-person authorization is the scenario where ransomware deletes the copies first and encrypts second. 96 percent of secrets with no expiry date are credentials that stay valid forever, including the ones that leaked long ago or were forgotten.
We left the recommendations in a form you can check off, with a deadline and a priority on each:
- Remove the rule that lets the entire internet into the warehouse and limit access to trusted networks, or deploy a Private Endpoint. That's the first seven days.
- Narrow the dynamic group for secrets to the people with a real need, instead of a rule that covers every employee. Also the first seven days.
- Disable local SQL authentication on the warehouse and move to Entra ID identity only, so that access falls under MFA and Conditional Access.
- Strip all role assignments from the disabled account and review the access of the external subcontractor's guest accounts, including removing the named firewall rules.
- Turn on query auditing and threat detection in both warehouse environments, with logs sent to Sentinel, and raise Defender coverage at least for Key Vault and Storage.
- Assign expiry dates to secrets and add an Azure Policy that blocks the creation of secrets without an expiry.
A retest after implementation will confirm the controls are back in their proper positions. That's the good news in configuration audits: since the problem was in the settings, the fix is in the settings too, not in rewriting half the architecture.
How many of these settings in your cloud sit in the "for later" position today? If you don't know who has access to your secrets, or from what address someone can reach your warehouse, we can check it with read-only permissions, the same as here.
Book a call with a consultant. We'll go through the scope of an Azure configuration audit and where these "for later" settings tend to hide.
All case studies are anonymized by sector, without names, dates or any data that could identify the client, in line with confidentiality. We never publish real vulnerabilities or client technical data.