Your Router Might Be Lying to You:
The Quiet Rise of DNS Hijacking

Over the last six months, I've been seeing more and more DNS hijack infections on routers, switches, and servers. It's a genuinely clever tactic, and it's worth understanding why: the attacker only needs to briefly gain access and very lightly maintain it. Once they've rerouted your DNS to a server they control, they can quietly sit in the middle of your traffic and analyze your traffic packets, harvest credentials, the works.

This isn't theoretical, and it isn't rare.

My own server and three customer servers have been hit by this class of attack in the last 3 months. I'm writing this to bring some attention to what's going on, explain how these attacks actually work, and (most importantly) show you how to defend your equipment and check whether it's already been hit, without needing to be a network engineer.

What DNS Hijacking Actually Is.

DNS is the phone book of the internet. When you type yourbank.com, your device asks a DNS resolver "what's the IP address for this?" and trusts whatever answer comes back. That trust is the whole game.

DNS hijacking means an attacker has inserted themselves into that lookup process. Usually by changing which resolver your equipment asks. They don't need to break encryption or crack passwords on the sites you visit. They just need to control the answer to "where is this domain?" If they can tell your computer that yourbank.com lives at their server instead of the real one, everything downstream is compromised.

What makes it so effective is how little the attacker has to do. Get into the router once, change two settings, and leave. The compromise persists because the malicious configuration just sits there, looking like normal router settings, often surviving for months because nobody thinks to check.

How Do These Attacks Get Deployed?

The pattern I keep seeing (and the one security researchers have documented at scale) looks like this:

1. Initial access to the edge device. Attackers get into a router, switch, or server through one of a few well-worn doors: known firmware vulnerabilities (CVEs) on unpatched devices, default or weak admin credentials, or management interfaces that are exposed to the internet when they shouldn't be. Small office and home office routers are favorite targets because they're rarely patched and almost never monitored. Legacy and end-of-life gear is especially bad; if the vendor isn't shipping fixes anymore, a known hole stays open forever.

2. Modify the DNS and DHCP settings. Once they have administrative access, the attacker changes the device's DNS servers to point at infrastructure they control that is typically a rented virtual private server set up to act as a malicious resolver. On a router, they'll often change the DHCP settings too, so every device on the network gets handed the rogue DNS server automatically. Phones, laptops, IoT gear, servers; anything that pulls its network config from that router. Sometimes both the primary and secondary DNS entries get set to malicious addresses.

3. Selectively redirect and intercept. With your DNS flowing through their resolver, the attacker can return honest answers for most domains (keeping things looking normal) and lie only for the targets they care about. When you request one of those targeted domains, you get sent to an adversary-in-the-middle node. There, they harvest passwords, session cookies, OAuth and authentication tokens, email contents, and browsing data. No user interaction required, and nearly invisible from the victim's side.

This is exactly the technique behind the large-scale campaign that Microsoft, Lumen's Black Lotus Labs, and the UK's NCSC documented in early 2026. A Russian state-linked actors exploiting vulnerable TP-Link and MikroTik routers, repointing their DNS, and using that foothold for traffic interception against organizations worldwide. The campaign reportedly ran from around August 2025 until its infrastructure was disrupted in April 2026. Government agencies were the headline targets, but the same playbook works against any business or individual, and the 5,000-plus consumer devices caught up in it show nobody is too small to be collateral.

That timeline should bother you. These attacks ran for the better part of a year before being shut down. The "lightly maintained" part is not an exaggeration.

Does HTTPS and/or Encrypted DNS Help?

Short answer: it helps with some things, and not at all with others. It's worth being precise here, because "just turn on encrypted DNS" gets repeated as a fix when it's really only a partial one.

What DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) actually do. Both encrypt the DNS conversation between your device (or router) and the resolver. Standard DNS runs in plaintext over port 53, which means anyone on the path (someone on the same café Wi-Fi, a malicious local network, in some cases your ISP) can read your lookups and, worse, silently rewrite the answers. DoH and DoT close that specific door. An on-path attacker can no longer quietly tamper with your DNS responses in transit.

