DNS Hijacking Incident Response Guide for Rural Critical Access Hospitals

How can a rural critical access hospital identify DNS hijacking?

Suspect DNS hijacking when a hospital domain unexpectedly directs staff, patients, or partner organizations to the wrong destination, or when email and web services behave differently depending on the network or DNS resolver used. Possible signs include a changed hospital website, failed or misdirected email, unexpected login pages, or reports that a familiar service presents a new certificate. These signs warrant investigation, but do not by themselves prove a hijacking.

Compare what the hospital’s domains resolve to against a trusted inventory or previously verified records. Check the answers from the authoritative DNS servers as well as from more than one independent recursive resolver. Look for unexpected changes to DNS A record integrity, MX records, or NS record delegation, and review registrar and DNS-provider audit logs for unfamiliar logins, recovery changes, or record edits. CISA advises treating unexplained record discrepancies as potential security incidents and reviewing records across the registrar and authoritative DNS services.

Coordinate IT, clinical leadership, and incident response staff early. Determine whether the issue affects only a public-facing website or also services needed for patient care, such as email, remote access, patient portals, cloud-hosted systems, or vendor connections. A DNS change can redirect traffic, but it does not establish by itself that anyone accessed electronic protected health information (ePHI).

Which DNS records and systems should responders inspect?

Start with a complete inventory of the hospital’s domains, subdomains, registrars, DNS hosting providers, authoritative and secondary name servers, and the staff or vendors who administer them. Include domains managed on the hospital’s behalf, such as those used by a medical group, patient portal, email provider, billing service, or other business associate. CISA notes that fragmented ownership can make it difficult to see all domains and associated records.

Compare current settings with a known-good baseline, approved change records, or a trusted configuration backup. Review:

• NS records and registrar delegation: Confirm that the registrar points to the hospital’s intended authoritative name servers, and check for unauthorized name-server or domain-transfer changes.
• A, AAAA, and CNAME records: Check that web, portal, remote-access, and other service names resolve to intended destinations.
• MX and related email records: Investigate MX record tampering and review TXT records used for SPF, DKIM, and DMARC, since email routing and authentication settings can affect the security and delivery of hospital communications.
• DNSSEC settings: Check DNSSEC validation, signing keys, and DS records at the registrar or parent zone. DNSSEC can help validating resolvers authenticate DNS data, but it does not prove that an approved administrator made a change or that a validly signed record reflects the hospital’s intended configuration. See the IETF DNSSEC Best Current Practice.
• Accounts and administrative pathways: Inspect the DNS registrar account, DNS provider console, identity-provider accounts, recovery email and phone settings, API keys, delegated users, and any systems that can publish DNS changes.
• Certificates and historical data: Review certificate transparency monitoring for unexpected certificates issued to hospital domains, and use passive DNS or provider history to identify when records changed.

Preserve relevant registrar, DNS-provider, identity, email, firewall, and web-service logs before they expire. CISA recommends reviewing public records, changing passwords for accounts that can modify DNS, enabling multifactor authentication, and monitoring certificate transparency logs for unauthorized certificates in its DNS Infrastructure Tampering guidance.

How should the hospital contain an active DNS hijacking incident?

Activate the hospital’s incident response process and assign a lead who can coordinate IT, clinical operations, privacy, legal, communications, and affected vendors. Prioritize patient safety and continuity of essential services while containing the incident. Avoid making broad network or system changes without assessing whether they could disrupt clinical care.

From a trusted device and network, contact the registrar and DNS provider using verified contact information—not a phone number or link from a suspicious message. Ask the provider to help secure the DNS registrar account compromise, stop unauthorized transfers or edits, preserve account and change logs, and restore control to verified administrators. Change passwords for every account and service that can change DNS, including registrar, DNS hosting, identity, and relevant email accounts. Revoke suspicious sessions, tokens, and API keys, and enable multifactor authentication where available.

After preserving the evidence needed to investigate, correct unauthorized records with the provider and review the changes across all authoritative and secondary servers. If the hospital uses DNSSEC, coordinate any repair of signing keys, DS records, or validation problems with the DNS provider; do not disable DNSSEC or change keys hastily, since a configuration error can make legitimate services unreachable. Coordinate with network and service providers about cache behavior and safe ways to reduce continued exposure. CISA recommends changing DNS account passwords, applying MFA, and reviewing records across registrars and DNS servers.

If there is evidence that redirected traffic reached an attacker-controlled destination, treat it as a potential exposure—not as automatic proof that PHI was viewed. Preserve evidence, identify the affected services and time window, and investigate which data may have been transmitted. CISA warns that DNS tampering can redirect web and email traffic and that an attacker may obtain valid certificates for a domain, so a browser certificate warning may not occur.

How can the hospital recover DNS accounts and restore trusted services?

First secure the accounts and recovery channels that control the domain: verify ownership and authorized administrators, remove unfamiliar users and recovery methods, rotate credentials and API keys, revoke unauthorized sessions, and confirm MFA is enabled. Review the identity-provider and email accounts used for registrar recovery as well; changing DNS alone may not remove an attacker’s access to those accounts.

Restore records from a verified baseline and confirm that the registrar’s delegation, authoritative DNS, and secondary servers agree with the intended configuration. Test critical domains from internal and external networks, using more than one trusted resolver. If DNSSEC is enabled, have qualified DNS staff or the provider verify signing and validation through the chain of trust before considering recovery complete. RFC 9364 describes DNSSEC as providing origin authentication for DNS data; it does not replace securing the accounts and processes that authorize DNS changes.

