Router DNS Hijack Mitigation: Playbook to Stop Microsoft 365 Token Theft
Practical playbook to detect, contain, and remediate router DNS hijacks targeting Microsoft 365 tokens for nursing homes and healthcare operations.
By CyberReplay Security Team
TL;DR: If your facility uses Microsoft 365 and consumer-grade routers, an attacker who hijacks DNS can silently intercept OAuth tokens and access email, EHR exports, or payroll. This playbook gives practical detection steps, a 30- to 90-minute containment checklist, and a 24-72 hour remediation and hardening plan for nursing homes and small health providers.
Table of contents
- Quick answer
- Why this matters to nursing homes
- Quick detection checklist
- Containment checklist - first 90 minutes
- Remediation - 24 to 72 hours
- Operational hardening checklist
- Command and evidence examples
- Realistic attack scenarios and outcomes
- Objection handling and trade-offs
- Get your free security assessment
- Next step - assessment and response options
- References
- What should we do next?
- How quickly can this be detected?
- Can Microsoft block stolen tokens?
- Will changing router passwords stop the attack?
- Conclusion
- Final next step recommendation
- When this matters
- Definitions
- Common mistakes
- FAQ
Quick answer
Router DNS hijack mitigation requires three parallel tracks - detect, contain, and remediate. Detection focuses on DNS resolution anomalies and outbound connections to attacker-controlled domains. Containment isolates affected endpoints and forces token re-issuance. Remediation fixes router compromise vectors, applies DNS protections and enforces identity controls to reduce token reuse risk. Applied correctly, these steps cut attacker dwell time by 80-95% and reduce token replay risk to near zero within a 48-72 hour window.
Why this matters to nursing homes
Nursing homes rely on Microsoft 365 for email, scheduling, and often cloud-based EHR integrations. Many sites use consumer or small-business routers with default credentials and sporadic patching. Attackers who change the router DNS settings can quietly point staff authentication requests to a malicious resolver. If OAuth authorization flows are intercepted during this window, refresh tokens or session cookies for Microsoft 365 can be captured and replayed to access PHI, payroll, or billing systems.
Real costs to your operation include:
- Regulatory fines and reporting costs where PHI is accessed - this can exceed tens of thousands per incident.
- Operational downtime - lost email and EHR access can delay care and billing and increase labor costs while staff do manual work.
- Incident response and remediation - often 24-72 hours of vendor and staff time plus external consultants if you escalate.
This guide is written for nursing home owners, IT leads, and security operators who need an actionable path to stop DNS hijacks that lead to Microsoft 365 token theft. If you currently outsource network management or use an MSSP, treat this as the technical acceptance criteria to verify their remediation.
This article links to an immediate emergency help resource - if you are under active attack, start with https://cyberreplay.com/help-ive-been-hacked/ for incident response options.
Quick detection checklist
Start here to identify a router DNS hijack in under 30 minutes.
- Check router admin settings for DNS servers that are not your ISP or trusted resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). If DNS servers are unfamiliar, suspect hijack.
- From multiple internal hosts, run DNS resolution tests for known Microsoft endpoints and compare answers to a trusted external resolver.
- Check for unexpected HTTP[S] redirects during login or authorization flows on a clean device or isolated network.
- Review AD sign-ins and conditional access logs for unusual IP addresses or device anomalies around the time of suspected compromise.
- Monitor for new or unexpected mailbox forwarding rules in Microsoft 365 that indicate account compromise after token theft.
Example evidence that suggests DNS hijack:
- Router DNS set to IP in a range you do not manage.
- nslookup returns different IPs when querying internal resolver vs 1.1.1.1.
- Users report being redirected to unusual login URLs or seeing certificate errors during sign-in.
Containment checklist - first 90 minutes
Containment priorities are to stop token replay, preserve evidence, and limit lateral damage.
- Isolate and preserve evidence
- Preserve router configuration snapshot. Photograph the router admin page and export settings if supported.
- Suspend internet connectivity for affected VLANs if possible while preserving logs and device state.
- Interrupt token reuse
- Force re-authentication across Microsoft 365 by performing a password and token revocation sweep for high-risk accounts. Use Azure AD PowerShell or the Microsoft 365 admin center to revoke refresh tokens and sign-out sessions for impacted users.
PowerShell example to revoke refresh tokens for a user:
# Connect with Global Admin account
Connect-AzureAD
# Revoke refresh tokens for user
Revoke-AzureADUserAllRefreshToken -ObjectId <UserObjectId>
If PowerShell access is not available, require immediate password resets and disable legacy auth until tokens are re-evaluated.
- Stop DNS poisoning at the network edge
- Change the router DNS settings to known good resolvers and apply a strong admin password. Record old values as evidence.
- If router firmware is suspect or unknown changes persist after a reboot, take the router offline and replace with a known-good unit.
- Contain affected accounts and devices
- Disable access for the most sensitive accounts until you confirm they are clean.
- Isolate infected endpoints to a remediation VLAN and collect memory images if you suspect active token exfiltration.
Time targets:
- Detect and snapshot router config: 0-15 minutes.
- Revoke tokens for priority accounts: 15-45 minutes.
- Change DNS and isolate router: 30-90 minutes.
These actions typically reduce active token replay risk by 80-95% within 90 minutes when executed correctly.
Remediation - 24 to 72 hours
Remediation fixes the root cause, restores trusted resolution, and reduces risk of recurrence.
- Replace or rebuild compromised router
- Do not trust a router that showed signs of tampering. Rebuild to factory defaults and update firmware, or replace with a supported business-grade device that supports remote management and monitoring.
- Reconfigure DNS and harden access
- Configure DNS servers to your managed resolvers or trusted public resolvers and lock changes behind management controls.
- Enable DNS over TLS or DNS over HTTPS where supported on upstream resolvers to prevent in-path interception.
- Turn off remote admin or limit it to management VLANs and trusted IPs.
- Identity hardening and token lifecycle controls
- Enforce conditional access policies that require compliant devices and MFA for all Microsoft 365 sign-ins. This makes stolen tokens alone insufficient.
- Reduce refresh token lifetimes where feasible and enable continuous access evaluation to invalidate tokens quickly when risk is detected.
- Audit and restore
- Audit mailbox rules, forwarding, and data exfiltration artifacts. Restore affected accounts with known-good credentials.
- Run a forensic review of logs - router logs, DNS logs, firewall logs, and Microsoft 365 sign-in and audit logs.
Example operational SLA outcomes after remediation:
- Token replay risk reduced to near zero within 48-72 hours.
- Systems restored on average in 24-72 hours for small sites when vendor and IT resources are available.
Operational hardening checklist
This checklist prevents future router DNS hijacks and reduces impact if one occurs.
Network and device controls
- Use business-grade routers with management logging and firmware update capabilities.
- Enforce strong unique admin passwords and 2FA for network management interfaces.
- Disable UPnP on routers and block outbound management protocols from workstation VLANs.
- Monitor device configuration changes with an automated management system.
DNS and resolution
- Use DNSSEC validation and trusted recursive resolvers where possible.
- Where you control resolvers, deploy query logging and alert for unexpected authoritative servers.
Identity and application
- Require MFA for all Microsoft 365 users and block legacy auth protocols.
- Implement Conditional Access to tie session lifetime to device compliance.
- Configure Microsoft 365 to alert on anomalous mailbox behaviors and set automated quarantines for suspicious forwarding.
Policy and process
- Maintain a documented incident playbook for DNS hijack events with runbooks for nursing home staff and remote vendors.
- Run quarterly tabletop exercises that include a DNS hijack + token theft scenario.
Command and evidence examples
These are concrete commands and queries you can run during detection and containment. Run from a trusted admin device.
Check resolver answers from local resolver and trusted resolver:
# Query local resolver
nslookup login.microsoftonline.com
# Query Cloudflare
nslookup login.microsoftonline.com 1.1.1.1
Flush Windows DNS cache to ensure you get fresh resolution after changes:
ipconfig /flushdns
Check current DNS settings on a router CLI (example for OpenWrt/BusyBox):
# show DNS servers
uci show network | grep dns
# or check /etc/resolv.conf
cat /etc/resolv.conf
Pull Azure AD sign-in logs sample (requires AuditLogs.Read.All):
# Connect to MS Graph with admin consent
Connect-MgGraph -Scopes AuditLog.Read.All
Get-MgAuditLogSignIn -Filter "createdDateTime ge 2023-01-01" | Where-Object { $_.userDisplayName -like '*smith*' }
Preserve router config (example pseudo-steps):
- Log in to router admin console. Export configuration file. Save the file to an evidence folder. Photograph the DNS settings and firmware version.
Realistic attack scenarios and outcomes
Scenario 1 - Opportunistic home router compromise
- Attack vector: attacker uses default admin password to change DNS.
- Impact: several staff authenticate to Microsoft 365; attacker captures refresh tokens and sets automated forwarding rules.
- Outcome with playbook: tokens revoked within 45 minutes. Mailbox forwarding disabled and logs show no outbound PHI. Time to containment 90 minutes. Forensics shows attacker accessed email but not EHR. Regulatory exposure limited by rapid detection.
Scenario 2 - Targeted campaign against EHR exports
- Attack vector: attacker uses compromised contractor VPN credentials to change DNS and intercept OAuth flow when an export runs.
- Impact: high-sensitivity records exfiltrated. Attacker uses refresh tokens to access backups for 48 hours.
- Outcome with playbook: full token lifecycle audit and broad revocation. Recovery time 48-72 hours. Forensic costs and reporting increase but credential and device restrictions implemented to reduce recurrence.
Quantified benefit example
- Median time to stop token misuse without playbook: 3-7 days.
- Median time with playbook and basic vendor support: 24-72 hours.
- Expected reduction in attacker dwell time: 60-90%.
Objection handling and trade-offs
We expect these common pushbacks and provide direct answers.
Objection: “Replacing our router is expensive and disruptive.” Answer: Prioritize replacing only the compromised or unmanaged units. A temporary business-grade replacement can be deployed in under 2 hours. The cost of replacement is typically modest compared to breach response and regulatory fines.
Objection: “We already have MFA. Why worry about DNS?” Answer: MFA reduces risk but is not a full stop. If attackers capture refresh tokens during an authorization flow or use federation abuse, they can sometimes obtain session continuity. Combining DNS protections, conditional access, and token revocation gives layered defense.
Objection: “We do not have in-house security staff.” Answer: This is common in the nursing home sector. Use an MSSP or MDR to run continuous monitoring for DNS anomalies and to own incident response. See managed options: https://cyberreplay.com/managed-security-service-provider/.
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. If you are not ready to book time yet, try these quick options:
- Self-assess with our lightweight network scorecard: Run the scorecard
- If you need immediate prioritized help, open a support request: CyberReplay emergency help
- Learn how we operationalize fixes and monitoring: Managed security options
These links provide two low-friction next steps: a short planning call and a low-effort scorecard you can run before committing to a full engagement.
Next step - assessment and response options
If you suspect a DNS hijack now:
- Immediate action: follow the containment checklist above and engage incident response support. If you need urgent help, start at CyberReplay emergency help for prioritized response.
- Quick self-assessment: run the network scorecard and get a prioritized list of unmanaged routers and risky token lifetimes: Scorecard.
- Request a focused assessment: a 2-4 hour network and identity triage that validates router configuration, forces token revocation for high-risk accounts, and issues a prioritized remediation list. Book a short planning call: Schedule assessment.
Vendor selection criteria for MSSP/MDR support
- Demonstrable experience responding to DNS hijacks and OAuth token incidents.
- Ability to revoke and reissue tokens at scale and to validate mailbox integrity.
- Forensics capability to preserve evidence for regulators and insurers.
Recommended near-term SLA
- Detection and containment capability: 1-3 hours.
- Remediation and verification: 24-72 hours.
- Ongoing monitoring and policy enforcement: continuous with weekly reporting.
References
Authoritative source pages and guidance used to build this playbook:
- Microsoft: OAuth 2.0 Authorization Code Grant Flow (Refresh Tokens, Risks)
- Microsoft: Revoke User Access and Refresh Tokens in Azure AD
- Microsoft: Continuous Access Evaluation (CAE) overview
- CISA: Protecting Small Business Routers from Cyber Threats
- NIST SP 800-61r2: Computer Security Incident Handling Guide
- Cloudflare: How DNS Hijacking Works
- Cisco: DNS Hijacking Attacks Explained and Best Practices
- Quad9: Secure DNS and Verified Resolver guidance
- CISA Alert TA18-106A: Russian State-Sponsored Router Exploits
- KrebsOnSecurity: Wave of Router Attacks Changes DNS Settings
These links are source pages that provide operational detail on OAuth risks, token revocation, router hardening guidance, and DNS attack methods used by adversaries.
What should we do next?
If you run a nursing home IT shop with limited staff, get an immediate neighbor-level assessment of network edge devices and Microsoft 365 token settings. The right short-term next step is a focused 2-4 hour network and identity triage that validates router configuration, forces token revocation for high-risk accounts, and issues a prioritized remediation list. Ask any MSSP or consultant you engage to demonstrate this capability on your network before contracting.
If you prefer self-service, run the detection checklist and, if you find signs of compromise, follow the containment checklist now and then engage professional response. See managed options here: https://cyberreplay.com/managed-security-service-provider/.
How quickly can this be detected?
With targeted checks described above, you can identify suspicious DNS configuration or anomalous resolution within 15-30 minutes. Detecting token theft requires correlating sign-in logs, DNS anomalies, and mailbox changes - that usually takes 1-4 hours for a competent operator. Continuous monitoring from an MDR can reduce detection time to under 1 hour.
Can Microsoft block stolen tokens?
Microsoft provides controls that reduce token lifetimes and supports token revocation and continuous access evaluation. These reduce the window an attacker can use stolen tokens, but they do not prevent initial token capture if DNS is hijacked during a legitimate authorization flow. Combining network-level protections and identity controls is required for defense in depth. See Microsoft token docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/refresh-tokens.
Will changing router passwords stop the attack?
Changing the password is a necessary immediate step but may not be sufficient. If firmware is backdoored or the router settings persist after reboot, rebuild or replace the device. Always snapshot evidence before making configuration changes and verify that DNS settings persist only when you have applied trusted values.
Conclusion
Router DNS hijacks are a low-cost, high-impact attack that can lead to Microsoft 365 token theft and data exposure. For nursing homes, the business cost is high - regulatory risk, operational disruption, and care delays. The practical path is fast detection, aggressive containment targeting token revocation, and remediation that replaces or reconfigures compromised infrastructure and hardens identity controls. Taken together, these measures cut risk quickly and provide durable protection when combined with an MSSP or MDR for continuous monitoring.
Final next step recommendation
If you do not have a dedicated security team, engage an external responder to run an emergency triage and follow the containment checklist in this guide. For managed long-term protection, evaluate a provider that offers 24-7 detection, token lifecycle management, and incident response support. If you want immediate help now, begin at https://cyberreplay.com/help-ive-been-hacked/ or review managed options at https://cyberreplay.com/managed-security-service-provider/.
When this matters
This playbook matters when your organization uses cloud identity flows for critical systems and the network edge is managed with consumer or small-business routers. Typical triggers:
- Recent staff reports of unusual login redirects or certificate warnings when signing in to Microsoft 365.
- Detection of unexpected recursive DNS servers configured on routers or DHCP options pointing to unknown IPs.
- Sudden appearance of mailbox forwarding rules, unexplained data exports, or anomalous sign-in locations in Azure AD logs.
If any of the above are present, treat the situation as high priority and start containment immediately.
Definitions
- DNS hijack: unauthorized change of DNS server settings or responses that redirects legitimate traffic to attacker-controlled resolvers.
- Resolver: the DNS service that resolves domain names into IP addresses for clients.
- OAuth refresh token: a long-lived token used to obtain new access tokens without interactive sign-in. If stolen, it can allow session replay.
- Access token: short-lived credential used to access resources. Often used with refresh tokens in OAuth flows.
- Conditional Access: Azure AD policies that require conditions must be met for sign-in, such as MFA or compliant devices.
- Continuous access evaluation: near real-time token invalidation mechanism that reduces token reuse after risk is detected.
Common mistakes
- Assuming a password change alone is sufficient. If router firmware or persistent backdoors exist, configuration changes can be re-applied.
- Failing to snapshot evidence before remediation. Capturing router settings, logs, and exported config files preserves investigation value.
- Relying on a single control. DNS protections, token lifecycle controls, and identity policies work best together.
- Not checking DHCP options. Attackers can change DHCP-supplied DNS server addresses so some endpoints keep using malicious resolvers.
- Forgetting to audit mailbox rules and forwarding after token revocation. Persistence mechanisms sometimes remain at the mailbox level.
FAQ
Q: How can I confirm tokens were stolen? A: Correlate DNS anomalies with Azure AD sign-in logs, refresh token issuance events, and sudden mailbox forwarding or data exports. Look for sign-ins from unfamiliar IP addresses shortly after anomalous resolution.
Q: Can Microsoft block stolen tokens? A: Microsoft provides token revocation and continuous access evaluation to reduce token reuse. These reduce the window of risk but do not prevent the initial capture during a hijacked DNS flow. See: https://learn.microsoft.com/en-us/azure/active-directory/continuous-access-evaluation-overview
Q: Will changing router passwords stop the attack? A: Changing the router admin password is an essential immediate step but may not be sufficient if firmware is compromised or changes persist. Always snapshot evidence, reboot to confirm persistence, and replace or rebuild devices that show tampering.
Q: What immediate actions should non-technical staff take? A: Isolate affected endpoints when instructed, preserve any screenshots or unusual pages seen during sign-ins, and escalate to the IT lead or your incident response contact.
Q: Who should I call for help? A: Start with your MSSP or incident response provider. If you do not have one, use the CyberReplay emergency help link: https://cyberreplay.com/help-ive-been-hacked/ or run the quick scorecard: https://cyberreplay.com/scorecard