Huntress Adversary Infrastructure: Microsoft 365 Sign-In Blocks, Eligibility and Limits

The phrase is clever marketing, but the mechanism underneath is ordinary Entra plumbing: named locations, block policies and a review process that decides which IP ranges go into them. Administrators should understand what the feature does, what it needs, and where it stops working.

What Huntress actually shipped​

According to Huntress's product page, Adversary Infrastructure means that when our SOC confirms attacker infrastructure in one tenant, Huntress blocks it with Conditional Access in every eligible, opted‑in ITDR tenant. Huntress's same-day press release says the block reaches every eligible, opted-in Microsoft 365 tenant the same day.

In its launch blog, Huntress lists these details:

• Where it blocks: at the Microsoft 365 sign-in, before the attacker gets a session or token.
• What gets blocked: hosting, relay or proxy infrastructure that the SOC has tied to a confirmed compromise.
• Who maintains it: Huntress. There is no blocklist, policy or threat feed for the customer to manage.
• Cost: included in Managed ITDR for Microsoft 365 at no extra charge.
• Reporting: each block creates a Low severity incident report naming the targeted identity, the source and the campaign. Huntress says the credential the attacker tried to use is then rotated.
• Upkeep: Huntress says it checks every tenant daily, repairs drift, updates ranges as attackers move, and never changes customer-written policies.

That reporting point is a real change from how Huntress has handled CA before. Its existing support documentation says that attempts blocked by CAPs on their own do not generate ITDR alerts or escalations. A customer's own geo-block would have stopped an attack quietly. A block from an Adversary Infrastructure policy, as Huntress describes it, produces an incident report.

Section summary: Huntress turns attacker IP ranges confirmed by its SOC into CA block policies across its customer fleet. Each block produces an incident report and triggers credential rotation.

The Railway fire drill that started it​

The feature grew out of a one-off emergency. In March, Huntress says, a phishing-as-a-service operation abused Railway, a developer cloud platform with a clean IP reputation, to harvest tokens. Its device code phishing lures reached 344 organizations in five countries in under three weeks. Huntress argues that Microsoft's risk scoring had no reason to flag those logins, because Railway's addresses looked trustworthy.

Huntress's response was a hand-built CA policy blocking Railway's IP ranges. It checked the policy against 14 days of fleet traffic and then pushed it out. The company's livestream page says 305 attack attempts were stopped at the door, and no legitimate logins were affected.

At the time, consulting firm SaltData documented the objects Huntress created. These included a conditional access policy named [HUNTRESS] Block - Confirmed Adversary Infrastructure and a named location holding the campaign's IP ranges in CIDR notation. SaltData also offered a fair caveat: IP-range blocking is a valid short-term measure for confirmed adversary infrastructure, but it's a reactive control by nature.

Huntress appears to agree. Its own write-up says the attackers moved to new infrastructure after the block. That is the reason for making a one-time block into a maintained service.

Huntress also claims that across the 344 Railway victims, no two phishing lures were the same. It reads that as a sign that automation or AI wrote them, and it links the campaign to a PhaaS group called EvilTokens, which it says sells AI-assisted workflows. That is Huntress's assessment, not proven attribution. The scale figure is also Huntress's own count: 5,086 distinct attacker IP addresses hit its fleet in one 14-day window. The announcement does not give the dates or the method behind that number.

How a range gets nominated​

The validation process is the part of the system most likely to cause or prevent self-inflicted outages, so it deserves a close look. Huntress describes these steps:

1. Confirmed compromise. The SOC confirms a real incident in a real tenant and identifies the hosting, relay or proxy addresses behind it.
2. Engineering validation. The infrastructure must be datacenter or hosting space, scoped tightly to the evidence. It must show zero legitimate logins anywhere in the Huntress fleet and confirmed reports from at least two unrelated partners.
3. Second review. A second engineer reviews every nomination. If real users log in from an address, it does not ship.
4. Canary first. New campaigns go to Huntress's own canary tenants before customer tenants.
5. Fleet rollout. Each campaign gets one block policy with one named location, both labeled [HUNTRESS], rolled out to every eligible, opted-in tenant.

The rule requiring datacenter or hosting space carries most of the safety burden. A residential ISP range used by an attacker would also carry legitimate users. A hosting range that has never seen a real login across Huntress's whole customer base is a much safer block.

Huntress's figure of 17M+ protected identities is the company's own number. The "zero legitimate logins" results are also self-reported, and no independent audit backs them.

Two campaigns now on the blocklist​

Huntress names two campaigns that are now live in Adversary Infrastructure.

LSHIY LLC: password spraying through ROPC​

About three months after Railway, Huntress saw a password spray from a single IPv6 range linked to LSHIY LLC. Huntress counts more than 81 million login attempts. The attacker replayed already-validated credentials through ROPC (Resource Owner Password Credentials), a legacy OAuth flow that skips the interactive MFA prompt.

