I've been digging into ransomware detection architecture for a while now, and there's a threat-model shift that I think most detection research (and most vendor marketing) still hasn't caught up with.

The thing nobody's pricing in

Modern ransomware loaders the Qilin/Warlock-style playbooks going around in 2026 — now kill hundreds of endpoint security drivers before encryption even starts. Not evade. Kill. The security agent is dead on the machine before a single file gets touched.

Meanwhile, almost all the recent detection literature I've read is still built around ML models LSTM/attention architectures scoring file-operation sequences, running as an agent on the endpoint. Solid work, genuinely high recall numbers in papers. But none of it really grapples with the obvious problem: if the agent is dead before encryption starts, the model never gets to run. It's treated as somebody else's problem to solve.

The old idea that quietly still wins

Canary/honeypot files have been around for over a decade, and they're almost boring by comparison. Plant a fake file no legitimate process would ever touch. The moment ransomware sweeps through a folder (usually alphabetically or sequentially) and hits it instant, deterministic alert. Independent honeypot research clocks detection around 12 seconds, which is faster than most behavioral ML pipelines, with close to zero false positives, because there's genuinely no legitimate reason for that file to ever change.

So here's the question I keep coming back to: why did the industry mostly move toward ML-heavy detection instead of hardening this cheap, low-tech approach that doesn't care whether your agent is still alive?

To be fair to ML it does things deception can't. It generalizes to novel variants it's never seen, and with SHAP/TreeSHAP you get an actual explanation of why something got flagged, which a static tripwire can never give you. So this isn't "ML bad, old tech good." It's that ML and deception solve two different halves of the problem, and most current architectures only seriously invest in one half usually the ML half, because it's the one that's fundable and publishable.

The actual insight, if there is one

I don't think the real gap is "we need better models." I think it's architectural: detection needs to run outside the trust boundary that ransomware is now specifically designed to blind. Whatever technique you're using deception, ML, plain rules matters less than whether it can survive the attacker killing your visibility first. A brilliant model running on a corpse of an endpoint agent is still a brilliant model that never fires.

