The Illusion of Progress: Fighting 2005 Malware and AI Overreach in 2026
Reading the weekly recap, I can't help but agree with the sentiment: "Everything is dumb again." It feels less like innovation and more like regression. We're dealing with Fast16, a Lua-based malware framework that dates back to the mid-2000s (pre-Stuxnet), yet it's apparently relevant enough to make headlines again. If we are still fighting OT sabotage frameworks from two decades ago, have we actually progressed?
Meanwhile, the "fake help desk" trend is terrifyingly effective. We're seeing actors abuse trusted platforms like Microsoft Teams to deliver payloads (similar to the UNC6692 SNOW delivery methods). Users are conditioned to trust the "IT Support" popup, and attackers know it. It’s not just about CVEs anymore; it’s about abusing trust in legitimate tools like the new XChat platforms and standard remote access software.
Detection is getting noisy, but we can focus on the behavioral anomalies. For those hunting on their endpoints, watch for communication apps spawning shells:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "teams.exe" or InitiatingProcessFileName =~ "xchat.exe"
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe", "python.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine, ProcessCommandLine
And for the Fast16/Lua activity on legacy systems, don't ignore obscure script interpreters:
# Check for recently modified Lua scripts on non-standard paths
find /home /var /tmp -name "*.lua" -mtime -1 -exec ls -la {} \; 2>/dev/null
We have AI tools tracking employee keystrokes on one side and 20-year-old malware on the other. It’s a mess.
**Discussion:** With the rise of "living-off-the-land" attacks using trusted chat apps, are you guys blocking scripting languages (PowerShell/Python) entirely for standard users, or is that just a pipe dream in 2026?
Blocking PowerShell entirely for non-IT users is the only thing keeping us sane right now. We implemented AppLocker policies last year to restrict mshta.exe and powershell.exe from spawning from browsers or chat clients. It broke a few internal automation scripts, but the drop in phishing payload execution was worth the headache. You can't rely on users to spot a fake IT desk anymore; their 'spidey sense' is gone.
The Fast16 stuff is wild, especially when you look at the OT sector. I'm consulting for a manufacturing firm, and they still have Windows XP boxes controlling PLCs. They air-gap them, but technicians bring in laptops that have been phished via Teams. It doesn't matter how old the malware is if the path to the target is a USB drive or a remote bridge. We need to focus more on the jump hosts than the malware itself.
Great KQL snippet. I'd add a filter for InitiatingProcessCommandLine containing "-enc" or base64 strings, as that's how most of the SNOW-like variants are hiding the initial payload. Also, keep an eye on NetworkEvents immediately following the process spawn; they usually beacon out to a C2 within seconds.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access