Passive Token Harvesting: The Router Mass-Heist & Token Theft
Hey everyone, just caught the latest KrebsOnSecurity report regarding the Russian military intelligence campaign targeting routers. It’s a textbook "Living off the Land" scenario that should have us all worried. Instead of dropping malware on endpoints, they are leveraging known vulnerabilities in end-of-life SOHO and SMB routers to harvest Microsoft 365 authentication tokens.
What is particularly alarming is the scale: over 18,000 networks affected. By altering routing tables or DNS settings on these neglected devices, actors are performing a Man-in-the-Middle (MitM) attack to siphon OAuth tokens without ever touching the disk.
The Technical Breakdown:
- Vector: Auth bypass and configuration modification on older firmware (typically devices unpatched since 2018-2020).
- Target: Active Directory Federation Services (ADFS) traffic and direct M365 logins.
- Mechanism: Passively capturing
RefreshTokensorAccessTokenspassed during authentication.
Since there is no malware on the endpoint, your EDR is essentially blind here. Detection has to happen at the identity or network layer.
Here is a KQL query for Sentinel to help identify potential sign-ins originating from anomalous locations that might indicate this kind of router interference:
SigninLogs
| where ResultDescription == "Success"
| extend DeviceDetail = parse_(DeviceDetail)
| extend Browser = DeviceDetail.browser, OS = DeviceDetail.operatingSystem
| project TimeGenerated, UserPrincipalName, AppDisplayName, Location, Browser, OS, DeviceId, RiskDetail
| where RiskDetail has "detected" or Location !contains "Office"
| summarize count() by UserPrincipalName, Location, bin(TimeGenerated, 1h)
| where count_ > 3
Given that these routers are often in home offices or small branch locations, how are you guys handling legacy equipment? Are you enforcing stricter Conditional Access Policies, or do we need to start blocking authentication attempts from known consumer-grade ISP ranges?
Solid query. We've been pushing 'Compliant Device' requirements via Conditional Access for exactly this reason. If the device isn't enrolled in Intune or hybrid AD joined, they don't get the token. It breaks some legacy workflows, but it stops token replay attacks cold. Also, we started forcing TLS 1.3 on internal traffic to make MitM harder.
This is the exact reason I hate supporting SOHO gear for remote employees. Users plug in a 5-year-old Netgear from their closet and think it's fine because it 'connects to the internet.' We've started shipping pre-configured SD-WAN units to anyone working remotely. It costs more, but I can push firmware updates centrally. You can't patch what you can't manage.
Don't forget to check your perimeter logs for these routers acting as proxies. We caught a similar setup by looking for high volumes of traffic to login.microsoftonline.com from a single public IP associated with a residential ISP.
grep "login.microsoftonline.com" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20
If you see hundreds of unique accounts coming from one home IP, you've got a problem.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access