Stop router DNS hijacks that steal Microsoft 365 tokens: a 48-hour remediation checklist for security teams

TL;DR: If routers are hijacking DNS responses, attackers can silently redirect Azure AD and Microsoft 365 authentication flows to steal refresh tokens and session cookies. This guide gives a prioritized 48-hour remediation checklist you can run as an incident playbook - detect rogue DNS, isolate affected assets, rotate Azure AD sessions and tokens, and harden routers to cut exposure from days to less than 48 hours.

Table of contents

• Quick answer
• Why this matters now - business stakes
• When this matters
• Definitions - concise terms you need
• 48-hour remediation checklist - prioritized actions
• Day 0 - detection and containment (hours 0-6)
• Day 1 - eradication and token control (hours 6-24)
• Day 2 - recovery and hardening (hours 24-48)
• Practical commands and verification checks
• Common mistakes
• FAQ
  • How quickly should we revoke tokens after confirming DNS hijack?
  • Will revoking tokens stop all attacker access immediately?
  • Can DNSSEC or DoT/DoH fully prevent these attacks?
  • How do we balance user impact with aggressive revocation?
• Get your free security assessment
• Next step recommendation for MSSP/MDR/IR support
• References
• What should we do next?
• How long until tokens are useless to the attacker?
• Can we detect token theft from router DNS alone?
• Which router settings reduce risk the most?

Quick answer

Router DNS hijack Microsoft 365 mitigation starts with three priorities: stop poisoned DNS responses at the network edge, revoke or rotate Azure AD refresh tokens and sessions for impacted accounts, and harden router and DNS configurations to prevent recurrence. If executed in the first 48 hours you can limit active token misuse, restore trusted name resolution, and reduce lateral access risk by 70-90% relative to an unmitigated compromise - provided tokens are revoked and MFA is enforced quickly.

Why this matters now - business stakes

A router DNS hijack redirects legitimate hostname resolution. For Microsoft 365 this can mean an attacker points login endpoints to an adversary-controlled server. The attacker can capture OAuth or SAML exchanges, intercept refresh tokens, and impersonate users without a password. Costs include:

• Immediate account takeover risk for admins and business-critical accounts - potential for data exfiltration and mail forwarding attacks.
• Operational downtime: user outages for mail and collaboration while remediation runs - typical internal SLA hits of 4-48 hours per major incident if unprepared.
• Regulatory and breach notification exposure depending on data accessed.

This is a cross-team incident - networking, security operations, identity, and executive leadership must act together.

When this matters

This checklist matters whenever branch or edge routers are managed outside of a central, hardened fleet and clients rely on those routers for DNS. Typical high-risk situations include:

• Distributed organizations with remote or branch offices that use on-premise or ISP-managed routers.
• Environments where remote management or legacy RMM tools are enabled on routers without strong access controls.
• Estates with delayed firmware patching or inconsistent vendor-signed image verification.

In those cases the risk is not theoretical. Focused router DNS hijack Microsoft 365 mitigation is critical when user logins, email routing, or authentication redirects traverse edge devices you cannot fully inventory. Acting quickly prevents attackers from converting poisoned DNS into long-lived refresh token theft and session abuse.

Definitions - concise terms you need

• Router DNS hijack: an attacker changes the DNS resolver or responses at a router or edge device so clients receive malicious IP addresses for legitimate hostnames.

• Refresh token theft: stealing long-lived tokens that allow issuance of new access tokens without reauthentication.

• Microsoft 365 session revocation: actions that invalidate refresh tokens and sessions in Azure AD so stolen tokens stop working.

• MFA enforcement: requiring multi-factor authentication to raise the difficulty of reusing stolen credentials or tokens.

48-hour remediation checklist - prioritized actions

This checklist is ordered by impact and time to run. Assign teams and SLA expectations for each step.

• Immediate containment (0-6 hours) - isolate suspect routers and switches; redirect clients to known-good resolvers.
• Identity control (6-24 hours) - revoke refresh tokens for compromised accounts; force reauthentication and password resets for high-value users.
• Network eradication (24-48 hours) - restore router firmware, remove attacker access, and apply configuration hardening and logging.
• Validation and recovery (within 48 hours) - verify DNS integrity, confirm token revocation effectiveness, and restore services with documented handoff.

Expected outcomes after 48 hours when checklist followed:

• Exposure window for active stolen tokens reduced to under 48 hours.
• Number of accounts able to be abused drops by an estimated 70-90% when tokens are revoked and MFA enforced promptly.
• Mean time to contain (MTTC) reduced compared to ad hoc response - measurable SLA improvement.

Day 0 - detection and containment (hours 0-6)

Action items - immediate triage and containment.