Review certificate transparency monitoring for certificates issued during the incident that the hospital did not authorize. If an unauthorized certificate is found, coordinate investigation and revocation or replacement with the issuing certificate authority and affected service providers. Continue monitoring DNS changes, registrar access, and certificate issuance after services return; an attacker may retain access to compromised accounts or credentials even after the visible redirection stops.

Restore services in an order set by clinical and operational criticality. Verify that staff can reach and authenticate to essential systems, that email routes correctly, and that vendor connections and patient-facing services behave as expected. The HHS cybersecurity guidance on incident recovery recommends integrity checks and careful restoration as part of returning systems to normal operations.

What downtime procedures protect scheduled care during recovery?

Use the hospital’s emergency mode operations plan to keep essential care running while affected digital services are unavailable or being verified. Clinical leadership should assess the incident’s actual impact and decide whether to continue, reschedule, or divert scheduled services. DNS hijacking does not necessarily mean that clinical systems are unavailable, so base operational decisions on verified service status and patient-safety needs.

Identify essential functions and communicate their approved downtime workflows to staff. Depending on the hospital’s plan, these may include paper-based patient registration and clinical documentation, manual order and medication processes, and telephone or other verified communication channels for labs, imaging, pharmacies, referral partners, emergency services, and vendors. Use known-good contact information and avoid links or phone numbers received through potentially affected email or websites.

Protect any paper records and temporary electronic files containing PHI, limit access to staff who need it, and reconcile downtime documentation into the appropriate systems after recovery. Keep a record of care decisions and the time services were unavailable so teams can follow up on delayed appointments, results, referrals, and orders.

The HIPAA Security Rule’s contingency-planning standard includes data backup, disaster recovery, and emergency mode operations procedures. HHS explains that emergency mode procedures should enable the continuation of critical business processes while protecting ePHI. See the HHS Security Rule Administrative Safeguards guidance.

How should the hospital document the incident and assess HIPAA breach obligations?

Maintain a contemporaneous incident record. Document when and how the issue was discovered; domains, records, accounts, systems, and services affected; the incident timeline; relevant logs and forensic evidence; decisions and actions taken; vendors and authorities contacted; and recovery and validation results. Record what is known, what remains uncertain, and how the investigation’s conclusions were reached. HHS OCR describes incident documentation as including discovery, affected systems and data, mitigation, recovery outcomes, root-cause analysis, and forensic information in its security incident response guidance.

A DNS hijacking event is a security incident to investigate, but it is not automatically a reportable HIPAA breach. The hospital must assess whether there was an impermissible use or disclosure of PHI and whether the information was unsecured. Under the Breach Notification Rule, an impermissible use or disclosure is generally presumed to be a breach unless the hospital demonstrates a low probability that the PHI was compromised through a risk assessment considering the PHI’s nature and extent, who received or used it, whether it was actually acquired or viewed, and how much risk was mitigated. See the HHS Breach Notification Rule guidance.

Assess whether PHI was sent through a redirected portal, email service, or other affected destination, and consider the data involved, the attacker or recipient, evidence of access or acquisition, and mitigation. If an impermissible use or disclosure of unsecured PHI may have occurred, involve the privacy officer and legal counsel promptly. Do not wait for the technical investigation to be complete before recognizing that the breach-notification clock may have started; HHS explains that discovery is tied to when the incident is first known, not when the investigation is finished.

For a breach of unsecured PHI, individual notices are due without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more individuals must also be reported to HHS without unreasonable delay and within 60 days; breaches affecting fewer than 500 may be reported to HHS annually, no later than 60 days after the end of the calendar year in which they were discovered. Media notice is required when a breach affects more than 500 residents of a state or jurisdiction. Document the assessment and any decision not to notify, as well as notices made, and check applicable state law and contractual obligations with counsel.

Conclusion

Respond to suspected DNS hijacking by prioritizing patient safety, securing registrar and DNS accounts, comparing records with a trusted baseline, and restoring services in a verified order. Preserve evidence, keep downtime procedures ready, and assess any possible PHI disclosure under HIPAA’s breach rules rather than assuming either that exposure occurred or that DNS restoration ends the investigation.

FAQs.

What should a rural critical access hospital do first after suspected DNS hijacking?

Protect patient care and activate the incident response process. Assign an incident lead, verify which clinical and communication services are affected, and contact the registrar and DNS provider using trusted contact details. Preserve relevant logs and evidence while securing the accounts that can change DNS.

How can responders confirm whether DNS records were maliciously changed?

Compare current records and registrar delegation with a trusted baseline, approved change records, and provider audit logs. Check authoritative and secondary DNS servers, registrar account activity, and independent resolver results. Unexpected changes should be investigated; a mismatch alone does not establish who made the change or whether PHI was accessed.

Can attackers retain access after DNS redirection ends?

Yes. An attacker may still control a compromised registrar, DNS-provider, identity, or email account, or retain a session, token, API key, or recovery method. Secure those accounts, revoke suspicious access, review audit logs, and monitor DNS changes and certificate transparency after restoring the intended records.

When must a hospital assess whether unsecured PHI was breached?

As soon as the hospital discovers a suspected incident that may involve an impermissible use or disclosure of unsecured PHI. The hospital should investigate and document its assessment promptly; the discovery date is not postponed until the technical investigation is complete. If a breach is established, the hospital must meet the applicable notice deadlines, including the individual and HHS reporting rules described in the HHS Breach Notification Rule guidance.