The administrator access a role review could not see
UK managed service provider
The client had already spotted a privileged account holding more power than it should, and had taken that power away. The reduction held in every view they could see. It did not hold in the one that mattered. Tested personally by a named, CREST certified practitioner.
Outcomes
- Assumed breach test of the Microsoft 365, Entra ID and Azure estate
- A route back to Global Administrator identified, traced and closed
- Inconsistent multifactor authentication enforcement demonstrated, not argued
- Every automated baseline result manually verified before it could be reported
- Around a third of the automated findings discarded as wrong or overstated
A UK managed service provider asked Tarian Labs to test their Microsoft 365 and Entra ID environment. They wanted a penetration test rather than a configuration audit: not a list of settings that differ from a benchmark, but an answer to the question of what an attacker holding one ordinary set of credentials could actually reach. Testing was carried out from a standard user account and a read-only account, with no administrative access at any point.
The challenge
This was not a neglected tenant. It had been built by people who knew what they were doing, and in several places it was hardened well beyond what we usually see. User consent to applications was restricted. Legacy authentication was blocked. A delegated administration model was in place so that administrative roles were held through groups rather than handed out individually.
That is exactly the environment where an audit is least useful. Everything a compliance checklist asks about was already in place, and the client had no way of knowing whether the controls did what they believed they did. They wanted somebody to test the assumptions rather than the settings.
What we did
We started from the position an attacker starts from: a valid account, no administrative rights, and whatever the tenant hands out by default.
An automated baseline scan ran first, but its output was treated as intelligence rather than as evidence. Every result it raised was verified by hand against the tenant's own configuration before it was allowed anywhere near the report, and around a third of them did not survive that check. Some were overstated. Some described a control that was genuinely in place by a different mechanism than the tool knew to look for. Several were the same underlying issue reported four times. The client received the findings that survived, and an audit trail for the ones that did not.
The rest of the engagement was manual. We mapped who held which administrative roles, then mapped who controlled those roles, which is not the same question. We walked the mail, files and chat the test account could reach and searched them for credentials. We tested how multifactor authentication behaved rather than reading what the policy said it did. Where something could be demonstrated within the rules of engagement, we demonstrated it. Where it could not, we said so plainly and explained what the conclusion rested on instead.
The result
The finding that mattered most was one the client had already half solved.
They had judged that a particular account held too much privilege, and had taken that privilege away. The decision was correct and they reached it without any prompting from us. What had not been changed was the account's ownership of the groups that carry administrative roles. In Microsoft Entra, the owner of such a group can add members to it, and one of those groups carried Global Administrator and had no members in it. The account could put itself back, in one action, with no approval, no time limit and nothing asking it to justify the change.
The reason it survived is the interesting part. Group ownership does not appear in the role assignment view an administrator uses to review privilege. The control the client had put in place was reversible by the very party it was designed to constrain, and the reversal was invisible to the check that would ordinarily confirm it had worked.
Alongside it we demonstrated that multifactor authentication was not enforced consistently, using the tenant's own sign-in evidence rather than an argument about policy. We identified a backup product holding tenant-wide access to every mailbox and file on a credential valid for sixty years that the product provides no way to rotate. And we showed that an ordinary user with no group memberships could read hundreds of documents across the organisation, including its own vulnerability scan output: a ranked list of unpatched systems, sitting where any compromised account could find it.
None of it was exotic. It rarely is. Each had been a reasonable decision at the time, and none of them had a scheduled moment at which somebody was required to look again.
The client received a report written for two audiences, with remediation ordered by what closes the path fastest rather than by severity label. Where the tenant was strong, we said so, and in this environment a good deal of it was.
Client name withheld by agreement.
Tarian Labs did not just run the usual scans and call it a penetration test. They worked through the tool output and discarded what did not hold up, then showed us what the real findings meant in our environment, including a route to Global Administrator we believed we had already closed.
Want the same on your environment?
Tell us what you are running. We will come back within one business day with how we would scope it.