Multi-factor sign-in (MFA) stops most stolen passwords. It doesn’t stop an attacker who steals the "proof of login" Microsoft hands you after you pass MFA. Security firm Huntress tracked a Microsoft 365 campaign between July 14 and Sept 22, 2026 that did exactly that. Victims typed their password and MFA code into a fake sign-in page, which passed them to the real Microsoft page and kept the sign-in token. The attackers then replayed those tokens from their own devices within minutes. Huntress counted more than 200,000 attempts, 497 successful sign-ins, 97 compromised accounts and 48 rogue devices across 79 organizations, per The Hacker News.

How they stayed in. Once inside, the attackers added their own authenticator app so they could pass MFA again after the stolen session expired. In at least 19 organizations, the victim’s existing MFA methods were removed and a new one registered within three hours of the first sign-in. They also registered fake computers in the company’s Microsoft directory, which stay there until someone deletes them. Huntress says the stolen tokens came from fake sign-in pages, device-code phishing and social engineering during a real login.

Why finance teams should care. The attackers set up hidden inbox rules with names like "." or "sss" that deleted incoming mail mentioning payroll, deposit and bonus, or moved it into rarely opened folders like RSS Feeds and Conversation History. One hijacked mailbox was used to send spam to hundreds of outside recipients before Microsoft flagged the account as high risk.

Action item: Did someone replay a sign-in? This week, have whoever runs your Microsoft 365 check:
1. Sign-in methods. Look at each person’s registered MFA methods. Is there an authenticator app or phone nobody recognizes, or did someone’s usual method disappear?
2. Devices. Review the devices registered in Microsoft Entra. Delete any computer you can’t match to a real person and machine.
3. Inbox rules. Open the rules on finance and payroll mailboxes. Look for rules with odd one- or two-character names, or rules that delete or move mail about payroll, deposits or bonuses.
4. Apps. Check for new enterprise applications nobody remembers approving.
5. If you find anything: revoke that user’s sessions and reset the password, then remove the rogue method, device or rule.

Longer term, Huntress recommends using Conditional Access to restrict device-code sign-in, and to require MFA (or block) for all users, all cloud apps and all client app types, with no exceptions. And tell payroll staff to confirm any direct-deposit change by phone, using a number already on file.

Also today

Brotli flaw: patched isn’t fixed until you restart. More fixes have shipped for CVE-2026-111497, a bug in Google’s Brotli decompression code that’s built into Node.js, Bun, .NET, Python packages and more. OpenAI’s Codex Security team reported it, and no real-world attacks have been reported, per The Hacker News. Microsoft shipped .NET fixes on Oct 25 (8.0.33, 9.0.22, 10.0.14), and Node.js is fixed in 22.23.4, 24.22.1 and 26.12.1. After updating, restart the service and rebuild any container images, because a running program keeps the old code until it restarts. Developers using Python’s Brotli or brotlicffi packages should check versions by hand (1.2.1 or 1.2.1.0 and later), because Dependabot may not flag them yet.