- › Russian actors are exploiting a Microsoft Outlook Web Access flaw against government, telecom, and financial targets to retain mailbox access even after victims rotate credentials.
- › Password rotation is the first move in nearly every response plan, which makes a persistence mechanism that survives it especially effective.
- › Eviction is a separate job from rotation: revoke sessions and refresh tokens, audit mailbox rules and delegated access, re-enroll MFA, and review OAuth application grants.
- › The same pattern shows up outside email, in signed vulnerable drivers, scheduled tasks, and trusted software that runs with high privilege.
- › Write an eviction checklist now, run it as a drill, and define 'contained' as a state you verified rather than a step you completed.
There is a moment in every incident response that feels like relief. The compromised account is identified, the password is reset, everyone exhales, and the incident moves from active to cleanup. That moment is doing a lot of work in most organizations, and this week gave a clear example of why it should not.
Researchers report that the Russian actors recently tied to the Zimbra campaign have moved to a Microsoft Outlook Web Access flaw, using it against government, telecommunications, and financial targets across the US and Europe. The detail worth stopping on is not the vulnerability. It is that the technique lets them keep reading the mailbox after the victim rotates credentials.
Think about what that means operationally. A team detects the compromise, does the thing the playbook says to do first, marks the account remediated, and the adversary keeps reading mail. Every subsequent decision that team makes, including what to tell executives and regulators, rests on a containment claim that is not true.
Rotation Is Not Eviction
The confusion underneath this is worth naming plainly, because it is extremely common and it is not a sign of an unsophisticated team.
Rotating a credential invalidates one specific thing: the knowledge of a secret. It is the right first move, because a password an adversary knows is a door that opens on demand. But a password is only one of the ways into an account, and modern platforms are full of the others. Sessions that were already established. Refresh tokens that mint new access without ever presenting the password again. Application grants a user approved months ago. Mailbox rules that forward mail somewhere else. Delegate permissions that let another account read this one. Registered devices that are already trusted.
None of those care that the password changed. Some of them were created by the adversary specifically because they survive a reset, and some of them are legitimate platform features being used exactly as designed. Either way, the account is still reachable after the step that everyone treated as the fix.
This is the same lesson from a different angle as the zero-click Zimbra campaign we covered last week, which happens to be the same actor. There, the point was that a control assuming user action has nothing to catch when no action is required. Here, the point is that a response assuming the password is the access has nothing to remove when the access lives somewhere else.
What Eviction Actually Requires
If rotation is step one, here is what steps two through six look like for a compromised mailbox. None of this is exotic, and the reason it gets skipped is that it takes longer than a password reset and produces no satisfying moment of completion.
Revoke sessions and refresh tokens. This is the single highest-value action after the reset and the one most often missed. A refresh token issued before the reset can continue producing valid access tokens afterward. Sign the user out everywhere, at the identity provider, and confirm the revocation actually propagated rather than assuming it did.
Audit mailbox rules and forwarding. Attackers create rules that quietly copy mail to an external address, or that move security notifications into a folder nobody reads so the victim never sees the alerts about their own account. These rules persist through a password change and are invisible unless somebody looks at the rule list directly.
Check delegated and shared access. Delegate permissions, shared mailbox rights, and calendar access all let a different principal read the mailbox. If an attacker granted themselves delegation from a second compromised account, resetting the first account changes nothing.
Review OAuth application grants. A consented application holds its own access, independent of the user’s password. Malicious or abused app registrations are a well-established persistence route precisely because they survive credential changes and rarely appear in a response checklist.
Re-enroll multi-factor authentication. If the adversary registered their own authenticator or phone number during the intrusion, they hold a second factor that the reset does not touch. Removing unknown MFA methods and re-enrolling the user closes that path.
Look at registered devices and app passwords. Devices marked as trusted, and any legacy app passwords, can bypass the controls you are counting on.
Run that list and you have plausibly evicted the adversary from that mailbox. Run only the reset and you have changed a password.
The Pattern Is Bigger Than Email
Email is where this shows up most visibly, and the underlying failure generalizes to nearly everything.
Two other stories this week are the same shape. Silver Fox ran a bring-your-own-vulnerable-driver chain against a Japanese manufacturer, loading legitimately signed drivers with known flaws to obtain kernel access. A signed driver that the operating system loads willingly is persistence that sits underneath the tools you would use to find it. Separately, a state-sponsored campaign compromised trusted South Korean websites to abuse locally installed financial-security software and plant backdoors with no user prompt at all, turning the trusted software into the foothold.
In every one of these, the adversary’s real objective was durable access that survives whatever the defender does first. That is the professional standard now, and it means the question at the end of an incident cannot be “did we complete the remediation steps.” It has to be “can we demonstrate they are out.”
Define Contained as Something You Verified
The practical fix is a change in how a response ends, and it costs nothing but discipline.
Most incident processes have a status that means contained, and in practice it gets set when the assigned actions are done. Change the definition. Contained should mean you looked for the adversary after remediation and did not find them, using detections aimed at post-remediation activity: authentication from unexpected locations, mailbox access patterns that do not match the user’s normal behavior, new rules or grants created during or after the incident window, tokens minted from a session that predates the reset.
That requires two things you can build now, before the next incident. First, an eviction checklist specific to your platforms, written down, so the steps beyond rotation are part of the process rather than something an experienced responder happens to remember at 2 a.m. Second, a drill. Take a test account, simulate a compromise, run your process end to end, and find out which of the persistence paths above your current playbook misses. It will miss some. Better to learn that now than during the real thing, which is the same argument behind rehearsing any incident response plan rather than filing it.
The Uncomfortable Part
The reason this matters beyond the technical detail is what a false containment claim does downstream.
Once a team believes the incident is contained, everything after that inherits the belief. The executive briefing says the issue is resolved. The regulatory assessment is scoped to a window that has already closed. The decision about whether to notify is made on the assumption that access ended on a specific date. If the adversary was still reading mail the whole time, every one of those artifacts is wrong, and the correction, when it comes, is far more damaging than the original incident.
Adversaries know that response playbooks lead with credential rotation. Building persistence that survives it is not an exotic innovation, it is the obvious counter to a predictable move, and this week’s OWA campaign is what it looks like in practice against serious targets.
So keep rotating credentials first. It is still the right opening. Just stop treating it as the end, and make the last question of every incident the one that actually matters: what would we see if they were still here, and did we go look?
If you want to know whether your response process would actually evict an adversary or just change a password, that is the work we do. Start with our free Human Attack Surface Score, or contact Grab The Axe and we will test it the way an adversary would.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