1. Identify scope and indicators

• Ask: Which subnets and endpoints use the affected router? Pull DHCP and endpoint logs.
• Look for anomalous DNS server settings on client endpoints: compare against known-good resolvers.

2. Redirect name resolution

• Push temporary DHCP option updates or local policy to set resolvers to trusted public DNS (Cloudflare 1.1.1.1, Google 8.8.8.8) or internal secure resolvers. This reduces further poisoning while investigation runs.

3. Isolate the router

• If feasible, remove the router from upstream networks or place it in a dedicated VLAN to stop attacker egress.
• Replace with a known-good device or fallback configuration.

4. Preserve evidence

• Capture router configuration, logs, and memory if supported. Record timestamps and change history.

Time goals: complete steps 1-4 within 6 hours. Outcome: stop additional DNS redirection and preserve forensic evidence for token linkage.

Day 1 - eradication and token control (hours 6-24)

Action items - stop attacker access to identities and sessions.

1. Identify impacted accounts

• Query authentication logs for unusual IPs, refresh token issuance, and failed MFA prompts. Prioritize admin and high-privilege accounts.

2. Revoke refresh tokens and sessions

• Use Azure AD methods to revoke refresh tokens for targeted users.
• Example PowerShell command (AzureAD module):

# Revoke all refresh tokens for a user
Connect-AzureAD
$UserId = "<user-object-id>"
Revoke-AzureADUserAllRefreshToken -ObjectId $UserId

• For bulk revocation, script through a prioritized list. Microsoft docs: https://learn.microsoft.com/en-us/powershell/module/azuread/revoke-azureaduserallrefreshtoken?view=azureadps-2.0

3. Force reauthentication and require MFA

• Set conditional access to require MFA for all interactive and risky sign-ins. Use short-lived policies while incident response runs.

4. Reset credentials where indicated

• For compromised admin accounts, perform password resets and confirm recovery phone/emails are correct.

Time goals: complete targeted revocations and MFA enforcement within 24 hours. Outcome: attackers lose live refresh tokens and MFA requirement increases reuse difficulty.

Day 2 - recovery and hardening (hours 24-48)

Action items - remove backdoors and prevent recurrence.

1. Rebuild or reconfigure routers

• Reflash router firmware from vendor-signed images.
• Replace default credentials and use strong admin passwords or centralized management with MFA.

2. Harden DNS configurations

• Disable remote management on edge devices. Only allow management from a jump host with MFA.
• Configure DNS over TLS or DNSSEC where possible, or use secure internal resolvers behind authenticated controls.

3. Audit and monitoring

• Enable DNS query logging, forward logs to SIEM, and add detection rules for NXDOMAIN spikes and unusual authoritative responses.
• Add network-based detection for unexpected HTTP/S certificates during auth flows.

4. Post-incident validation

• Verify user sessions are healthy and users can reauthenticate. Confirm no attacker-controlled resolvers remain.

Time goals: finish hardening and validation by 48 hours. Outcome: trusted resolution restored, persistence removed, and monitoring increased to detect recurrence.

Practical commands and verification checks

Use these checks to verify DNS integrity and to find evidence of hijacking.

• Check the default gateway and DNS servers on a Windows host:

# Get default gateway and DNS servers
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address, IPv4DefaultGateway, DNSServer

• Check DNS resolution against a trusted resolver:

# Linux / macOS example with dig
dig @1.1.1.1 login.microsoftonline.com +short

• Confirm Azure AD refresh token revocation with sign-in logs:

# Example: list sign-ins for user via Microsoft Graph PowerShell
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userDisplayName eq 'Alice'" | Select-Object CreatedDateTime, IpAddress, AppDisplayName

• Inspect router config for unusual DNS entries. Common places to check in admin UI:
  • WAN DNS server fields
  • DHCP server DNS settings
  • Static DNS entries and DNS forwarding rules

Verification goal: authoritative name resolution for Microsoft endpoints resolves to known Microsoft IP ranges. If not, continue containment.

Common mistakes

Security teams often make avoidable errors during router DNS incidents. Watch for these and the quick fixes that reduce recovery time:

• Treating DNS only as a network problem. Fix: Coordinate identity and networking teams immediately so token revocation is triggered while DNS is being corrected.
• Changing router settings directly without preserving forensic evidence. Fix: Capture configs, logs, and memory snapshots where possible before applying remediation.
• Relying solely on router firmware updates and ignoring DHCP or host-level overrides. Fix: Use temporary DHCP pushes or local host overrides to force trusted resolvers while devices are rebuilt.
• Overbroad token revocation without prioritization. Fix: Revoke admin and high-risk accounts first, then escalate to bulk revocation with communication plans.
• Assuming DNSSEC alone stops the attack. Fix: Treat DNSSEC as one layer. Combine resolver hardening, DoT/DoH, management access controls, and token controls.

