Executive summary
The UK National Cyber Security Centre (NCSC) reported on 7 April 2026 that APT28 had compromised routers and changed their name-resolution settings to redirect selected connections towards attacker infrastructure. The agency describes theft of passwords and authentication tokens through adversary-in-the-middle activity, with downstream laptops and phones inheriting altered settings from the router. It attributes APT28 to Russian military intelligence and assesses that the operation initially targets broadly before selecting people of intelligence interest. We assess it is likely (B2) that an investigation confined to endpoint malware will miss relevant evidence in this campaign, because the reported changes occur in network configuration and the resulting account access may originate from additional infrastructure.
Contextual background
The NCSC’s accompanying announcement links APT28 to Russia’s GRU military intelligence service, specifically Military Unit 26165. That is the government’s attribution; an organisation finding an unfamiliar resolver address should not infer the same attribution without supporting evidence. The technical advisory describes activity extending from 2024 into 2026, so publication on 7 April 2026 does not mark the beginning of the operation.
The campaign matters because a shared network component can affect devices that were not directly exploited. In the first cluster described by the NCSC, compromised small-office and home-office routers supplied malicious Domain Name System (DNS) server addresses through Dynamic Host Configuration Protocol (DHCP). Connected devices then used those settings. The advisory describes a second cluster involving likely compromised MikroTik and TP-Link devices and more selective router operations, often involving devices in Ukraine.
For organisations supporting home working, our recommendation is to include the network path in incident scoping. A healthy corporate endpoint does not answer whether its configured resolver was legitimate at the time of a suspicious sign-in. Identify where the user worked, which router supplied network settings and which records remain available before deciding that the event was solely a phishing email or endpoint infection.
Technical analysis
The technical advisory describes selective responses. Queries matching particular service-related terms were directed to actor-controlled infrastructure, while other requests received legitimate destinations. Continued access to unrelated websites therefore did not establish that name resolution was trustworthy. The intended follow-on interception concerned web and email services, through both browsers and desktop applications.
One reported target was the TP-Link WR841N. The NCSC assesses that attackers likely used CVE-2023-50224 to obtain router credentials before changing DNS settings. NVD’s record identifies the vulnerability, but the NCSC’s word “likely” remains important: the report does not establish that this flaw explained every compromised model. Its list includes other TP-Link devices and expressly allows that the list may be incomplete.
The advisory notes that an attacker sometimes preserved the original primary resolver as the secondary address. In other cases, both addresses were malicious, which the NCSC assesses could indicate repeated exploitation. Investigators should therefore examine the complete resolver configuration and its history. Finding one expected address is insufficient to clear the device; finding two unfamiliar addresses still requires validation against legitimate network administration.
Router compromise, traffic redirection and credential theft are separate findings. A changed setting supports the first part of an investigation but does not quantify which accounts lost secrets. Conversely, a suspicious login may occur after the router settings have been restored. Build a timeline linking configuration changes, client network settings, relevant service access and account activity, retaining uncertainty where telemetry is missing.
Impact assessment
The NCSC describes possible exposure of passwords, OAuth tokens and other authentication material. It also warns that subsequent malicious logins may use infrastructure absent from the published indicator list. Recovery should therefore consider the services accessed from an affected network, rather than only sessions associated with a listed address. The advisory does not provide a confirmed victim total or a reliable denominator for the population exposed.
Our recommended scoping unit is the combination of router, client and account. Establish which devices used the affected settings, which people used those devices and which services they accessed during the suspected interval. Prioritise privileged accounts and sensitive services using their actual access rights. That prioritisation is a response decision, not evidence that the actor selected every privileged user or captured every session.
For shared accommodation, branch offices or managed customer networks, record ownership and administrative responsibility early. The party able to isolate or replace the router may differ from the party able to revoke cloud sessions. Assign both tasks explicitly and agree a safe communications channel before making coordinated changes.
Indicators and their limits
The following are selected indicators from the NCSC advisory, not its complete list. Preserve the source date, 7 April 2026, when importing them into detection systems.
| Indicator | Source context | Defensive use |
|---|---|---|
5.226.137[.]151 |
First-cluster DNS or interception infrastructure | Compare with resolver configurations and historical network records |
23.106.120[.]119 |
First-cluster DNS or interception infrastructure | Investigate matching traffic with its timestamp and destination role |
64.44.154[.]227 |
Second-cluster infrastructure | Correlate with router administration and DNS activity |
outlook.office365[.]com |
Legitimate domain targeted for redirection | Validate how it was resolved; this is not a malicious domain to block |
The NCSC warns that selectors can change and recommends detecting the broader tradecraft. An indicator match is an investigation lead. It should be checked against the relevant timeframe and the organisation’s own records before making an attribution or declaring credential theft. Equally, no match to this small selection does not clear a network.
Detection and hunting guidance
The following investigation plan is our application of the advisory’s reported behaviour. It is intended for systems the organisation owns or administers.
| Evidence | Question to answer | Limitation to retain |
|---|---|---|
| Router configuration and approved change records | Did either DNS server or DHCP setting change without authorisation? | A current configuration may not preserve the earlier state |
| Client network settings and available DNS records | Which devices used the suspect resolver, and when? | Missing history limits the exposed-device list |
| Router administrative logs | Which source and account made the change? | Account identity alone does not identify the operator |
| Identity-provider and email-service logs | Did account activity change after the suspected exposure? | Later access may use an unlisted address |
| User reports and support tickets | Were there unexpected sign-in prompts or service problems? | Normal browsing does not rule out selective redirection |
Compare observations with a known authorised baseline rather than assuming that every non-default resolver is malicious. Enterprise filtering, parental controls and managed network services can legitimately change DNS settings. Record the benign explanation considered and the evidence that supports or contradicts it. This reduces avoidable disruption while keeping unexplained changes visible.
Incident response guidance
Our recommended sequence starts with preserving the current configuration, available logs and relevant client settings. Record collection times and the suspected exposure interval. Avoid an immediate reset that destroys the only available explanation of what changed, unless service safety or active compromise requires urgent isolation.
Next, restrict untrusted management access and arrange a trusted recovery path with the device owner. Apply the relevant vendor’s supported remediation or replace an unsupported device. Restore approved network settings and verify them from a connected client, rather than relying only on a management-screen screenshot. Recheck that changes persist as intended after the recovery procedure.
Account containment should run alongside device recovery. Determine which passwords, tokens and sessions could have been exposed, then use each service’s supported revocation and recovery process. Review account settings and subsequent actions for unauthorised changes. Do not assume that changing the router’s password invalidates credentials already obtained from a user’s web or email session.
Close the incident only when network ownership, configuration integrity and account recovery have each been addressed. Where historical records are absent, describe the remaining uncertainty and the additional monitoring agreed. A statement that no malware was found on a laptop is not a substitute for those findings.
Keep a short recovery record for each affected network: the original and restored resolver settings, the remediation performed, the devices checked and the accounts considered for revocation. Have a second administrator verify the result where practical. This makes the closure decision reviewable and gives responders a baseline if the same user reports another suspicious login.
Threat intelligence context
The NCSC maps the campaign to the following ATT&CK techniques. These mappings describe its reported activity; they do not establish that every investigated device experienced every step.
| Technique | Reported behaviour |
|---|---|
| T1190: Exploit Public-Facing Application | Exploitation of internet-facing routers |
| T1557: Adversary-in-the-Middle | Interception aimed at account credentials |
| T1584.008: Compromise Infrastructure — Network Devices | Compromised routers used in the DNS operation |
Keep attribution separate from remediation. The organisation can correct unauthorised settings and protect affected accounts before resolving which actor caused the event. Preserve the NCSC’s confidence language when briefing stakeholders, and distinguish a campaign resemblance from a direct match supported by forensic evidence.
Mitigation recommendations
The NCSC recommends protecting management interfaces, maintaining supported software, collecting useful security logs and using multi-factor authentication. It also encourages prompt investigation of user reports. These measures address different parts of the chain and should have different owners.
Our practical implementation priority is an inventory of routers that influence organisational traffic, including remotely administered small-office devices. Record support status, management exposure, approved resolvers and the responsible administrator. Establish a process for reviewing configuration changes and replacing obsolete equipment. For account security, verify that recovery procedures cover session revocation as well as password reset.
Test the incident workflow with a harmless configuration-change exercise on a controlled network. Confirm that the change is detected, attributed to the authorised administrator and visible to the response team. The purpose is to validate visibility and coordination, not to recreate the adversary’s interception technique.
Outlook
Our assessment remains focused on the demonstrated access path: router settings and account credentials must be investigated together. Indicators may change, but the organisation can still test whether its resolver configuration is authorised and whether account activity fits expected use. Better evidence at those two points should make both detection and recovery more dependable without requiring certainty about the attacker’s identity.
