APT28 Targeting SOHO Routers: MikroTik & TP-Link DNS Hijacking
Just caught the latest report on APT28 (Forest Blizzard) leveraging insecure MikroTik and TP-Link SOHO routers for a global DNS hijacking campaign. According to the article, this has been active since May 2025, but it looks like they are ramping up the infrastructure build-out.
The modus operandi here is classic but effective: exploiting exposed management interfaces (specifically WinBox on MikroTik) to modify DNS settings. Once compromised, the routers are used as proxy nodes or to facilitate espionage via DNS redirection. Since SOHO gear rarely gets the same TLC as enterprise servers, these make perfect hideouts.
If you manage remote sites or clients, you need to audit your edge devices immediately. First, check if your management interfaces are exposed to the WAN. Second, verify your DNS configurations haven't been tampered with.
For those running MikroTik RouterOS, run the following to check your DNS settings and DHCP options:
routeros /ip dns print /ip dhcp-server network print
Ensure the servers field points to legitimate resolvers (e.g., 1.1.1.1 or your internal DC) and not to suspicious external IPs.
From a blue team perspective, detection is tricky because the traffic passes through a "trusted" gateway. However, you can hunt for devices making DNS requests to non-standard external resolvers directly from your endpoints, bypassing your internal DNS.
DeviceNetworkEvents
| where RemotePort == 53
| where InitiatingProcessFileName !in ("svchost.exe", "dns.exe", "systemd-resolved")
| summarize count() by RemoteIP, DeviceName
| where count_ > 500
Given that APT28 is state-sponsored, they are likely being very selective with the traffic they modify. How is everyone handling the patching cycle for these rogue SOHO devices? Are you pushing for replacement, or just relying on strict firewall rules to block management access?
We've seen a massive spike in MikroTik exploitation in our honeypots over the last few months. It's almost always default credentials or exposed WinBox (port 8291). If you can't replace them, at least use the firewall to drop WAN traffic to the router itself except for specific VPN ports. I use a script like this to harden them automatically:
routeros /ip firewall filter add chain=input src-address-list=allowed_mgmt action=accept add chain=input action=drop
Don't trust the default 'allow from anywhere' config.
Great KQL query. One thing I'd add is to watch for devices resolving domains at weird times or with high entropy in subdomains, which often indicates C2 beacons over DNS. Since the router itself is compromised, internal DNS logs might look clean if the router handles the recursion. You have to inspect the packets leaving the perimeter.
This is exactly why I hate managing remote SOHO gear for clients. The 'set it and forget it' mentality is a liability. We've started replacing all MikroTik/TP-Link gear at client sites with Meraki or similar cloud-managed devices where auto-patching is actually enforced. It costs more, but the risk of a router becoming a zombie for a nation-state actor is too high.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access