1 / 8
Monthly Briefing · September 2026

Nobody broke your MFA.They didn't need to.

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.

8 SLIDES~5 MIN READCOVERS AUG 15 – SEP 4, 2026
Use → or swipe
What the month meant

The attacks moved one step to the right.


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.

Key insight

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.

The count
7 of 12

lead stories end with someone holding a signed-in session.

None of these seven broke the second factor. Each waited for it to succeed, then took the session.

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.

How the session changes hands

Three routes. One destination.


Route 1 · Relay

The page in the middle

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.

SEEN IN: MIRAGE2FA · RECRUITTRAP

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.

Route 2 · Approval

The user says yes

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.

SEEN IN: DEVICE-CODE PHISHING · APOLLO / BLACKFILE

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.

Route 3 · Theft afterward

Lifted off the machine

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.

SEEN IN: CLICKFIX · ANYDESK / SCREENCONNECT · 19 EXTENSIONS

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.

Key insight

All three routes end at the same object. Protecting the sign-in is still necessary. It is no longer the whole job.

Same mechanism, any size

A trillion-dollar firm and a small real estate office.


$1.05T
Apollo Global Management

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.

Weekly Briefing · Aug 28 →

<$1,000
A small real estate firm

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.

Weekly Briefing · Sep 4 →

The script cares about help-desk habits and payment routines, not assets under management — and a fifteen-person practice has both.

Key insight

The accounts that ask for an MFA exception are usually the ones with payment authority. The exception is where this lands.

One thing to do this month

Find the line that says “reset the password.”

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.

If yours says only this
  1. Reset the user's password.
It has to say this
  1. Revoke every active session for the account.
  2. Then reset the password.
  3. Then check the mailbox for rules created while the session was open — hiding replies is a common next move.

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.

Have us review your steps Read why a reset isn't enough

Evidence, not assurances.

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.

Brian Sammons
Brian Sammons · Founder Managing IT for Ohio professional service firms — medical, dental, legal, accounting, and financial — since 2004. Questions about how any of this affects your firm? Grab fifteen minutes on my calendar.
Capstone Technologies Group · 2071 N Bechtle Ave, Box 143 · Springfield, OH 45504-1583
captechgroup.com · (937) 319-1211 · Threat Intelligence Center
The Capstone Monthly Briefing · September 2026 · written for Ohio medical, dental, legal, accounting and financial firms.