Attacks run themselves now. Here is what they leave behind. Back to Blog
Security

Attacks run themselves now. Here is what they leave behind.

Tyler Oliver October 14, 2026 9 mins

Autonomous attack tooling never tires and never forgets. That persistence leaves a trail. Two open hunts for what it leaves behind.

An attacker that never gets tired also never stops leaving a trail. Signatures catch the one attempt that works. Hunting catches everything that came before it.

The loop has closed

For years, "automated attack" meant a scanner: one pass, a list of results, and a person deciding what to do next. That person was the bottleneck. They slept, got bored, and gave up on targets that took too long.

That bottleneck is going away, and the evidence no longer comes from vendor speculation. It comes from the people who run the models and the people who clean up after intrusions.

Meanwhile, the window between disclosure and exploitation keeps shrinking. Mandiant measured an average time-to-exploit of five days in 2023, down from 63 days in 2018–19. VulnCheck found that in the first half of 2025, nearly a third of known exploited vulnerabilities were exploited on or before the day their CVE was published.

Put those together and you get a simple picture: pick a target, try something, fail, remember why, try something else, and do it again tomorrow. The loop no longer needs a person in it.

A report from this week, read carefully

On October 13, the independent researcher @TheM3gatr0n posted what they call Operation CAIRN. We want to be clear about its status. We have not seen the files. Nobody else has reported it yet. Everything below is the researcher's account, not something we have confirmed.

According to the post, an exposed server on an APAC hosting provider held an open directory with more than 150 files from an active campaign. Among them was an LLM-driven attack platform with these parts:

The researcher reports more than 229,000 dispatched attack events over 13 days, more than 85 targets, and more than 90 sessions against a single target. Each session closed with a written summary of what was tried, what was blocked and what was confirmed. The vulnerabilities named include CosmicSting and StyleSmuggler in Adobe Commerce, both in CISA's Known Exploited Vulnerabilities catalog, along with Shellshock against a mail server.

Some details deserve caution:

That last point is more interesting than it sounds. A system that tries everything also tries things that don't work. Those attempts stay on disk.

If CAIRN turns out to be exactly what the researcher describes, it is one more data point. If it doesn't, the pattern stands on the reporting above.

We built one too

Before this report appeared, we built a boxed attacker of our own, inside a sealed lab, to test how well our hunting process holds up against it: a model, a short list of lab targets, one goal, and a memory of everything it had already tried. It was not a big project. That was the uncomfortable part.

The pieces are cheap and getting cheaper. Reasoning models now run on small hardware, and an agent like this needs no data center and no operator. Eventually you could drop one on a Raspberry Pi in a coffee shop and walk away. Or leave it inside an air-gapped network, where nobody is watching for traffic that never crosses the boundary.

It also does not need to win today. It can sit quietly for weeks, months or years, checking in every so often, and act the moment a patch is missed, a port is opened or a new service goes live.

That is why Huntbase exists.

Autonomy has a shape

The loop is a capability. It is also a habit, and habits leave traces. Here is what an attacker that never tires tends to look like from the defender's side.

It comes back. A scanner passes once. A system with memory returns to the same host on day two, day five and day nine with a different idea each time, and almost all of those ideas are refused. In web logs that shows up as one source, many distinct paths, many distinct days, and a refusal rate near total.

It eventually lands somewhere a log wasn't watching. The attempt that works often arrives inside something ordinary, like a mail handshake or a web request body that nobody records. The request may be invisible. What happens next is not: a mail delivery agent or a PHP worker suddenly starts a shell, or runs the commands every intruder runs first to find out where they are.

It leaves persistence where nobody looks. A scheduled job inside a datastore container. A script in a data directory. Nobody collects those logs, so nothing alerts on them. But the files are there, on the host, right now.

It keeps time. A foothold that calls home every few minutes shows up as a shell tool talking to the same public address in hour after hour of network data. People don't work like that. Schedules do.

Why signatures miss it and hunting doesn't

