In May 2026, the largest public health system in the United States confirmed what it had quietly disclosed in March: attackers sat inside its network for roughly eleven weeks and walked out with the personal and health data of about 1.8 million current and former patients and employees. The compromised data was not trivial. It included names, medical record numbers, diagnoses, medications, test results, insurance and billing details, biometric data such as fingerprints and palm prints, Social Security numbers, government ID numbers, and even financial account credentials.
The technical entry point is the part most security teams should pay attention to. Investigators believe the attackers did not break down the front door at all. Initial access appears to have been gained through a breach at one of the organisation’s third-party vendors — and from there, they moved into the hospital network and stayed there from late November until mid-February before anyone noticed.
This is not an unusual story anymore. It is the standard shape of a modern intrusion: quiet entry, a long dwell time, and slow, deliberate data theft. The question worth asking is not “how did they get in” but “why did nobody see eleven weeks of activity.” A large part of the answer lives at a layer most organisations barely monitor — DNS.
Why DNS Sits at the Centre of a Breach Like This
Almost every stage of an intrusion touches DNS, the system that turns names like example.com into IP addresses. It is the quiet plumbing under every connection, and attackers rely on it just as much as legitimate traffic does.
Consider the typical lifecycle of an attack like the one NYC Health + Hospitals experienced:
- Initial foothold. A compromised vendor account or a phishing payload reaches into the network. The malware that lands almost always needs to “phone home” to a command-and-control (C2) server. To find that server, it makes a DNS query.
- Establishing persistence. Once inside, the implant checks in regularly with its operators. Each check-in is a DNS lookup to attacker-controlled infrastructure, often using domains registered only days earlier.
- Lateral movement and staging. As attackers explore the network and stage data for theft, tooling frequently resolves external domains for additional payloads, scripts, or tunnelling endpoints.
- Exfiltration. When it is time to steal the data, attackers increasingly use DNS itself as the smuggling route — encoding stolen records into DNS queries that slip past firewalls configured to allow port 53 traffic by default.
Each of those steps is a DNS event. Each one is an opportunity to detect — or to block — the attack before 1.8 million records leave the building.
The Vendor Problem Is a DNS Problem Too
The detail that should keep healthcare CISOs awake is that the suspected entry point was a third-party vendor, not the hospital’s own systems. You can harden your own perimeter to perfection and still be breached through a supplier you authenticated and trusted.
Traditional perimeter defences struggle here because the malicious traffic often originates from a connection or credential the network already trusts. But the destinations that traffic reaches out to are a different matter. A newly registered C2 domain, a known malware distribution host, or a suspicious DNS-over-HTTPS resolver being used to bypass corporate controls — these are external indicators that do not care whose credentials were stolen. They are visible at the DNS layer regardless of how the attacker got in.
This is why DNS filtering is one of the few controls that meaningfully shrinks the blast radius of a supply-chain compromise. It does not assume the connection is hostile. It evaluates where the connection is trying to go.
What DNS Filtering Actually Does in This Scenario
A DNS filtering layer like DNSCircle sits in the resolution path for every device on the network — endpoints, servers, and increasingly the remote and roaming machines that never touch the office network at all. Before a connection is ever established, the destination domain is checked against threat intelligence and policy. Here is how that changes the four stages above:
- It breaks C2 callbacks. If malware cannot resolve its command-and-control domain, it cannot receive instructions. The implant is effectively deaf, and the dwell time that let attackers operate undetected for eleven weeks collapses into a failed connection logged on day one.
- It catches newly registered and low-reputation domains. Attackers cycle through fresh domains constantly. A filtering service that scores domain age and reputation can block a brand-new C2 endpoint that no signature-based tool has ever seen.
- It blunts DNS-based exfiltration. By inspecting query patterns — unusually long subdomains, high query volumes to a single domain, abnormal record types — DNS filtering can flag and stop data being tunnelled out through port 53.
- It produces the visibility that was missing. Even when filtering does not block something outright, every query becomes a logged, searchable event. The eleven-week blind spot becomes a timeline. Security teams can ask “what did this endpoint try to resolve” and get an answer.
Detection Is the Real Lesson
NYC Health + Hospitals said it has since strengthened its defences — enhanced detection rules, password resets, additional protective technologies, and tighter remote access policies. Those are sensible steps. But notice that almost all of them are about seeing the attack sooner. The damage in this incident was not done in the first hour. It was done over eleven weeks of undetected presence.
DNS filtering is one of the lowest-effort, highest-leverage ways to compress that detection window. It requires no agent rollout on every machine, it works for roaming and remote users, and it operates at a layer the attacker cannot avoid — because malware that cannot resolve a domain cannot do its job.
A Practical Checklist for Healthcare and Regulated Organisations
If this breach prompts a review of your own posture, these are the DNS-layer questions worth answering:
- Are all devices forced through a controlled, filtered resolver — including laptops that leave the network and unmanaged vendor devices that connect in?
- Can you detect and block the use of rogue DNS-over-HTTPS resolvers that staff or malware use to evade your filtering?
- Are newly registered domains and low-reputation destinations blocked by default, rather than only known-bad domains?
- Are DNS query logs retained long enough to investigate a months-long dwell time after the fact?
- Do you have policy controls that extend to your third parties and contractors, given that supply-chain access was the suspected entry point here?
The Takeaway
The NYC Health + Hospitals breach is a textbook case of the modern threat model: trusted vendor access, a long quiet dwell time, and large-scale exfiltration that nobody caught for weeks. No single control would have stopped all of it. But DNS filtering addresses the precise weaknesses this incident exposed — it cuts off command-and-control, it limits what a compromised vendor connection can reach, it disrupts data smuggling over DNS, and above all it turns a blind spot into a logged, searchable record.
You cannot always stop an attacker from getting a foot in the door. You can make sure that, the moment they try to call home, you are listening — and that the call doesn’t connect.
DNSCircle provides cloud-delivered DNS filtering and threat protection for organisations that need visibility and control at the network’s most fundamental layer. Learn how DNSCircle protects your network →