Team: Huntress Managed Identity Threat Detection and Response (ITDR)
Product: Microsoft 365
Environment: Microsoft 365 (Microsoft Entra ID)
Summary: Learn how Adversary Infrastructure for Huntress Managed ITDR blocks Microsoft 365 sign-in attempts from confirmed attacker infrastructure by deploying and maintaining Microsoft Entra Conditional Access policies across eligible tenants.

In This Article

Requirements
What Is Adversary Infrastructure?
How It Works
Default Settings
Before You Begin
Turn Adversary Infrastructure On or Off
What Huntress Creates in Your Tenant
The Adversary Infrastructure Dashboard
Blocked Attack Incident Reports
Troubleshooting
Frequently Asked Questions

Requirements

A tenant receives Huntress Adversary Infrastructure policies only when all of the following conditions are met:

• The organization is protected by Huntress Managed ITDR and maintains a healthy Microsoft 365 connection.

• The tenant has Microsoft Entra ID P1 or P2 licensing (Microsoft 365 Business Premium, E3, E5, or a standalone Entra ID P1 or P2 license).

• Security Defaults are turned off. Conditional Access and Security Defaults can't run simultaneously, and Huntress will not alter this setting for you.

• Adversary Infrastructure is turned on for the organization.

What Is Adversary Infrastructure?

Huntress Managed ITDR detects and responds to identity compromises after an attacker signs in. Adversary Infrastructure adds a layer of prevention that stops those attacks at sign-in.

When the Huntress Security Operations Center (SOC) confirms a compromise in the hosting, relay, or proxy infrastructure for one tenant, Huntress blocks that infrastructure across all eligible tenants with Adversary Infrastructure enabled. Sign-in attempts from that infrastructure fail at authentication rather than becoming incidents: one partner's incident becomes every partner's protection.

Huntress builds, validates, and maintains every policy. You do not need to curate IP lists, write Conditional Access policies, or consume a threat intelligence feed. Adversary Infrastructure supports Microsoft 365 only.

How It Works

1. Confirm: The Huntress SOC confirms the attacker infrastructure behind a real identity compromise.

2. Validate: Huntress detection engineers check the IP addresses against legitimate traffic across the Huntress fleet and publish them as a campaign. Infrastructure that legitimate users rely on, such as ISPs, corporate VPN and SASE providers, and Microsoft and Cloudflare ranges, is never added.

3. Deploy: Huntress deploys each new campaign to internal test tenants first, then rolls it out to every eligible tenant that has turned on the feature. New campaigns and address changes reach deployed tenants within one business day.

4. Block: Microsoft Entra ID blocks sign-ins from campaign addresses at authentication.

5. Report: Huntress retrieves blocked sign-in events from your Microsoft Entra sign-in logs and delivers a Low-severity incident report for each targeted identity.

6. Maintain: Huntress updates IP address ranges as campaigns shift. A daily check compares Huntress objects in each tenant against the expected configuration and repairs configuration drift.

Default Settings

• Accounts that used Managed ITDR before Adversary Infrastructure became generally available on November 4, 2026, are opted out. You choose when to turn it on.

• Accounts onboarded on or after November 4, 2026, start opted in.

• An account-level setting determines whether newly added organizations automatically receive policies. Each organization can override the account default at any time.

• The enablement setting applies only to deployed Conditional Access policies. Managed ITDR detections, incident reports, and SOC response remain active regardless of whether Adversary Infrastructure is enabled or disabled.

Before You Begin

1. Confirm that each organization you plan to enable meets all criteria listed in the Requirements section.

2. Plan for your break-glass (emergency access) accounts. When Huntress deploys policies, it creates a security group named [HUNTRESS] CAP - Emergency Access Exclusion in the tenant. Add your break-glass accounts to this group one time, and every current and future Huntress policy excludes them automatically.

3. If your client requires change control approval for Conditional Access, inform them that Huntress will create policies and named locations in their tenant. Every Huntress object uses the [HUNTRESS] prefix, and Huntress never alters partner-created policies.

Turn Adversary Infrastructure On or Off

You can configure this setting across your entire account or for individual organizations. Only Huntress users with permission to modify Managed ITDR settings can view the Manage option.
 

Manage Settings for Multiple Organizations or an Entire Account

1. Log in to Huntress and go to the Managed ITDR dashboard.

2. On the Adversary Infrastructure card, select Manage.

3. On the Manage Organizations page, review the eligibility details for each organization (licensing, Security Defaults status, and Microsoft 365 connection health).

4. Select the checkboxes for the organizations you want to update, or select all organizations to change the account-level default.

5. Select Enable or Disable, then confirm your choice.
    

What Happens When Settings Change

• Enabling: Huntress deploys active campaign policies to the tenant. New campaigns take up to one business day to appear.

• Disabling: Huntress sets its policies in that tenant to off without deleting them. If you turn Adversary Infrastructure back on, policies re-enable immediately.

• Huntress logs every change made to this setting in the audit history.

What Huntress Creates in Your Tenant

Huntress provisions three distinct objects prefixed with [HUNTRESS] to distinguish them from your custom configurations:

• Named locations: One IP named location per campaign, marked as untrusted, containing blocked IP addresses in CIDR format.

• Conditional Access policies: One blocking Conditional Access policy per campaign applied to all users and cloud apps, scoped specifically to that campaign's named location.

• Exclusion security group: One security group named [HUNTRESS] CAP - Emergency Access Exclusion, excluded by all Huntress policies. Huntress creates this group empty for you to populate with break-glass accounts.

Policy Rules and Guardrails

• Huntress never modifies, disables, deletes, or rescopes any policy, named location, trusted location, or exclusion group you create.

• Huntress never turns off Security Defaults.

