Case study · Permissions
When suddenly everyone could see into every mailbox
A data security service provider had upgraded its Windows and Exchange servers to a new version. Afterwards, practically every employee could open every mailbox and enter every folder on the server – including the management and accounting folders. The fact that both happened at the same time was the decisive clue.
A security service provider with 50 administrators was stuck
The company served large communications providers and employed around fifty administrators. So there was plenty of expertise – but it was spread across networking, operating systems, security technology and client projects. When it came to the question of why permission inheritance of all things had broken after a migration, nobody had the relevant experience.
That is not negligence but a matter of specialisation. People who look after firewalls and intrusion detection every day rarely face an Exchange migration with a permission structure that has grown over years. That is exactly why someone from outside was brought in.
The time pressure came from the situation itself: as long as access was open, anyone in the company could view HR files, contracts and accounting data. It would hardly have been noticed afterwards – read access leaves no conspicuous traces.
Before going on site
What the combination of symptoms already gave away
Before anyone was on site, the range of possible causes could already be narrowed down. The decisive factor was something the people involved initially took for coincidence: mailboxes and file folders were affected at the same time. A fault in the Exchange update alone does not explain that – it would have left the file shares untouched. So there had to be something both systems have in common. Four possibilities remained:
- A general user group had been added to an administrative group. The quickest route to exactly this picture: anyone in an administrative group can get in everywhere – without anything having been changed on an individual mailbox or folder.
- A group had been given far-reaching rights on Exchange and the file server. In that case the problem would not be the membership but what the group had been granted in both places.
- A script with the wrong target ran during the upgrade. Migration scripts set permissions in bulk. One wrong parameter, and they hit the entire estate instead of a part of it.
- An administrative account had been compromised and the permissions changed deliberately. The most unpleasant possibility – and the one you have to rule out before repairing anything. If you just clean up without asking this question, you may lock an attacker in with you.
On site
Seven steps, in this order
The order is the real substance of this case study. It leads from the visible symptom to the common cause – and changes nothing until it is clear what needs changing.
Actually reproduce the access
Do not go by the description; try it yourself: open someone else's mailbox with an ordinary user account. Only once that works is it clear that this is not a misunderstanding – and you know exactly which access has to be explained.
Check this account's group memberships
Which groups is the user a member of, including nested ones? If an ordinary account sits in an administrative group, that usually already explains it.
Export all directly assigned full-access permissions
All mailbox-level permissions are exported and saved – as a complete list, not as spot checks. This snapshot is also the evidence of the state before any change was made.
Remove it on a single test mailbox first
The suspected wrong permission is removed from exactly one mailbox, and we check whether that really ends the access. If you change the whole estate at once instead, you will not know afterwards what had the effect – and in the worst case you bring operations to a standstill.
If nothing turns up at mailbox level, keep looking
If the export shows no suspicious entries, the cause does not lie there. That is not a setback but a result: it rules out an entire level.
Check higher-level Exchange and directory permissions
Permissions granted one level up apply to everything below, without being visible on any individual mailbox. That is exactly why checks that only look at the mailboxes find nothing here.
Cross-check the file folders
If the same users can also open all Windows shares, the common cause is narrowed down: a group in the directory service or changed inheritance on the file system permissions. Both affect both systems – and explain what an Exchange fault alone cannot.
Transferable lessons
What this means for every migration
The case is years old; the pattern is not. We still see the same gap in migrations today – including moves to Microsoft 365.
- Export permissions before and after the migration. Comparing the two snapshots shows within minutes what has shifted. Without the "before" state, any later discussion is guesswork.
- Migration permissions have an expiry date. Whatever is set for the move should be removed again afterwards – ideally written down before it is set.
- A successful sign-in proves nothing. The fact that everyone can work says nothing about who else could.
- Two or three spot checks are enough. Take an account from general administrative staff and try to open the management folder. This check takes five minutes and is almost never done.
- Read access leaves hardly any traces. Unlike deleted files, unauthorised reading is rarely noticed after the fact – which is why only checking beforehand helps.
- Today such a situation would be reportable. Since May 2018, open access to HR and accounting data can trigger a notification obligation under Article 33 GDPR. That did not yet apply at the time of this project.
Frequently asked questions
What prospective clients usually ask about this
Four hours sounds short. What made that possible?
The fact that there was one common cause. Mailboxes and file folders were affected at the same time – that rules out a fault in the Exchange update alone and inevitably points to something both systems share. Once you recognise that, you search in two places instead of two hundred.
The longer part was the assessment: reproduce, export, save, test on a single mailbox. The actual change took minutes. The other way round would have been dangerous – if you immediately withdraw permissions across the whole estate, you will not know afterwards what had the effect, and you can quickly bring operations to a standstill.
Why couldn't the in-house team of fifty administrators solve it?
Because it is a question of specialisation, not ability. The people there looked after security technology for large communications providers. An Exchange migration with a permission structure that has grown over years does not come up in that day-to-day work.
That is the usual reason why companies with their own IT department bring us in: not for day-to-day operations, but for something that happens to them once or twice a decade.
Was any data accessed while things were open?
That could not be established conclusively, and we said so at the time. Read access to file shares is not logged by default – without auditing switched on, there is simply nothing to analyse.
Which leads to the uncomfortable lesson: if you want to know afterwards whether something happened, you must have switched logging on beforehand.
Can this also happen when moving to Microsoft 365?
Yes, in a different form. There it is usually overly broad sharing in SharePoint and OneDrive, or permissions that were set while moving the mailboxes and never removed.
The countermeasure is the same: export the state before and after the move and compare. In Microsoft 365 this is actually easier, because the sharing that has been granted can be analysed centrally.
A note on confidentiality
For reasons of confidentiality, we only publish client names and contact persons with their express consent. That applies especially here: this is about a security gap at a security service provider. We are happy to provide further references from comparable projects to qualified prospective clients in a personal conversation, after agreeing this with the client concerned.
Free security check
Do you know who can access what in your company?
We export the permissions on your file shares and mailboxes and show you who actually has access. You get the result in writing – even if you do nothing further with us afterwards.
+49 221 984300-0Switchboard and support hotline
[email protected]Reply within 4 hours on working days
Robert-Perthel-Straße 7250739 Köln – Bilderstöckchen
Mon–Fri 9 am–6 pmEmergency support outside these hours by arrangement