There's also a real, concrete benefit against the router-hijack scenario specifically: if you configure DoH explicitly in your browser or operating system, pointed at a resolver you chose and trust, it overrides whatever DNS the router handed out over DHCP. So even if the router is compromised and trying to push a rogue resolver, your browser ignores it and goes straight to the good one. That's genuinely useful.

Where it falls short. Here's the part that matters:

Encryption authenticates the channel, not the honesty of the resolver. If the attacker has maneuvered you into using their resolver, DoH just gives you a beautifully encrypted pipe straight to the attacker. Garbage in, garbage out; now with TLS.
A compromised router can downgrade or block it. The attacker controls the edge device. They can block DoT's dedicated port (853), block known DoH endpoints, and let devices silently fall back to plaintext port 53. Many devices fail open like this.
Most of your devices don't use it. Browser DoH covers your browser. It does nothing for the smart TV, the cameras, the thermostat, the printer, or that old server quietly running resolv.conf against port 53. Budget IoT gear overwhelmingly doesn't support encrypted DNS at all, and it'll happily trust the rogue DHCP-assigned resolver.
It doesn't fix the actual problem. The router or server is still compromised. An attacker who owns your edge device has other tools as they can redirect by IP, mess with routing, and more. Encrypted DNS doesn't evict them.

So: encrypted DNS is a worthwhile layer, and browser/OS-level DoH to a trusted resolver is a real mitigation against rogue DHCP-assigned DNS. But it narrows the attack surface; it doesn't close it. The fix is securing and verifying the edge device itself.

How to Actually Defend Against This Type of Attack.

Checking is detection. The better position is not getting hit in the first place. None of this is exotic. It's the same edge-device hygiene that closes most of the doors attackers use, and it's worth doing now rather than after.

Patch firmware, and mean it. The single biggest vector here is known vulnerabilities on devices nobody updated. Turn on automatic firmware updates if your gear supports it; if it doesn't, put a recurring reminder on the calendar to check manually. And retire end-of-life equipment as once the vendor stops shipping security fixes, every known hole in that device stays open permanently. A cheap new router beats a "still works fine" router with an unpatchable remote-code-execution bug.

Close the remote management door. Administrative interfaces should never be reachable from the internet unless you have a deliberate, locked-down reason. Disable WAN-side administration, remote management, and any cloud-management features you don't actually use. An admin panel exposed to the internet is the front door for a huge share of these compromises.

Kill default and weak credentials. Change the default admin username and password on every router, switch, and managed device the day it goes into service; long, unique, and stored in a password manager. Default credentials are still one of the most reliable ways in.

Set your DNS deliberately and LOCK it. Don't leave DNS on "automatic" and forget it. Manually configure trusted resolvers (Quad9, Cloudflare, or your ISP) on the router. If your router supports DoH or DoT at the router level, turn it on. That will give every device on the network encrypted DNS to a resolver you chose, including the IoT gear that can't do it itself. A filtering resolver like Quad9 adds another layer, since it blocks known-malicious domains outright.

Turn off services you don't use. UPnP, Telnet, unused open ports, legacy remote-access protocols; each one is attack surface. If you're not using it, disable it.

Segment your network. Put untrusted and IoT devices on their own VLAN or guest network, separate from the computers and servers that matter. Cheap IoT gear is the device most likely to get popped and the least likely to ever be patched. Don't let a compromised camera sit on the same flat network as everything else. Segmentation limits how far an attacker can pivot if they do get a foothold.

Make checking a habit, not a one-off. Everything in the next section is worth doing on a schedule, not just once. For a business, that means keeping an inventory of every edge device you own (you can't defend or audit what you don't know is there) and reviewing DNS and firmware on a recurring basis. If your equipment can alert on configuration changes, turn that on; it converts "I happened to check" into "I get told."

How to Check Your Own Systems:

This is the part I want everyone to walk away with. You can verify this stuff yourself, and it doesn't take long. The core idea: find out which DNS servers your equipment is actually using, and confirm they're ones you recognize.

1. Check your router's DNS settings. Log into your router's admin interface and look at two places: the WAN/internet DNS settings (what the router itself uses) and the LAN/DHCP DNS settings (what it hands out to your devices). You're looking for DNS server IP addresses you don't recognize. Known-good values are your ISP's resolvers or reputable public ones such as Cloudflare (1.1.1.1), Quad9 (9.9.9.9), Google (8.8.8.8). An unfamiliar IP here is a red flag worth chasing down.

