Every so often a threat report sends me straight back to the early days of ATT&CK. It's rarely the headline. It's usually some small detail in the middle of the report that most people skim past.
This time it was a renamed bash binary.
Palo Alto Networks Unit 42 recently published research on an AI-powered espionage campaign targeting government Linux infrastructure. The attackers used open-source tools, custom malware, web shells, and payloads with artifacts consistent with AI-generated code. That's the part everyone will write about, and fair enough.
The part I keep coming back to is smaller. The attackers copied /bin/bash, renamed it .tourch, and changed its permissions so they could run commands as root.
I've seen this movie before. I was in it, and I did not come off well.
Around 2011 or 2012, ATT&CK was closer to a top 10 list than the framework you know today. I was working with Eric Sheesley and Brad Crawford, and our blue team had just come off a solid showing against the red team.
To be fair to the red team, they threw us a few softballs in that first round. We chose not to dwell on that. We'd closed real gaps in our endpoint and network detections, especially around net.exe, and we were pretty pleased with ourselves.
Next engagement, we were blind. For two days.
We knew something was going on. The detections we'd been so proud of had almost nothing to say about it. Eventually we found SMB connections that looked a lot like the behavior we'd been hunting for. They weren't coming from net.exe, though. They were coming from foo.exe.
Then we found the rename event.
The red team had copied the binary, given it a new name, and walked right around everything we'd built. There was nothing sophisticated about it, which was the humbling part. We hadn't built a detection for the behavior. We'd built a detection for a filename.
That question has followed me around ever since, because every term you put in a detection is a bet about what you're trying to catch.
Take the net.exe case. Did we need to look for net use? Or any executable called with a use argument? Maybe the better signal was access to specific administrative shares. Maybe it was the volume of data moving across the connection. Maybe it was some combination of those, plus context about the host, the user, and whatever else was happening around it.
There usually isn't a clean answer. Go too specific and a rename beats you. Go too general and you've built a noise machine your analysts learn to ignore by Tuesday. Somewhere in between is a detection precise enough to be useful in your environment.
I call this the Goldilocks problem of detection engineering. Too specific. Too general. Doesn't capture the behavior. And every so often, after enough testing, arguing, and more testing, just right.
Now put yourself in front of the Unit 42 activity with a blank rule.
You could look for .tourch. That catches this exact intrusion, assuming the next attacker has the same taste in filenames. They won't.
You could look for commands touching /etc/shadow. That's closer to the thing you care about, but now you're sorting through every legitimate admin and security tool with a good reason to read it.
You could look at how the shell gets invoked, the permission change on the binary, the copy and rename, or the process activity around it. Personally, I like catching the creation of an unusual setuid shell before the attacker ever uses it. It sits earlier in the chain, and a new filename doesn't get around it.
All of those are reasonable. All of them come with tradeoffs, and the right tradeoff depends on what telemetry you have and what normal looks like on your Linux systems. This is why detection engineering has never been as simple as copying a command line out of a threat report and shipping it as a rule.
Different operating system, different decade, same lesson I learned from foo.exe.
AI is speeding up parts of these attacks. Attackers generate scripts, rewrite code, and try new variations faster than they used to. I'm not going to wave that away.
But look at the behaviors in the Unit 42 report. Renaming legitimate binaries. Harvesting credentials. Setting up persistence. Abusing privileges. Clearing logs. None of that is new. What's new is how quickly an attacker spins up the next variation.
So here's the uncomfortable math for defenders. If an attacker produces a new filename or command line in seconds, you won't win by writing one rule per artifact. Point AI at that same approach and you get the same result at higher volume: more rules that are too specific, too noisy, or built on the wrong assumption.
I already made that mistake by hand in 2012. I'd rather not automate it.
A detection is only as good as your understanding of the behavior going in. That's true whether a person writes it or a model does.
If all you hand an AI system is a command line from a threat report, don't be surprised when it hands back a rule that looks for that exact command line. It did what you asked. That's the foo.exe problem with a faster turnaround.
Give it procedure-level intelligence instead and you get to better questions. What was the adversary trying to accomplish? Which parts of the execution are essential to the behavior, and which are quirks of this one implementation? What variations have we seen before? Which defensive tools could see this activity? And how would we know the detection works?
None of this replaces testing or human judgment. It gives the testing and the judgment a much better place to start.
The other half of this is your own environment. Knowing how the attacker operates tells you what to look for. It doesn't tell you whether you'll see it.
Would your endpoint tooling flag a copied and renamed bash binary? Would you see the permission change? Would another control catch the read of /etc/shadow? Do you already have detections covering pieces of this procedure, and has anyone checked whether they fire?
Those questions sit at the center of Threat-Led Defense, and they're where we spend most of our time at Tidal Cyber. We connect procedure-level intelligence to the defensive tools an organization already owns, so security teams see where the gaps are and decide what to fix first.
It's also why I'm interested in AI for detection engineering. Getting from "here's what the adversary did" to "here's what we should change" takes far too long today, and AI should shorten that. But only if we start from the behavior and the environment. Otherwise we're automating the mistakes we made in 2012. Only faster.
More than ten years later, I still think about foo.exe. It wasn't clever. That's the point. It showed how easy it is to mistake a detection for one implementation for a detection of the behavior itself.
AI will help attackers move faster and throw more variations at us. The behaviors underneath are mostly ones we've studied for years, and we have ATT&CK and a lot of hard-won detection engineering experience to build on, including as the foundation for AI-assisted detection engineering.
The job is still the Goldilocks problem. We need to solve it faster, and preferably without another two days of wondering why foo.exe is talking over SMB.
Palo Alto Networks Unit 42, AI-Powered Espionage Campaign Targets Government Linux Infrastructure, October 15, 2026.