APT28's SOHO Router Pivot: Hardening MikroTik & TP-Link Against DNS Hijack
Just caught the latest reports on APT28 (Forest Blizzard) pivoting back to SOHO infrastructure. They are actively compromising MikroTik and TP-Link devices, manipulating DNS settings to facilitate their cyber espionage operations since May 2025.
The campaign turns these insecure routers into malicious proxy nodes, effectively hiding the origin of their traffic. The scariest part is how often these devices are neglected—sitting at the network edge with default credentials or unpatched firmware.
If you manage remote sites, you need to audit your edge immediately. On MikroTik devices, check if the DNS settings have been tampered with by running this in the CLI:
routeros /ip dns print /ip dhcp-server network print
Look for static servers fields in /ip dns or gateway/dns-server fields in DHCP settings that point to external IPs you don't recognize.
For detection internally, we're watching for DNS queries that originate from the router interface itself rather than internal clients, which often indicates the device is being used for resolution. A basic KQL query to spot anomalies in your network traffic:
DeviceNetworkEvents
| where RemotePort == 53
| where InitiatingProcessFileName !in ("chrome.exe", "firefox.exe", "svchost.exe")
| summarize count() by DeviceName, RemoteIP, bin(Timestamp, 5m)
| where count_ > 500
Is anyone else seeing these specific TTPs targeting TP-Link gear in the wild, or is this campaign primarily focused on the MikroTik ecosystem right now?
We saw a spike in MikroTik exploitation attempts last month targeting the Winbox interface. The immediate fix was ensuring firewall rules blocked access to Winbox and the API from the WAN interface. You can do this quickly with a drop rule:
routeros /ip firewall filter add chain=input protocol=tcp dst-port=8291 in-interface=WAN action=drop
Most admins forget these management ports are exposed. Firmware updates are crucial, but disabling remote management is the most effective immediate mitigation.
From a SOC perspective, the hardest part is visibility. Most of these SOHO routers don't forward syslogs by default. We started deploying a Python script on our management server to scrape configurations daily via SSH, just to flag if 'DNS servers' change unexpectedly. It's a bit 'band-aid' but it caught a compromised router at one of our branch offices last week.
Don't sleep on the TP-Link aspect. While MikroTik has the CLI power, TP-Link SOHOs often have hardcoded backdoor credentials in older firmware revs. I run a simple Nmap scan across our subnets monthly to check for open management ports:
nmap -p 80,443,8080 --script http-title 10.0.0.0/24
If you see the default TP-Link admin page title, assume it's vulnerable until patched.
To build on Marcus’s point about older firmware, specifically check for static DNS overrides, as attackers use them for persistence. On MikroTik, run this command to verify no rogue servers are set:
/ip dns print
Ensure allow-remote-requests is disabled; otherwise, the device acts as an open resolver, fueling the proxy activity APT28 relies on.
Excellent thread. To build on Quinn’s firewall rules, we must also disable unnecessary services completely. Attackers often hunt for exposed Telnet or API ports, so shut those down immediately.
For MikroTik, run: routeros /ip service set telnet disabled /ip service set api disabled /ip service set api-ssl disabled
Also, consider disabling the DNS cache entirely if you rely on an upstream DNS server like Pi-hole or Windows DNS. This removes the local target for DNS manipulation on the router itself, shifting the risk to a system you likely monitor more closely.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access