2. Check DNS settings on each computer and server. Servers are worth checking individually, because they can be pointed at a rogue resolver independent of the router.

Windows: ipconfig /all — look at the "DNS Servers" line.
macOS: scutil --dns — check the nameserver entries.
Linux: resolvectl status (or inspect /etc/resolv.conf).

3. Ask who's actually answering. Run nslookup yourbank.com (or any domain) and look at the Server: line in the output; that's the resolver that answered. With dig, compare your default resolver against a known-good one: run dig example.com and then dig @1.1.1.1 example.com and see if the answers match.

4. Cross-check from a second network. This one needs no tools. Resolve a domain on the network you're worried about, then do the same thing on a known-good connection; your phone on cellular data works fine. If a domain resolves to a different IP address on your network than it does on cellular, that's a serious warning sign.

5. Use a resolver-check service. Cloudflare's page at 1.1.1.1/help will show you which resolver you're using and whether encrypted DNS is active. If it reports a resolver or organization you don't recognize, investigate.

6. Don't click through certificate warnings. When an attacker intercepts an HTTPS site this way, your browser usually throws a certificate error. This is because the attacker can't produce a valid certificate for a domain they don't own. These campaigns rely on people clicking "proceed anyway." Treat an unexpected certificate warning on a site that's normally fine as a possible interception, not an annoyance.

7. Check your firmware. Confirm your router and switch firmware are current, and look up whether your specific model has known DNS-related vulnerabilities. If the device is end-of-life and no longer getting security updates, plan to replace it as an unpatchable known hole is a standing invitation.

If You Find Something!!

If your DNS settings have been changed to something you don't recognize: factory-reset the device, update its firmware before putting it back in service, set strong and unique admin credentials, disable any remote/WAN-side management you don't explicitly need, and manually set DNS to a resolver you trust. Then assume that credentials used on that network may have been exposed and rotate the important ones; email, banking, anything tied to your business.

DNS hijacking works because it's quiet, it's cheap for the attacker to maintain, and almost nobody checks. The good news is that last part is also the fix: checking takes ten minutes, and now you know how. If you run a business, do private or security-sensitive work, or just want to be sure, make it a habit.

I have also designed a detection, removal and remediation tool for the JWrapper/Weaponized ScreenConnect "Medusa IAB Variant" computer hijacks and DNS hijacks that I have encountered. Feel free to contribute to the GitHub repo if you have any further details or findings you would like to submit.

Report Anything & Everything You FIND!

Here's the uncomfortable part: DNS hijacking campaigns run for months precisely because they're under-reported. Campaigns like FrostArmada get shut down when enough activity is detected, correlated, and handed to law enforcement; visibility is the whole game, and every documented incident adds to it. Reporting also warns the next person before they get hit.

If you've found a DNS hijack (or you think you have and want a second set of eyes) you can report it through my site, scamorhack.com. In the "Report & Get Help" section there's a reporting form that comes straight to me at Pacific Northwest Computers for investigation and documentation. Send as much detail as you can: the affected device, the rogue DNS addresses you found, when you first noticed it, and whatever led you to it. The more specific you are, the more useful it is.

ScamorHack.com also routes you to the official channels, which are worth filing with regardless:

FBI Internet Crime Complaint Center (IC3): ic3.gov — the right channel for a business or network compromise, and where cyber incidents get aggregated at the federal level.
FTC: reportfraud.ftc.gov — for consumers and small operators reporting scams and fraud.

You don't have to choose. File with IC3 and send us the details too! The more places a real incident is on record, the more good it does!

Created & Maintained by Pacific Northwest Computers

Jon Pienkowski runs Pacific Northwest Computers, providing IT services, networking, and cybersecurity support to SW Washington and the Portland metro area.

Pacific NW Computers
www.linktr.ee/pnwcomputers
www.pacificnwcomputers.com

📞 Pacific Northwest Computers offers Remote & Onsite Support Across:
SW Washington including Vancouver WA, Battle Ground WA, Camas WA, Washougal WA, Longview WA, Kelso WA, and Portland OR

Pacific NorthWest Computers

Thursday, May 14, 2026