Weekly Threat Landscape: Router Botnets, Defender LPE, and Supply Chain Risks
Morning everyone.
Another Monday, another massive recap to digest. The irony of CVE-2026-41091 (Microsoft Defender LPE) isn't lost on me—security tools needing protection from themselves is a trend we really need to squash. If you haven't checked your AV versions yet, you're inviting trouble.
On the Linux side, we're seeing old bugs resurrected to fuel new router botnets. It seems like threat actors are aggressively targeting EoL SOHO routers again. If you have any legacy infrastructure sitting in a DMZ, now is the time to audit it.
I've been digging into the "sketchy dev tool" mentioned in the recap (likely related to the recent supply chain pollution). We pushed a quick Python script to our repos to validate package hashes against the PyPI logs during CI/CD. It caught a few discrepancies late last night.
Here is a quick KQL query I’m using in Sentinel to hunt for potential signs of the Defender LPE exploitation attempts, specifically looking for suspicious handle manipulations by the MsMpEng.exe process:
DeviceProcessEvents
| where InitiatingProcessFileName == "MsMpEng.exe"
| where ProcessCommandLine contains "-s" or ProcessCommandLine contains "-sc"
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessAccountName
How is everyone else handling the router botnet resurgence? Are you aggressively patching, or just isolating them in VLANs and hoping for the best?
We're isolating. You can't patch what doesn't have a firmware update anymore. We moved all legacy routers into a 'quarantine' VLAN that only has outbound access to a specific whitelist. It's a hassle, but it beats dealing with a Mirai variant inside the core network.
Nice catch on the dev tool. We switched to requiring --require-hashes in our requirements.txt files a while back after that PyPI incident. It breaks the build sometimes if the hash drifts, but I'd rather have a broken build than a compromised repo.
pip install -r requirements.txt --require-hashes
Regarding the Defender LPE, we enabled the 'Block all Office applications from creating child processes' ASR rule as a temporary stopgap until patches are fully rolled out.
The Defender flaw is scary because it runs as SYSTEM. We saw some weird process injection attempts in our lab environment. The KQL query is solid, but I'd also recommend checking for strange service creations by the Defender service account.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'} | Where-Object {$_.Message -like '*MsMpEng*' -and $_.Message -like '*start type*'}
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access