Four weeks of briefings, and not one attacker defeated multi-factor authentication. Seven of the twelve lead stories end the same way: someone holding a signed-in session that MFA had already approved.
Read one at a time, the last four Weekly Briefings were four separate weeks of bad news. Read together, they are one finding: multi-factor authentication worked every time it was switched on, and it no longer decided the outcome.
When someone signs in, the password comes first and the second factor — a code or a push approval — comes next. What the service hands back is a session: a token that says this person has already proved who they are. Every page after that rides on the token. Nobody is asked for the password or the code again.
The answer to stolen passwords was MFA, and it is doing its job. The attacks in these four weeks went after the session instead — the thing MFA produces, rather than the thing it guards.
A session is a login that already succeeded. Whoever holds it is signed in, and your own logs record it as an ordinary sign-in by a real employee.
None of these seven broke the second factor. Each waited for it to succeed, then took the session.
The user signs in on Microsoft's real page and approves the real prompt. The token goes to whoever started the sign-in.
AUG 21A fake login window passes the one-time code to the real service while it is still being typed, and keeps the session that comes back.
AUG 28A relay page passes the real password and the real MFA through to Microsoft, then keeps a copy of the session cookie.
AUG 28A caller posing as IT support talks an employee through handing over credentials or approving a sign-in prompt.
SEP 4An employee pastes one line into Windows. An infostealer reads every saved session token out of the browser, usually in under a minute.
SEP 4Real remote-access software, installed by the user on a pretext, puts the operator inside the user's own signed-in session.
SEP 4Five had real users and were bought from their developers. A routine auto-update turned them into code that reads session cookies from inside the browser.
Our count, from the twelve lead stories in the Aug 15, 21, 28 and Sep 4 briefings — not a sourced statistic. We counted strictly: the other five follow a different pattern, though two of them (malware hiding in SharePoint and Teams traffic, and a fake help-desk chat on Teams) come close.
A look-alike sign-in page sits between the user and Microsoft. Everything typed passes straight through, MFA included. The real service issues a real session, and the page keeps a copy.
What beats it: sign in from your own bookmark or by typing the address. A sign-in page that arrived by link deserves suspicion, however perfect it looks.
No fake page at all. The attacker starts a genuine sign-in and gets the user to finish it: a message supplies a code to enter at microsoft.com/devicelogin, or a caller from “IT” asks for a prompt to be approved.
What beats it: real device sign-ins show the code on the screen in front of you — nobody emails it. And nobody approves a prompt because of an inbound call.
The user signed in normally, maybe days ago. Something on the workstation lifts the session that already exists: an infostealer run from a pasted command, a remote-access tool the user installed, or an extension that changed owners.
What beats it: name the one remote-support tool your IT provider uses, and treat any other as an incident, not a maintenance ticket. Allowlist extensions on managed devices — a store listing tells you an extension was clean when reviewed, not who owns it now.
All three routes end at the same object. Protecting the sign-in is still necessary. It is no longer the whole job.
Assets under management at the firm that confirmed attackers reached some of its cloud platforms between July 6 and July 10. The data included names, dates of birth, home addresses and Social Security numbers.
No software flaw and no malware. Operators called employees as “IT support” and talked them through handing over credentials or approving a sign-in prompt.
The size of the test payment. MFA was on every account except the CEO's, removed at his own request. The attacker read how he wrote to his finance team, copied the pattern, and sent a payment small enough to pass unnoticed. It cleared.
The amounts climbed until he saw the balance was wrong. The business almost missed payroll, with every other control in good shape.
The script cares about help-desk habits and payment routines, not assets under management — and a fifteen-person practice has both.
The accounts that ask for an MFA exception are usually the ones with payment authority. The exception is where this lands.
Open your incident-response steps, or ask your IT provider for theirs, and look for the line telling someone to reset the password on a compromised account. Every one of the last four briefings describes an attacker that step alone would not have removed.
The fix is the order, not a new product.
A password reset changes the lock. A stolen session is someone already inside. Your IT provider will know the exact steps for your systems; what matters is that revoking the session comes first, and is written down before the day you need it.
Controls that were installed, licensed and silent — including a Safe Mode reboot that kept endpoint protection from ever loading.
Read → AUG 21Three ways into Microsoft 365 without a working password, and why containment means revoking the token.
Read → AUG 28A relay kit linked to 4,532 organizations' email domains, a fake help desk on Teams, and the phone call behind the Apollo breach.
Read → SEP 4Pasted commands, genuine remote-access tools, and nineteen browser extensions caught stealing sessions.
Read →New analysis is published daily in the Threat Intelligence Center.
We implement the controls regulated firms need — managed firewalls, immutable backups, 24/7 monitoring, security awareness training — then maintain the quarterly evidence packages that examiners, insurers, and clients actually ask for.