Ask most people what a mailbox compromise looks like and they will describe the loud version. Strange emails going out to the whole address book, someone in accounts getting a suspicious payment request, an apologetic message to clients the following morning. Noisy, embarrassing, over within a week.
The version that actually costs businesses money is quiet. Someone gets in, they look around, they set up a way to stay, and then they wait. The password gets reset at some point, for reasons that have nothing to do with them. The way back in keeps working. Months pass.
I have seen configuration left behind in a mail tenant sit undisturbed for the better part of a year. Not because anybody was careless, but because nobody was looking at that particular screen, and nothing about the business felt wrong.
What gets left behind
The techniques are not sophisticated. That is what makes them effective. Every one of them is a legitimate feature being used exactly as designed.
Forwarding rules
The classic, and still the most common. A rule that quietly copies incoming mail to an outside address. Sometimes everything, more often a filter on words like invoice, payment, remittance or bank, so the volume stays low and nothing looks unusual.
The refinement that catches people out is a rule that also moves the copied messages somewhere the owner never looks. A folder with a blank name, or straight into deleted items. The staff member sees a mailbox that behaves normally, because the mail they were meant to see has been read by someone else and tidied away.
Mail connectors
A step up, and considerably worse. Where a forwarding rule affects one mailbox, a connector is tenant-level configuration that governs how mail flows in and out of your entire organisation. An attacker with administrative access can add connectors that let them relay mail through your domain.
The damage is not to your data, it is to your name. Your domain sends the spam, your reputation absorbs the consequences, and the first symptom is usually your legitimate email starting to land in other people's junk folders for reasons nobody can explain. By then the configuration has often been sitting there for months.
Almost nobody checks this list. It is not part of anyone's morning routine, it changes rarely, and an extra entry with a plausible name looks like something a previous administrator set up for a good reason.
Application consents
The most durable of the three. Somewhere in the process, a person clicks accept on a permission request from an application, granting it ongoing access to their mail or files. The consent is recorded, the application keeps its access, and none of it depends on the password any more.
Reset the credential as many times as you like. The application still has what it was given, because it was given legitimately, by someone with the authority to give it.
Attackers do not break the rules to stay in. They use the features, exactly as documented, because that is what nobody audits.
Why it stays hidden
Three reasons, and none of them reflect badly on the people involved.
The first is that the incident felt closed. A password was reset, a ticket was updated, the status changed. Closed means somebody made a decision, not that the environment was checked. Those two things get conflated constantly, and it is worth asking your provider directly which one happened.
The second is that the evidence expires. Sign-in and audit logs in the platforms most businesses run on are retained for a limited window, commonly a few weeks unless you have specifically paid to keep more. Discover something six months later and the record of how it got there is simply gone. You are left with the artefact and no story, which makes it very hard to know what else was touched.
The third is that nothing feels wrong. There is no outage, no ransom note, no alarm. The business runs. That is the entire design goal.
What to actually check
You do not need to run this yourself, but you should know it is being run, and you are entitled to ask for the results in writing.
Across every mailbox: forwarding to external addresses, and rules that move or delete mail matching finance-related words. At tenant level: the list of mail connectors, with a reason for each one that somebody can actually explain. In identity: the applications holding consent to read mail or files, and who granted them. And underneath all of it, whether your log retention is long enough to answer a question you might not think to ask for another two months.
The connector check in particular is worth doing once across the whole organisation rather than only where you suspect a problem, because the whole point of the technique is that there is nothing to suspect.
The honest summary
If your business has had any kind of account compromise in the last two years, and statistically most have, the useful question is not whether the password was changed. It is whether anyone went looking for what was left behind, and whether that search covered rules, connectors and consents rather than just the one mailbox that triggered the alert.
If the answer is no, or nobody is sure, that is a contained and finite piece of work rather than a crisis. It is also the kind of thing that only gets more expensive the longer it waits, because the logs that would explain it are quietly ageing out.
This is standard ground in our security assessment, and it sits alongside the wider work we do on email security and Microsoft 365.
