How to check whether your organisation is exposed to the APT28 router campaign
In April, the NCSC published an advisory describing a sustained DNS hijacking campaign by APT28, the Russian GRU unit responsible for a number of significant attacks on Western infrastructure. The advisory is worth reading in full. What it describes is specific, technically credible, and directly relevant to any organisation with staff connecting from home offices, hotels, or shared workspaces.
This post covers three things: what the attack actually does, what you can practically check, and what the advisory tells us about a broader problem that extends well beyond this particular campaign.
What APT28 did
The attack is straightforward in principle. APT28 exploited known vulnerabilities in unpatched off-the-shelf routers, primarily TP-Link and MikroTik models running manufacturer firmware, to gain access to the devices. Once in, they modified the router’s DHCP DNS settings to redirect DNS queries through attacker-controlled servers.
Every device connected to that router, including laptops and phones, inherited the poisoned DNS configuration automatically. The malicious DNS servers then selectively redirected lookups for email and authentication services, specifically Microsoft Outlook and M365 login domains, to adversary-in-the-middle infrastructure. That infrastructure harvested passwords and OAuth authentication tokens.
The NCSC describes the campaign as opportunistic rather than targeted. APT28 was not going after specific individuals. They were gaining visibility over a large pool of users and filtering for intelligence value at each stage. If your staff connect from home networks or shared environments, their routers are in that pool by default. No specific targeting is required to be caught by it.
The activity ran from at least 2024 into 2026 before it was publicly attributed. More on that below.
What to check
If you have staff connecting from home or while travelling, here is a practical starting point.
Audit your exposure to the affected device models
The NCSC advisory lists the specific TP-Link and MikroTik models exploited in this campaign. Conducting a meaningful audit against that list is a more involved exercise than it might initially appear.
At minimum, a credible audit requires the following.
Cataloguing the estate: You need the router make, model, firmware version, and date of last firmware update for every router any member of staff connects through when accessing work systems. That includes home routers, and it requires asking each person to find out, because your IT team has no direct visibility into those devices. The NCSC advisory notes explicitly that its list of affected models is likely not exhaustive, so firmware version and update history matter as much as the model itself.
Collecting data from users: For devices on or near the affected list, each user needs to verify their DNS configuration and firmware status and report the results back to IT. This relies on staff following a process correctly and accurately, and on someone in your team reviewing the results, cross-referencing against the NCSC indicators, and following up on anything that warrants it.
Reviewing and acting on results: Someone needs to own the review, maintain the knowledge of what they are looking for, and have a defined response process for any device that raises a concern.
Keeping the picture current: Audits cannot be not a one-time exercise. Staff change routers, the list of affected models may grow, new people join (and people leave), all of which need to be captured. A useful process, at the very least, requires a process for staff to proactively notify IT when their home router changes, and a regular review cycle to confirm the position remains accurate.
Considering connections beyond home networks: Serviced offices and coowrking spaces, holiday rentals and extended travel create the same exposure. A policy requiring staff to check whether the router at a given location appears on the affected list before connecting to work systems is a defensible position. How you could ever enforce it in practice is a separate question.
The cumulative picture is an ongoing programme rather than a single check, built substantially on self-reported data from an estate your IT team cannot directly see or manage. We have written previously about what a managed router programme looks like in practice and the setup and compliance overhead it involves.
Check DNS settings directly
For any of the affected router models you can access, log into the router admin interface (typically accessible at 192.168.1.1 or 192.168.0.1) and check two things: the WAN DNS configuration, and the DNS settings being pushed to downstream devices via DHCP. Both should show your ISP’s standard DNS servers, or a known provider such as 8.8.8.8 or 1.1.1.1. An unfamiliar IP address in either field warrants investigation.
From an end-user device, the simplest check is a DNS leak test. Tools such as dnsleaktest.com and ipleak.net will show the IP addresses of the DNS servers currently handling your traffic. Cross-reference the results against the indicator list in the NCSC advisory. An unfamiliar IP that does not correspond to your ISP’s servers or a known provider warrants investigation. These tools show the resolving server rather than the raw DHCP configuration, which in most home network environments amounts to the same thing and is the more directly relevant check.
Review network and DNS logs for the published indicators
The NCSC advisory includes a substantial list of IP addresses associated with the malicious infrastructure. If you have DNS query logs, firewall logs, or network monitoring in place, search for these addresses in recent traffic. The NCSC explicitly notes that these indicators are liable to change, so a clean result is not conclusive, but a positive match is a clear signal to investigate further.
Mitigation: what works, and where the realistic limits are
The NCSC’s mitigation guidance is sound as far as it goes. Apply patches promptly. Enable MFA. Use modern systems. All of this is correct.
A note on MFA specifically: the advisory describes credential theft that includes OAuth authentication tokens, not just passwords. Standard one-time password MFA does not protect a harvested OAuth token, because the token represents a session that has already been authenticated. FIDO2 hardware authentication, such as passkeys or physical security keys, is significantly more resistant, because the credential is cryptographically bound to the legitimate origin domain and cannot be replayed against a different one.
The harder structural reality is this: most of the mitigations in the NCSC advisory are things your organisation can advise on but not directly control for staff connecting from home networks. You can recommend staff patch their home routers but you will struggle do it for them. You can recommend they verify their DNS settings but most of them will not. You cannot easily audit what router model is sitting between a staff member’s laptop and the internet when they are working from holiday rental or a hotel.
Endpoint security, identity tools, and MFA all address important layers of the stack. None of them address the network environment the device is connecting through. That is the gap this campaign is actively exploiting.
The part that should concern you more than APT28 itself
The campaign described in the NCSC advisory ran for at least twelve to eighteen months before it was publicly attributed and disclosed. This is not unusual. Volt Typhoon was believed to have been present in US critical infrastructure for five years before attribution. Salt Typhoon was in US telecommunications networks for an extended period before it became publicly known. State actor campaigns are specifically designed to be persistent and quiet. Attribution is hard, takes time, and requires significant investigative resources.
What the NCSC published in April is not the current state of the threat landscape. It is the current state of what has been investigated, attributed, and cleared for public disclosure. By definition, that is a subset of what is actually occurring.
The question for any security team is not simply: is my organisation exposed to the APT28 campaign described in this advisory? The question is: if this class of attack has been running since at least 2024 without public disclosure, what else is running now that has not yet been attributed? The answer is almost certainly: more than we know.
Router vulnerabilities are particularly attractive for this kind of long-term, low-visibility access. Compromised routers are outside the scope of most endpoint security tools. They do not generate the kind of alerts that endpoint detection systems produce. In a home network environment, there is typically no monitoring at all.
The structural answer
Checking specific models and IPs is the right immediate response to this advisory. It will not address the underlying exposure.
The underlying exposure is that organisations routinely have staff connecting to sensitive systems from network environments they cannot verify, monitor, or control. The router the staff member is sitting behind is running firmware the organisation has never audited, on a device the organisation has never seen, on a network the organisation has no visibility into.
Managing the router environment, rather than just advising on it, is the structural answer to this class of attack. That means deploying a router under organisational control with centrally managed firmware at each connection point, not relying on a staff member’s home ISP equipment to remain uncompromised.
This is specifically what Loxada does. Our managed secure router ships fully configured, runs Loxada proprietary firmware rather than manufacturer firmware, and establishes an encrypted connection that routes traffic through the Loxada RPN before it touches the surrounding local network. The poisoned DNS described in this advisory does not reach through that architecture. We have written a technical note on exactly why, which is available on request.
The NCSC advisory: APT28 exploit routers to enable DNS hijacking operations
If you would like to discuss how this applies to your specific environment, we’d love to talk to you! Contact us here.