Avoiding these mistakes shortens containment and lowers user impact during router DNS hijack Microsoft 365 mitigation.

FAQ

How quickly should we revoke tokens after confirming DNS hijack?

Revoke highest-privilege and high-risk user refresh tokens within the first 6 to 12 hours after containment. For large estates, prioritize admins and service accounts then proceed in waves. Microsoft documentation for revoking tokens and session controls is here: Revoke refresh tokens using Azure AD PowerShell.

Will revoking tokens stop all attacker access immediately?

Revocation prevents future token exchanges but does not retroactively remove any access already established by active sessions tied to short-lived access tokens. Combine revocation with conditional access policies that require reauthentication and MFA. See Microsoft’s guidance on conditional access and authentication management: Manage authentication methods and Conditional Access fundamentals.

Can DNSSEC or DoT/DoH fully prevent these attacks?

DNSSEC helps protect the integrity of DNS records but adoption and validation gaps mean it is not a single solution. DNS over TLS or HTTPS (DoT/DoH) secures client-to-resolver transport. Use DoT/DoH, DNSSEC where available, and trusted resolver enforcement to create layered protection. See Cloudflare’s explanation of DNS hijacking and DoT/DoH: What is DNS hijacking? and Cloudflare DNS over HTTPS and TLS docs.

How do we balance user impact with aggressive revocation?

Communicate clearly and stage revocation. Start with high-value users, then broaden scope. Provide self-service guidance for reauthentication and expect short helpdesk spikes. Prioritize speed for admins and service principals to limit lateral movement.

If you need hands-on assistance, CyberReplay can run an emergency token-control wave and coordinated edge remediation: see our assessment and services links below.

Get your free security assessment

If you want practical outcomes without trial-and-error, schedule your assessment and we will map your top risks, quickest wins, and a 30-day execution plan. For immediate edge posture work and incident engagements, see CyberReplay’s emergency offerings: CyberReplay cybersecurity services and How we respond when you’ve been hacked.

Next step recommendation for MSSP/MDR/IR support

If you lack internal capacity to execute this 48-hour checklist, engage a provider that can operate across networking and identity. Recommended next steps:

• Run an immediate posture assessment for edge devices and active directory trust boundaries. CyberReplay offers focused assessments you can trigger as an emergency engagement: CyberReplay cybersecurity services.
• Request a focused incident response retainer or on-call MDR support to execute token revocation, router reconfiguration, and forensic capture in parallel. For hands-on help and playbook execution details see: Help, I’ve been hacked.

If you want a quick readiness check before committing to a vendor, use a short one-hour scorecard review: CyberReplay scorecard.

References

• Cloudflare - What is DNS hijacking?
• Cloudflare - DNS over TLS documentation
• Microsoft - Revoke-AzureADUserAllRefreshToken PowerShell cmdlet
• Microsoft - Sign-ins and audit logs in Azure AD (sign-in monitoring)
• Microsoft - Conditional Access overview and guidance
• Microsoft Graph - List sign-ins API (evidence for token misuse)
• CISA - Protecting Against Compromise of Network Infrastructure Devices
• CISA - Malicious Use of Remote Monitoring and Management Software (advisory)
• NIST - DNS Security guidance and resources
• US-CERT / CISA - Russian State-Sponsored Cyber Actors Targeting Network Infrastructure Devices advisory

What should we do next?

Start with a 2-hour tabletop with networking and identity owners to run the Day 0 steps and assign immediate actions. If you confirm hijacked DNS, activate token revocation and engage incident response support. A coordinated 48-hour window should be used to contain, eradicate, and recover.

How long until tokens are useless to the attacker?

If you revoke refresh tokens and force reauthentication, most stolen refresh tokens become unusable within minutes to an hour as Azure AD marks them invalid. Practical downtime for users is typically 15-60 minutes for reauth workflows if staged carefully. The key is speed - the faster tokens are revoked the less time an attacker has to use them.

Can we detect token theft from router DNS alone?

Not reliably. DNS evidence shows redirection, but token theft is proven by authentication logs, unusual refresh token exchanges, or access patterns. Combine DNS forensics with sign-in logs and SIEM correlation to confirm token misuse.

Which router settings reduce risk the most?

Prioritize these controls first:

• Disable remote management from WAN and restrict admin access to a secure jump host with MFA.
• Enforce vendor-signed firmware and timely updates.
• Set DHCP to deliver only trusted DNS resolvers and monitor for changes.
• Use DNS over TLS/HTTPS for client-to-resolver communications where supported.