• Huntress policies only block confirmed attacker infrastructure. They never relax your MFA, device compliance, or location requirements, and they can't grant access that custom policies have denied.

The Adversary Infrastructure Dashboard

Access the dashboard at the account level or organization level by navigating to Managed ITDR > Adversary Infrastructure.

The dashboard includes:

• Protection overview: Summary of active protections across your organizations.

• Status summary: Overview of blocked sign-ins and related security signals.

• Coverage metrics: Status of protected organizations and active Conditional Access policies.

• Blocked sign-ins table: Detailed log of sign-in attempts blocked by Huntress policies.

The blocked sign-ins table displays only prevented authentication attempts. Unblocked activity, such as sign-ins in ineligible tenants, appears in the standard incident counter and on the Incidents page.

Blocked Attack Incident Reports

When a Huntress policy blocks an authentication attempt, Huntress delivers a Low-severity incident report for the targeted identity. Each report includes:

• Targeted user identity

• Source IP address and network details

• Matching threat campaign

• Timestamp of the sign-in attempt

Each identity and source IP address pair generates one report. Subsequent attempts from the same source IP address against the same identity within a 24-hour window roll into that single report.
 

Why Blocked Attempts Require Action

Conditional Access policies evaluate sign-ins after credentials pass primary verification. A blocked attempt from confirmed attacker infrastructure indicates that an attacker likely possesses valid credentials. Rotate user credentials immediately before the attacker attempts access from unblocked infrastructure.
 

Remediation Workflows

• Cloud-only identities: The incident report might include a Reset Password assisted remediation. Huntress executes this action only after an administrator approves the remediation plan within the incident report. Because Huntress does not store or transmit new passwords, a Microsoft 365 administrator must restore user access.

• Hybrid identities (synced from on-premises Active Directory): Huntress can't reset passwords synced from on-premises AD. The incident report provides a manual remediation step to rotate credentials directly within on-premises Active Directory.
   

Review the user's recent successful sign-ins and registered authentication methods for unrecognized additions. For detailed instructions, review our guide on Huntress Managed ITDR - Microsoft 365 Response Actions and Partner Responsibilities.

Troubleshooting

An organization displays as not eligible

Verify the following tenant settings:

• The tenant holds active Microsoft Entra ID P1 or P2 licenses.

• Security Defaults are disabled.

• The Microsoft 365 integration status displays as healthy in the Huntress Platform.

The organization is eligible and enabled, but [HUNTRESS] policies do not appear in Entra ID

• Confirm that Adversary Infrastructure is turned on for that specific organization, not just at the account default level.

• Confirm that Security Defaults are turned off and the Microsoft 365 connection is healthy.

• Allow up to one business day for policy deployment across internal testing and production tenants.

A Huntress policy was turned off in Entra ID and turned back on automatically

This behavior is expected. Daily automated checks detect configuration drift and restore Huntress policies to their active state. To disable policies, turn off Adversary Infrastructure for that organization in the Huntress Platform.

The Manage option is not visible on the Adversary Infrastructure card

Only Huntress users with administrator permissions to modify Managed ITDR settings can view Manage. Contact an account administrator to adjust your role permissions.

A Huntress policy blocked a legitimate user

1. In the Microsoft Entra admin center, open the user's sign-in log entry and select the Conditional Access tab. Confirm that a policy starting with [HUNTRESS] caused the block. If a custom policy triggered the block, review that specific policy rule.

2. Contact Huntress Support with the targeted user identity, the exact sign-in timestamp (including time zone), and the source IP address.

3. While Support investigates, turn off Adversary Infrastructure for that organization in the Huntress Platform. Do not edit the policy directly in Entra ID.

Frequently Asked Questions

Does Huntress change my existing Conditional Access policies?

Huntress creates and manages only objects prefixed with [HUNTRESS]. Custom policies, named locations, trusted locations, and exclusion groups are never modified. For more details, review How Entra Conditional Access Policies and Huntress Managed ITDR Work Together.

Will Adversary Infrastructure block legitimate traveling users?

No. Huntress policies target specific malicious hosting, relay, and proxy IP addresses rather than geographic regions. Traveling users do not require exclusions for Huntress policies. Travel exclusions still apply to custom location-based policies and Huntress ITDR expected location rules.

Does this replace geo-blocking or MFA policies?

Keep your existing policies active. Huntress policies block confirmed attacker infrastructure regardless of hosting location, including proxy nodes in commonly permitted countries. Custom MFA, device compliance, and location policies operate alongside Huntress policies.

Can I review which IP addresses are blocked?

Yes. In the Microsoft Entra admin center, each [HUNTRESS] named location lists its campaign addresses in CIDR format. The Adversary Infrastructure dashboard also lists active policies and associated blocked sign-ins.

Can I add custom IP addresses to a Huntress policy?

No. Automated daily checks revert manual modifications made to Huntress objects. To block custom IP addresses, create a separate named location and Conditional Access policy in Entra ID.

Does Huntress stop monitoring if Adversary Infrastructure is turned off?

No. This setting controls only automated Conditional Access policy deployment. Managed ITDR detections, incident reports, and 24/7 SOC response remain fully operational.

How are emergency access (break-glass) accounts protected?

Add break-glass accounts to the [HUNTRESS] CAP - Emergency Access Exclusion security group. All current and future Huntress policies automatically exclude this group.

What is the [HUNTRESS] Block - Confirmed Adversary Infrastructure policy?

This is a static, one-time policy deployed in March 2026 to mitigate the Railway campaign. It does not receive automated updates. Adversary Infrastructure campaign policies supersede and actively replace this policy.

Does Adversary Infrastructure support Google Workspace?

Adversary Infrastructure supports Microsoft 365 (Microsoft Entra ID) only.