The same IP got into 29 companies and bounced off four

One IP address, 193.26.115.72, passed through dozens of Microsoft 365 tenants over four days in September. At four organisations it stayed outside 1,052 times. At twenty-nine others it got in, and the report that describes it sums that up as: "nothing stood in the way". Same attacker, same stolen tokens, same calendar. The only thing that differed was the configuration each company had in place before any of this started.

Two groups in the same attack

The numbers come from the report Huntress published on 22 October 2026 about a token spray and replay campaign against Microsoft 365. The window runs from 14 July to 22 September: ten weeks, 497 valid sign-ins across 79 organisations and over 200,000 failed attempts. All the activity came out of the 193.26.115.0/24 range belonging to a German hosting provider (1337 Services GmbH, AS210558, Hamburg), with six addresses the attacker rotated through in phases.

The report's paragraph about that address reads, in full: "Over four days, the address completed 303 successful sign-ins across 29 organizations. Conditional Access did real work here. The same address logged 1,052 blocked sign-ins as the attempts continued, but all of those blocks came from just four organizations. In the 29 organizations where it got in, nothing stood in the way."

It also has to be said that the report does not square with itself, and since this post's title depends on that, we are putting it on the table. In its mitigation section, the same document gives a different count for the same address: the same 1,052 blocks from four organisations, but 232 successful sign-ins at 28 different organisations, and it states there is no overlap between the two groups. 303 at 29 against 232 at 28. We use the phase narrative's figures because that is where they sit next to the 1,052 blocks, which is the comparison we care about; the two counts probably measure different slices of the same period. The difference is one organisation and it moves nothing in what follows, but anyone who goes to the source will meet both numbers.

A second caveat, because this is the kind of thing that gets lost in second-hand citation: the report does not publish each victim's Conditional Access configuration, so nobody on the outside can say "policy X stopped the attack at company Y". What is written, with a number and an attribution, is that the defended half of the split fits into four companies and that what did the work was Conditional Access. That asymmetry is the finding. There is something to be done about this attack, and what separates the two groups is whether somebody sat down and wrote a policy.

The token is issued after MFA

No passwords were guessed here. The sentence that sums up the campaign is that "the Microsoft accounts were compromised without the attacker ever needing a password". The three acquisition routes the report describes are adversary-in-the-middle relays that capture the session after MFA has already happened, device-code phishing, and social engineering during a legitimate sign-in.

The mechanics of the first one are the hardest to explain in a meeting. The victim does not see a sloppy fake page: they see the real Microsoft page, because the relay serves it to them unchanged. They type their actual password, they get the actual MFA prompt, they approve it, and they are in. Everything worked. What happens is that the session cookie Microsoft issues at the end of that process is kept by the adversary in the middle. And that cookie is, by definition, a session with MFA already satisfied: nobody is going to ask again. Demanding a stronger second factor on that screen changes nothing, because the theft happens one step after the screen.

Then comes the industrial part, which is where the name comes from: tokens get replayed in bulk. More than 200,000 attempts for 497 hits leaves a success rate of under 0.25%, and that ratio tells you the truth about the method. Here we move into our own reading, since the report does not break down what those failures were: most of the bag is probably tokens that had already expired or been revoked, though some will be Conditional Access blocks and accounts that no longer exist. The attacker does not need to tell them apart; they try everything and keep whatever is still breathing. It is brute force, but against sessions instead of passwords, and the noise is part of the method.

The expensive part started after they got in

A sign-in is not worth money. Staying is what is worth money. And on that front the campaign was anything but noisy:

• Their own devices inside your directory. The report observes, across the whole campaign and scoped to one of the client groupings it calls Build A, "48 distinct Entra-joined devices named DESKTOP- plus exactly eight uppercase hexadecimal characters". That is not 48 at your place: it is 48 spread across the victims. A registered machine is a way back in that no longer depends on the stolen token.
• The user's MFA, wiped and replaced. "In 19 organizations, the victim's existing MFA methods were wiped and a new method registered within three hours of the first sign-in from a campaign address." Three hours is the clock you have to answer.
• Inbox rules with names nobody reads. The documented names are ., sss, ss, iT, ,., ........, s and d. They marked as read, deleted, or moved mail into folders such as RSS Feeds, RSS Subscriptions or Conversation History. Nobody looks there. That is the point: the account owner does not get to see part of their own mail.

