Site icon Windows Active Directory

Legacy D-Link DSL Routers Exploited via Unauthenticated DNS Hijacking (CVE-2026-0625)

Arun Kumar
D Link vulnerability

LA critical command-injection flaw in legacy (end-of-life) D-Link DSL gateway routers is being actively exploited to achieve unauthenticated remote code execution (RCE) and silent DNS setting changes (DNS hijacking).

What happened (and why it matters)

Affected models noted so far

The article lists these impacted legacy models/firmware ranges:

D-Link says identifying all affected models is hard due to firmware variance; they note there’s no reliable model detection beyond firmware inspection and they’re doing a firmware-level review.

Why DNS hijacking is such a nasty outcome

Once DNS is changed at the gateway:

The Active Directory angle (why AD admins should care)

Active Directory is DNS-dependent.

If a branch office (or home office) uses one of these routers and its DNS gets hijacked:

“Is there any way to avoid this with a PowerShell hack or AD hack?”

Not in the way you mean.

Practical defenses AD teams can deploy (realistic and effective)

1) Force domain clients to use your AD DNS (and only your AD DNS)

Best path: DHCP hands out only your internal DNS resolvers (Option 006), and clients are prevented from using random resolvers.

If you have devices that end up with rogue DNS anyway (Wi-Fi, travel, bad DHCP), enforce outbound DNS control:

2) Block outbound DNS to the internet from endpoints (except your resolvers)

Via Windows Firewall GPO:

This prevents a hijacked router from pushing clients to use attacker-controlled resolvers.

3) Monitor DNS server settings on domain machines (PowerShell audit)

Run this from an admin box (with appropriate remoting rights) to flag machines using non-approved DNS resolvers:

$Approved = @("10.0.0.10","10.0.0.11")  # your DC/DNS IPs

$Computers = Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=example,DC=com" |
            Select-Object -ExpandProperty Name

$Results = foreach ($c in $Computers) {
  try {
    $dns = Invoke-Command -ComputerName $c -ScriptBlock {
      Get-DnsClientServerAddress -AddressFamily IPv4 |
        Select-Object -ExpandProperty ServerAddresses
    } -ErrorAction Stop

    $bad = $dns | Where-Object { $_ -and ($_ -notin $using:Approved) }
    [pscustomobject]@{
      Computer = $c
      DnsServers = ($dns -join ", ")
      NonApproved = ($bad -join ", ")
      Status = if ($bad) { "NON-COMPLIANT" } else { "OK" }
    }
  } catch {
    [pscustomobject]@{
      Computer = $c
      DnsServers = ""
      NonApproved = ""
      Status = "UNREACHABLE/ERROR"
    }
  }
}

$Results | Sort-Object Status, Computer | Format-Table -AutoSize

4) Quick endpoint containment if you suspect DNS hijack

On impacted machines:

# Example: set on a specific adapter
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses @("10.0.0.10","10.0.0.11")

Clear-DnsClientCache
ipconfig /flushdns | Out-Null

5) Watch your AD DNS servers for “sudden forwarding changes”

This attack targets routers, not AD DNS—BUT attackers often chain DNS abuse. On DNS servers/DCs, periodically verify forwarders/root hints/conditional forwarders:

Get-DnsServerForwarder
Get-DnsServerRootHint
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated

If you want change visibility, pair this with:

What to do if you have these D-Link devices in the wild

Because the affected DSL gateways are legacy/EoL, the practical guidance is:

  1. Replace/retire any affected devices (especially anything internet-exposed).
  2. If replacement isn’t immediate: isolate them (no WAN admin), restrict management to a management VLAN, and treat them as “compromised-by-design” until removed.
  3. Assume endpoints behind them may have experienced traffic interception/credential phishing; rotate passwords/tokens appropriately for affected users.
Exit mobile version