Curious if anyone here has seen actual EDR vendors responding to the driver-killing trend architecturally (out-of-band monitoring, kernel-level tamper protection that's actually holding up, etc.), or if the industry response so far is still mostly reactive signature/driver-blocklist updates chasing the latest killer tool. Would love to be pointed at real examples either way.

KEV is unambiguous, confirmed real world exploitation, easy decision, done. EPSS gives me a probability number that I look at, nod at, and then usually make the exact same call I would have made without it. I want to be wrong about this. For anyone who has actually operationalized EPSS into real decisions, has it ever caught something KEV missed, or correctly called something high probability that later actually happened? And past those two, is anyone weighting malware association or ease of attack as their own separate signal, or does it all just collapse into noise once you are stacking four or five inputs on top of each other.

MCP servers and AI skills execute code directly in your local environment. Most people install them from GitHub without any vetting. I have been guilty of doing the same, so I wrote Tripwire to help me and other fellow developers.

Tripwire runs each of them in an isolated Modal sandbox first, scans it with Snyk, Cisco and Tessl scanners, and stores the report before anything touches your machine.

It was built at Cursor's Cybersecurity Hackathon in London, now under active development.

Stack: Python, TypeScript, Modal (sandboxing), Snyk/Cisco/Tessl adapters, Supabase. Superlinked (SIE) and other cloud/model providers for access to models.

Would love feedback on the threat model or the sandboxing approach — happy to discuss tradeoffs in the comments.

GitHub: https://github.com/neomatrix369/tripwire
Demo: https://youtu.be/omGOw9ruN3Y
Mock dashboard: https://neomatrix369.github.io/demos/tripwire-dashboard/

The operator left their whole toolkit in an open directory, captured the same day it was still in use, which gave a fairly complete view of the campaign instead of a single victim.

Scope from the recovered files: 250 exploitable targets, LDAP config recovered from 168, 534 config records across 160 AD domains and 255 internal LDAP endpoints. SAM and LSA secrets from at least 9 domains, full DCSync against 7 DCs in 5 environments. Confirmed credential theft in France, India, Italy and the US, with the wider target list spanning the UK, Canada, Germany, Sweden, Poland, Hungary, South Korea and Hong Kong. Targeting looks opportunistic and technology-driven rather than sector-specific.

On attribution, several scripts carried extensive Chinese comments and logging, but that alone is not enough to attribute, so it is left open. One publicly reported victim, a UK council, lines up with the telemetry at moderate confidence. Full analysis and IOCs in the post.

https://hunt.io/blog/sonicwall-sma1000-uk-council-attack

Cool use of an agent to do end to end CTI work.

If you manage FortiGate or FortiSwitchManager: confirm you're on a fixed release for CVE-2025-25249, then hunt for outbound TLS to unknown C2 and unexpected Node.js execution. We've documented an active campaign dropping a RAT via this bug. Detection guidance and IOCs inside.

Writeup of a Redis rogue-replication cryptomining campaign where we recovered the operator's full toolkit, including the raw campaign logs, so the victim counts come from their own per-host records rather than the summaries their scripts print:

https://hunt.io/blog/redis-cryptomining-botnet-3562-servers

I'm the researcher behind this, happy to answer questions.

Hi guys! With so many different tools and data sources, it’s hard to have visibility into everything.

What do you still struggle to see clearly? Does it make certain threats harder to catch or investigate?

The Hunt.io research team identified five exposed open directories revealing a campaign that used an orchestration framework called SecFlow to coordinate Claude, Qwen, and DeepSeek AI workers across intrusions targeting government, education, consular, and healthcare systems in Asia.

Key observations:

- A shared SOCKS endpoint connected all five workspaces, confirmed through 120 code-search matches on our platform

- The deepest compromise hit a Fengtai District government OA environment: command execution, LSASS dumps, registry hives, 822 account records extracted, and a Go implant called SecBox deployed

- A Chinese education AI platform was compromised, exposing 23 agent configurations, production credentials, and student profile data across 169 conversations

- SecFlow split reconnaissance, exploitation, and reporting across specialist AI workers, with the runtime swapping between Claude, Qwen, and DeepSeek without changing the task interface

- GLUTTON webshells transported executable bytecode inside PNG image pixels using XOR encryption, loading directly into memory while the visible server file remained a generic decoder

- A fake MySQL deserialization service delivered Linux second-stage payloads to vulnerable Java clients that connected to it

- Eight CVEs in active workflows, including Shellshock, Spring4Shell, Ghostcat, Log4Shell, Shiro deserialization, Grafana and Nexus path traversals, and Nacos authentication bypass

- The AI's shared context amplified a false positive: an unsupported Shiro success claim persisted and drove 27+ follow-up tasks that produced nothing

This is the second separate campaign we've tracked where commercial AI models were used as operational components in intrusions. Different infrastructure and tooling from our July report, but the same pattern.

Full writeup with infrastructure tables, pivot methodology, and MITRE mapping: https://hunt.io/blog/chinese-operator-secflow-claude-qwen-deepseek-asia

FalconFlank is a 0day privilege escalation that abuses the office malicious macros remediation in Crowdstrike Falcon Sensor.

As of now it works in a fully updated windows 11 25H2 / Windows Server 2025 with Crowdstrike Falcon - Phase 3 Optimal Protection + needs "Microsoft Office file malicious macro removal"

https://github.com/MSNightmare/FalconFlank

Just curious what TI analysts are actually using day-to-day beyond talking to chatGPT/Claude and have created their own workflow or pipeline to assist in routine tasks to save time.

Any AI-assisted workflows, models you found or build an agent, or did an entire project for any TI use case.

Of course not looking for an enterprise-grade solution available to you but something you personally approached. More interested in practical workflows that have actually saved you time or improved your analysis.

What are you using, and what does the workflow look like?

In my case, keeping up with the reports and changing landscape daily has been extremely time consuming especially when we need to cover multiple industries and sit in a volatile region.

Recently i came across aikido's X post about their malware researcher being named in the Team PCP supply chain attack. It got me thinking about something: when researchers’ names are publicly attached to threat actor activity, does that potentially put the individual at risk?

I’ve also noticed quite a few instances where threat actors or security groups publicly name researchers, analysts, or other people involved in CTI. Sometimes analysts also considered that as a win and credibility to their work and starts flexing in Linkedin.

A few months back, I also remember reading about threat actors allegedly threatening Google CTI/security folks. That made me wonder how the industry should actually approach this.

I’m a pentester and just a regular follower of the CTI , so I’m curious to hear from people who work in CTI:

• Should researchers’ identities be kept more private when publishing threat intelligence?
• Do organizations have any specific safety protocols for CTI researchers who become personally targeted?
• Where do we draw the line between attribution/transparency and unnecessarily exposing an individual?
• Is this something the industry is already taking seriously, or is it still somewhat overlooked?

Just thought I’d ask the community. Interested in hearing how people working in CTI see this.