The order matters: first a key that does not expire, then control of the second factor, then silence. Of the three steps, the only one your user might ever notice is the third, which is exactly the one designed to go unnoticed.

The control that addresses this exists, and it does not cover the browser

Microsoft has a control aimed literally at this. It is called token protection and it is a Conditional Access session control that, in its own documentation's words, "attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens, like Primary Refresh Tokens (PRTs), are accepted by Microsoft Entra ID when applications request access to protected resources". The idea is right: the token is cryptographically bound to the machine, and "this binding ensures that even if a threat actor steals the token, it can't be used from another device". Exactly the attack in the report.

Now the small print, which is published and is the part almost nobody mentions. The platform availability table on that same page (revised 14 August 2026) says: native applications on Windows, iOS/iPadOS and macOS, generally available; browser-based applications, preview on Windows and macOS and not supported on iOS/iPadOS. And the scope of that preview is narrower than it sounds: "browser-based application support is currently limited to selected web apps, browsers, and device configurations that access Azure Resource Manager". The resources where it does apply for native apps are Exchange Online, SharePoint Online and Microsoft Teams, plus Azure Virtual Desktop and Windows 365 on Windows.

Put the two together and you get the awkward sentence of the day: for this campaign's theft route, the control that addresses it is not generally available yet. An adversary-in-the-middle relay steals a browser session, and there token protection runs in preview and scoped to Azure Resource Manager. It is worth not turning that into a general law: tokens also get stolen on the native side, say by an infostealer on the machine, and for that case the control is mature. Nor is it a flaw to hide: it is documented behaviour, and the same page asks you to deploy it in report-only mode before enforcing it. What it does change is what you can promise in a meeting. If somebody tells you "we are covered, we turned token protection on", the next question is: native or browser, and for which resources?

What stops what, phase by phase

Resetting the password evicts nobody

The report says it in two sentences that belong taped to anyone's runbook: "a password reset alone does not remove attacker-registered devices or MFA methods" and "additionally, you must revoke sessions; a password reset alone does not invalidate the access token, which means the attacker could keep access until the token expires (Time to live of approximately 90 minutes)". Both point the same way: the password was not the way in, so changing it does not close the way in.

It is the same lesson we drew from this month's ransomware report, which we summed up then as recovering fast is not evicting the attacker: getting services back up and having evicted whoever got in are two different jobs, and the first is measured in hours while the second is measured by what you looked at. Here, what to look at is listed out: devices, methods, rules.

When NOT to: two things that look like the answer

Do not close this out by blocking addresses. It is the first thing everyone asks for when they see a specific range in a report, and it is tempting because it takes ten minutes and reads well in the minutes. But the report itself describes six addresses in the same /24 used sequentially across four phases: the block you write today covers yesterday's photograph. There is one case where it is worth it, and it is a different one: blocking now, with the incident open, to buy hours while you sort out the rest. As a permanent measure it is an indicator of compromise promoted to security policy, which is not the same thing.

And do not cut session lifetimes by reflex. Shortening the sign-in frequency sounds like a fix and carries a bill you pay somewhere else. A stolen token is used inside its window, so going from days to hours narrows the margin without closing it; in exchange, everybody starts seeing sign-in prompts several times a day. And a user trained for months to approve prompts without thinking is precisely the user the next relay needs. The setting that does move the needle is the one in the table's first row: credentials an intermediary cannot relay. With a warning we owe you even though it costs us the clean line: of the report's three routes, that credential only closes the relay one. Against device-code phishing and against social engineering during a legitimate sign-in it does nothing, because there the user really does authenticate on the real page; for those, the work is blocking the device-code flow if you do not use it and teaching what support asks for and what it never asks for.