A detection rule is built around the payload: the specific request, string or file that marks success. That catches the one attempt that worked, if you happened to log the place it arrived. It says nothing about the hundreds of refused attempts before it, and nothing at all when the log was never collected.

Hunting asks different questions. Who keeps coming back? What did this mail server start that it never starts? What is scheduled on this host today that wasn't last month? When the log was never collected, ask the host.

That is the bet Huntbase is built on: find what was never logged.

Two open hunts you can run today

We wrote two hunts for this pattern. Both are open hunt.md playbooks. They import into Huntbase or any hunt.md-aware runtime, every query has been checked against the schemas it reads, and each one lists its blind spots.

Autonomous Exploitation Loop Against Commerce, Mail and Edge Services

  1. It starts by listing hosts running Adobe Commerce or Magento, mail transfer agents, or edge authentication appliances, and checks for open findings on the vulnerabilities the report names.
  2. It then runs five checks side by side:
    • sources that return on several days, try many paths and are refused almost every time
    • probing of the commerce endpoints those vulnerabilities are delivered through
    • mail or web processes starting shells or reconnaissance commands
    • Shellshock-style strings in mail logs, where they are shipped
    • shell tools calling out to public addresses
  3. A hunt agent weighs the evidence per host. Containment waits for an analyst's approval.

This is the core of the first check. It needs nothing but web logs:

SELECT src_endpoint_ip, url_hostname,
       COUNT(DISTINCT url_path)  AS distinct_paths,
       COUNT(DISTINCT date(time)) AS active_days,
       ROUND(1.0 * SUM(CASE WHEN status_code >= 400 THEN 1 ELSE 0 END)
             / COUNT(*), 2)      AS refused_ratio
FROM hb_http_activity
WHERE time >= datetime('now', '-30 days')
GROUP BY src_endpoint_ip, url_hostname
HAVING active_days >= 3
   AND distinct_paths >= 25
   AND refused_ratio >= 0.8
ORDER BY active_days DESC;

Its blind spots are stated plainly. Without mail transaction logging, a payload in the SMTP envelope is invisible. Without request-body logging, you see the probing but not which request carried the exploit. Appliances that run no agent can only be seen through their own logs.

Data-Tier Container Cron Persistence and Reverse Shells

  1. It lists hosts running Redis or compatible datastores and checks whether any are reachable from the internet.
  2. It then asks the hosts directly:
    • Has the datastore process written into a cron directory, an SSH key file or a shell script?
    • Which scheduled jobs run something from a data or temp directory?
    • Which scheduled commands appear on only one or two machines in the fleet?
    • Is a shell tool calling the same address in hour after hour?
  3. A planted job plus a timer-like callback is treated as malicious. Either one alone is suspicious.

Its blind spots: Redis keeps no command log by default, a pod without an agent reports nothing, and reading a container's environment variables leaves no trace on the host. A missing result is not a clean result.

Both hunts are on the Huntbase Hub: Autonomous Exploitation Loop and Data-Tier Container Cron Persistence.

Work with us on this

A call to the community. If you research autonomous attack tooling, including the report above, we want to work with you. Run these hunts against your own data and tell us where they break, share the behavioral patterns you are seeing, or send us a hunt of your own for the Hub. Every hunt is open hunt.md, and credit goes to the researcher who found the pattern. Reach us at [email protected] or open an issue at github.com/huntbase-io/hunts.

Automate the other side, and keep people in charge

The answer to an attacker that runs itself is not a defender that runs itself unsupervised. It is hunting, triage and detection that run continuously, at the attacker's pace, with analysts deciding what happens.

That is how Huntbase works. Hunts run on a schedule or a trigger. Scout, our investigation partner, reads the results, shows the query and source behind every conclusion, and stops at the checkpoints you set. Findings become watchers you can test against your own history before they go live. Containment waits for a person.

Autonomous. Accountable.

Sign up at huntbase.io, or start with the open hunts on the Huntbase Hub.

References

#Security #AI #Threat Intel #Detection
More Articles