Huntress says the campaign compromised 78 accounts across 64 organizations. In 55 of those accounts, CA policies requiring MFA were active but did not cover the authentication flow the attacker used. In other words, those policies looked correct and still left a gap.

1337 Services GmbH: ten weeks of token replay​

The second campaign is covered in Huntress's detailed October report. Between July 14 and September 22, an attacker captured sessions through adversary-in-the-middle (AiTM) relays. The stolen tokens were then replayed from 193.26.115[.]0/24, a range owned by Hamburg-based hosting provider 1337 Services GmbH (AS210558).

Huntress responded at 79 organizations. It recorded 497 successful sign-ins and more than 200,000 failed attempts. Post-compromise activity included:

• At least 48 rogue Entra devices registered
• MFA methods wiped and replaced
• Hidden inbox rules
• A payroll-related email sent to an outside CPA

The rotation pattern explains why Huntress blocks ranges rather than single addresses. The operator worked through six addresses in the /24, one after another, with quiet periods between phases. Microsoft Entra ID Protection did flag several of those addresses as verified threat actor IPs, but it flagged them individually rather than as a range. Huntress concedes that blocking the /24 would have covered all six main replay hosts, though the operator also used a few other 1337 Services addresses outside it.

Section summary: Both campaigns came from hosting infrastructure. One got around MFA policies through an uncovered legacy flow; the other replayed stolen tokens while rotating through IPs in a single range. Range-level blocks address both patterns.

What "blocked at sign-in" really means​

Huntress says the attack "fails at sign-in" and "no token is issued." Microsoft's documentation shows exactly where that block happens.

Microsoft says CA policies are enforced after first-factor authentication is complete. Its guidance for location-based blocks also calls them restrictive and says they should be applied carefully, after thorough testing.

That explains the credential rotation. Huntress's own token-replay report tells defenders to treat a CA block (error AADSTS53003) as a sign of a valid credential, not a save, because the block comes after authentication succeeds. When an Adversary Infrastructure policy fires, the attacker probably holds a working password or token. Rotating that credential is the sensible next step.

The second limit concerns stolen tokens. Huntress's 1337 Services report describes a two-tier operation: AiTM relays capture the session, then hosting infrastructure replays it. In one July case, 12 minutes passed between the victim reaching the MFA prompt and the hijacked session appearing from a 1337 Services address. Huntress states plainly that blocking the replay range does not stop credentials from being captured. Blocking a relay also does not stop replay of tokens that were already stolen. The feature closes one door; the phishing still happens.

Microsoft's documentation also sets limits that are worth knowing:

• No more than 195 named locations per tenant
• No more than 2,000 IP ranges per named location
• Only CIDR masks greater than /8

Huntress uses one named location per campaign. Most tenants will never approach the 195 cap, but administrators who already use many named locations should keep the count in mind. That is a planning point from Microsoft's published limits, not a problem anyone has reported.

Where ISPM fits​

Huntress already offers Managed ISPM (identity security posture management), which also manages CA policies. The company separates the two roles this way:

The LSHIY campaign shows that the baseline matters more. A tenant that had restricted ROPC across the board would have been protected from that range and from any other range sending the same traffic. IP blocking catches a known adversary. Posture controls cover attackers who have not been identified yet.

Who can turn it on​

Huntress lists these eligibility rules:

• Existing ITDR partners are opted out by default and can enable the feature from the ITDR settings page.
• Partners onboarding from November 5 onward are opted in by default.
• Tenants need:
  • Entra ID P1 or P2 (Business Premium, or E3 with P1, and up)
  • Security Defaults turned off
  • A healthy, fully onboarded Huntress tenant

Tenants that cannot run CA still receive the same detections and incident reports. They get them after the sign-in instead of before it.

For MSPs, the opt-out default for existing partners is the part that needs action. Nothing changes for current customers until someone turns the setting on. Before doing so, administrators should:

1. Confirm licensing for each tenant.
2. Check whether Security Defaults is still on in any tenant.
3. List existing CA policies and named locations so the [HUNTRESS] objects are easy to identify.
4. Brief help desks that Low severity incident reports may start arriving.

Huntress has not published detailed rollback or audit-log procedures for the feature. Administrators should ask for them.

The bottom line​

Adversary Infrastructure is a sensible use of a large customer base. Hosting ranges with zero legitimate fleet traffic are about as low-risk as IP blocks get, and the 1337 Services rotation pattern shows why range-level, actively maintained blocks are better than chasing single IPs.

The effectiveness figures come from Huntress itself. The feature also blocks only infrastructure that has already hurt someone. Every campaign in Huntress's list began with a first victim who had to clean up afterward.

Opting in is low-cost extra protection, but it does not replace baseline controls. Blocking legacy authentication and ROPC, restricting device code flow, and covering all client app types in MFA policies will stop attacks this feature never sees.