Silent Token Harvesting: APT28's Router Pivot without Malware
Just caught the report on Russia-linked APT28 units using known flaws in aging routers to mass-harvest Microsoft Office tokens. The operational security here is terrifyingly simple: they are leveraging old CVEs (likely hitting EOL Cisco/Netgear gear) to siphon tokens without deploying any malware on the endpoint.
Since they aren't dropping binaries, standard EDR won't catch this. They are essentially living off the land by manipulating the router's config or DNS to intercept authentication flows.
If you're defending M365, you need to pivot to looking at where the token is being presented rather than just what is generating it. I'm currently hunting for logins where the device identifier claims to be a legacy OS or mobile device, but the ASN points to a residential ISP or hosting provider often associated with SOHO infrastructure.
Here is a KQL query to hunt for potential token theft via these vectors, focusing on 'Impossible Travel' scenarios combined with legacy user agents:
let LegacyBrowsers = datatable(Browser:string)["IE 7.0", "IE 8.0", "IE 9.0", "Unknown"];
SigninLogs
| where ResultType == 0
| extend DeviceDetail = parse_(DeviceDetail)
| join kind=inner LegacyBrowsers on $left.DeviceDetail.browser == $right.Browser
| summarize Count = count(), Locations = make_set(Location) by UserPrincipalName, IPAddress
| where Count > 1
This helps spot cases where a user 'suddenly' reverts to an old IE/Unknown browser from a new IP—often a sign of a router proxying the auth request.
How is everyone handling legacy SOHO router remediation for WFH staff? Getting hardware replaced in this economy is a nightmare.
The 'no malware' aspect is exactly what makes this so dangerous. We implemented a stricter Conditional Access policy to block 'Unknown' user agents and legacy authentication protocols last month. It broke a few legacy printers and scanners, but it effectively neutralized this attack vector for our O365 tenant. I highly recommend blocking legacy auth entirely if you haven't already.
We found a bunch of Netgear R7000s still running 2017 firmware during our last external audit. I wrote a quick bash script to scan our IP ranges for the specific UPnP responses indicative of those vulnerable firmware versions.
#!/bin/bash
for ip in $(seq 1 254); do
echo "Checking 192.168.1.$ip"
curl -s --connect-timeout 1 http://192.168.1.$ip:49152 | grep -q "Netgear" && echo "Vulnerable Device Found at 192.168.1.$ip"
done
It’s tedious, but physically replacing those EOL devices is the only real fix since they don't get patches anymore.
This brings back memories of the VPNFilter campaign. The scary part isn't just the token theft, but the persistence. Even if you rotate the user's credentials, if you don't wipe the router config (or flash the firmware), the actors are still sitting in the middle of the traffic. If you have remote workers using their own gear, assume they are compromised and force them through a corporate ZTNA gateway.
Since DNS manipulation is a key vector, ensure your resolvers log query spikes or suspicious destination IPs. It's also worth auditing router configs for unauthorized static routes regularly. To catch this via SIEM, you can hunt for unexpected traffic patterns hitting your internal gateways using a query like this:
NetworkEvents
| where DeviceName in ("Gateway01", "Gateway02")
| where RemotePort == 443
| summarize count() by DestinationIP, bin(TimeGenerated, 5m)
| where count_ > 500
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access