Identity Attack Surface: The 18k-Node Router Token Heist
Just caught the latest Krebs report regarding APT28 (Russia's military intelligence) leveraging legacy router flaws to swipe Office tokens. They’ve reportedly compromised over 18,000 networks without dropping a single binary—just pure config manipulation. It’s a stark reminder that our perimeter identity often relies on devices that are EDR-blind.
The attackers seem to be targeting older SOHO routers (MikroTik, TP-Link, etc.) where administrative interfaces are exposed or firmware is outdated. Once in, they aren't installing malware; they're altering DNS settings or using the router as a pivot to intercept authentication flows and siphon Refresh Tokens. This gives them persistent access to O365 environments without triggering usual malware alerts.
Detection Opportunities: Since no malware is used, we have to rely on behavior analytics. If you have visibility into router logs, look for unauthorized changes to DNS settings. On the identity side, watch for impossible travel or logins from legitimate user accounts originating from anomalous geolocations that correspond to known proxy/VPN exit nodes.
Here is a basic KQL query to hunt for potential token theft indicators in your SigninLogs:
SigninLogs
| where ResultType == 0
| extend LocationDetails = tostring(LocationDetails)
| where LocationDetails contains "RU" or LocationDetails contains "CN" // Adjust based on threat intel
| summarize count(), dcount(UserPrincipalName) by AppDisplayName, IPAddress, LocationDetails
| where count_ > 5
For those managing remote offices, how are you handling the patch management cycle for these edge routers? Are you pushing for replacement, or is there a solid segmentation strategy in play?
We pushed a hardening standard last year explicitly banning the management of MikroTik and TP-Link devices from WAN interfaces. It's a low-tech fix, but given how many of these 'supply chain' style attacks start with a default creds scan on port 80/443/8291, it’s effective. We also implemented a strict "no internet" rule for management planes.
If you're stuck with older gear, at least disable Winbox and API access from the WAN.
The 'living off the land' aspect here is terrifying. They use the router's existing legitimate functionality to tunnel traffic. We've started correlating NetFlow data with MFA alerts. If we see a successful MFA challenge immediately followed by traffic to a high-risk country IP that doesn't match the user's registered device ID, we auto-revoke the session.
Great point on the 18,000 scale. This suggests automated exploitation of known CVEs (likely the MikroTik Webfig or Winbox vulnerabilities from years past). I'd add checking for specifically configured static DNS routes on your routers.
Here is a quick expect script to audit a list of MikroTik routers for DNS settings:
#!/usr/bin/expect
set password [lindex $argv 1]
spawn ssh admin@[lindex $argv 0]
expect "password:"
send "$password\r"
expect ">"
send "/ip dns print\r"
expect ">"
send "exit\r"
expect eof
Cron that and diff the output daily.
While remote hardening is vital, we must also consider the physical reality of these edge devices. Many SOHO routers sit in unsecured branch locations where physical access isn't strictly controlled. If an attacker can walk in and plug in a console cable, remote defenses are bypassed entirely. We're pushing for physical containment in locked enclosures. To audit for unexpected local accounts on MikroTik gear, run:
mikrotik /user print
Ensure only your intended administrative accounts are present.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access