Living off the Land: APT28's Router Token Harvest
Just saw the report on Krebs about Russian APT groups targeting routers to harvest Microsoft tokens. It’s a nightmare scenario because it bypasses EDR entirely—there’s no malware on the endpoint.
They are exploiting older, unpatched vulnerabilities—likely flaws like CVE-2017-6736 (Cisco Smart Install) or hardcoded credentials in SOHO gear. By modifying the router's config, they can intercept traffic and siphon authentication tokens (SAML/OIDC) as they pass through the gateway.
If you have legacy edge devices, you need to assume compromise. Start by auditing your internet-facing management interfaces.
Here is a KQL query for Sentinel to identify potential config manipulation or suspicious login attempts on network devices:
DeviceEvents
| where ActionType has "ConfigurationChange" or ActionType has "LogonFailed"
| where DeviceVendor in ("Cisco", "Netgear", "Juniper")
| where RemoteIP !startswith "192.168" and RemoteIP !startswith "10."
| project Timestamp, DeviceName, ActionType, RemoteIP, Account
| order by Timestamp desc
Also, review your Entra ID sign-in logs for "Impossible Travel" events, as the attackers are using these tokens from remote locations immediately after harvesting.
Question: Given the hardware shortage, how are you guys handling these legacy routers? Are you segmenting them off, or have you found a reliable way to patch these ancient firmwares?
This is exactly why we moved to a Zero Trust architecture for our edge. We can't patch some of these older ISR routers because they're EOL, so we put them behind a dedicated firewall and strictly filtered outbound traffic. We also disabled Smart Install (TCP 4786) globally across the WAN.
I've been scanning our ranges with Masscan and finding a shocking number of Netgear and Cisco devices still exposed. The 'malware-less' aspect is the scariest part—traditional AV won't catch this. We're focusing on Conditional Access policies now; enforcing 'Compliant Device' and 'Trusted Location' mitigates the stolen token risk significantly.
Great KQL snippet. Just ran a variant of it in our Splunk instance and found three routers in our remote branch offices with config changes at 3 AM. Turns out the admin credentials were still 'admin/admin'. This is a basic OPSEC fail, but the automation makes it scalable for the attackers. Please, change your default creds people!
Since patching industrial gateways is often a non-starter during uptime, we lean on integrity monitoring. We automate daily config backups and compare checksums to catch drift immediately. Here’s a quick Python snippet to generate a hash for your baseline comparison:
import hashlib
with open("running-config", "rb") as f:
print(hashlib.md5(f.read()).hexdigest())
Any mismatch triggers an incident response review.
Great points on integrity monitoring. To add a layer of active defense, consider embedding a Canarytoken directly into the configuration as a dummy credential or NTP server. This helps detect if the config is being read by the attackers.
# Example of creating a DNS Canarytoken
curl https://canarytokens.org/generate?token=your_token_here&format=text
Place the generated URL or DNS record in your config comments or dummy settings. It’s a low-effort tripwire that lights up when they enumerate the device.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access