This afternoon's check

Six steps. The first four are looking and get done today; the last two are deciding, and they are the ones that change the outcome next time.

1. List the Entra devices registered in the last ninety days and compare them against the inventory, not against your memory. Look for names like DESKTOP- followed by eight hexadecimal characters that nobody recognises. If your machine inventory lives in a spreadsheet nobody updates, this step will hurt, which is why it is first.
2. Pull authentication-method changes from the audit log for the last three months. What you are after is a pattern: a deletion and a fresh registration for the same user within the same hour. Every time it shows up, you call the user and ask. You do not assume.
3. Walk the inbox rules of every mailbox with Get-InboxRule and keep two things: one- or two-character names and destinations such as RSS Feeds, RSS Subscriptions or Conversation History. While you are there, list external forwards; it is the same sweep and it answers the other half of the question.
4. Hunt in the sign-in logs for what the report itself recommends: OAuth2:Token and Cmsi:Cmsi request types with node or a bare Mozilla/5.0 user agent. A user agent proves nothing on its own, but it is a dirt-cheap filter to start reading from.
5. Read your Conditional Access policies by their exclusions, not by their names. The report's recommendation is to require MFA or block "for All Users, All Cloud Apps, and All Client App types, unconditionally". Count how many of your policies really do that once you subtract the exceptions somebody added on a Tuesday for an urgency that has long since been resolved. And have a look at the conditional access policies you did not write too: there are policies in your tenant you did not write.
6. Decide which twenty people get a phishing-resistant credential this quarter. Not everyone at once, which is how you guarantee never starting: the ones who sign payments, the ones with privileged roles and the ones who talk to suppliers. And write the eviction runbook in six lines — revoke sessions, devices, methods, rules, forwards, warn the user through a channel that is not their mailbox — because three hours is not enough to improvise it.

Where this fits in what we do

We deploy and maintain other companies' Microsoft 365 tenants, and what this report portrays gets fixed by configuring things, which is work somebody has to do on an ordinary day, when there is no incident. That is the least glamorous part of the modern workplace — a machine inventory that adds up, authentication methods that get reviewed, mailbox rules nobody added on the quiet — and it is what decides which group of the split above you end up in. The Zero Trust layer is the formal name for the idea: that a valid session should not, by itself, be permission for everything.

If you want us to run the first four steps with you on your own tenant — devices, methods, inbox rules and the sign-in hunt — let us talk. It takes an afternoon. And if it comes out clean, we will tell you and that is that: knowing it is not your turn is a useful result too.

Sources. The campaign, the dates (14 July to 22 September 2026), the 497 valid sign-ins across 79 organisations, the 200,000-plus failed attempts, the 193.26.115.0/24 range belonging to 1337 Services GmbH (AS210558, Hamburg) and its six addresses, the split for 193.26.115.72 (1,052 blocks at four organisations; 303 successful sign-ins at 29 organisations in the phase narrative and 232 at 28 with no overlap in the mitigation section — the discrepancy is the document's, not ours, and we flag it in the body), the 48 Entra-joined devices named DESKTOP- plus eight hexadecimal characters observed across the whole campaign and scoped to Build A, the 19 organisations whose MFA was wiped and re-registered within three hours, the inbox rule names and their destination folders, the hunt by request type and user agent, and the sentences about password reset and session revocation: Huntress, "M365 Token Spray and Replay Campaign Compromises Business Email Accounts" (22 October 2026). The coverage the case reached us through: Help Net Security, 23 October 2026. The definition of token protection, the platform availability table (native generally available; browser in preview on Windows and macOS and not supported on iOS/iPadOS), the preview's limitation to selected web apps accessing Azure Resource Manager, the supported resources and the recommendation to deploy in report-only mode: Microsoft Learn, "How Token Protection Enhances Conditional Access Policies" (revised 14 August 2026). All verified on 24 October 2026. What is not in those sources — which specific policy each victim had — we do not claim: it is not public.