@Khazix0918: https://x.com/Khazix0918/status/2074010677413581196
Summary
The author shares their experience of a 48-hour DDoS attack on their website AIHOT, successfully defending and fixing security vulnerabilities using the Claude Fable 5 AI model.
View Cached Full Text
Cached at: 07/06/26, 08:07 AM
My Website Was Under Attack for 48 Hours, and Claude Fable 5 Defended It All
This weekend was probably my most dramatic one ever.
After publishing the Claude Fable 5 article on Friday, quite a lot of people read it, and the feedback was generally good.
But I don’t know who I offended — maybe some big shots wanted to teach me a lesson, or show me that Vibe Coding websites are crap with endless security vulnerabilities.
Then, they attacked my garbage AI news site AIHOT for two straight days…
I was forced to pick up AI and engage in this offensive-defense battle with my extremely rudimentary knowledge.
Later I posted a reflection: indeed, learning by doing. These two days might have been the fastest I’ve ever improved my cybersecurity knowledge…
Here’s the story.
Last Saturday, because I had spent all day Friday moving houses and was tired, plus the AIHOT server had no unusual activity, I went to bed relatively early — around 2 AM (I normally go to bed around 4 AM).
Then the nightmare began.
I only saw all this when I later reviewed our server logs.
At exactly 4:48:20 AM on Saturday, while I was sound asleep.
An IP from a German data center came to my AIHOT website and requested an image.
Since I cache many images in advance for better user experience — something like this.
My server dutifully received it and returned that compressed 86k image to it.
Looking back, this was actually reconnaissance. I only understood their tactics when I later analyzed the attack.
This German IP had a script with a pre-collected list of all the real image links on our pages. It went through the list one by one, confirming which links would actually make my server interact and return data.
The User-Agent field of this German IP wasn’t disguised as a server or a crawler — just one line:
#TeamAntiAI
Translated, it means Anti-AI Squad.
I initially thought it was some organization, but after checking over the weekend, I found no information about any Anti-AI Squad anywhere on the internet. Most likely, it was just a label someone gave themselves.
Their goal was simple: take down a Vibe Coding website like mine, teach an outsider like me a lesson, and show us that not everyone can build websites for public service.
If you dare to go public, I’ll destroy you.
At 5:30 AM, the attack officially began.
The number of requests to my server started climbing steeply.
At 5:58 AM, it hit 130,000 requests in one minute.
At 6:00 AM, the first error log appeared on my server. In plain English, it means: the requests were too intense, and my AIHOT couldn’t keep up.
Then from 6:04 to 6:07 AM.
In those 4 minutes, it hammered my image endpoint with 2.36 million requests.
The peak was at 6:05 AM — 870,000 requests in one single minute.
Based on last month’s data, my site normally handles about 3 million requests per day, averaging around 2,000 per minute.
That one minute hit 340 times my normal load.
It didn’t stop all morning — wave after wave. By the time I woke up at noon, it had thrown about 11 million requests total.
And all of this happened while I was sleeping.
When I woke up, I saw overwhelming user feedback and alerts from Feishu groups. By the time I realized what was happening, the site was already down. Users would get errors randomly, Skills and APIs kept failing.
I scrolled through the dense attack records in the logs — every single line carried the same signature: #TeamAntiAI.
Let me briefly explain: this “signature” is basically a tag placed in the HTTP User-Agent field. User-Agent is normally where browsers and crawlers identify themselves — Chrome, GPTBot, Googlebot, etc. So the attacker left this signature with a simple intention:
Pure provocation, conveying an attitude, and teaching me a lesson.
I was pretty devastated.
I had no idea who I’d pissed off.
After waking up and seeing all this, I immediately posted a notification in the AIHOT Feishu subscription group, explaining the situation.
And there was a fundamental problem: I’m not a developer, let alone a security engineer. As a pure outsider with a design background, asking me to diagnose an active attack is like asking me to fix an airplane.
So to solve this and keep my site running, I had to resort to AI. You’re an Anti-AI Squad? Well, let’s see you fight Claude Fable 5…
So I told my Claude Fable 5:
“We’re under attack. The only goal is to block the attack without harming real users, and then do a full recovery.”
As a complete outsider, that’s all I could do.
But honestly, the next 48 hours might have been the fastest learning period of my life. I couldn’t just be clueless and hand everything over to AI. So while it analyzed, I learned. Every thinking process, every unfamiliar technical term or approach — I immediately screenshotted and sent to Codex, asking it to explain in plain English based on my AIHOT project.
Trust me, when your server keeps crashing and your domain bill keeps burning money, your learning motivation is at its peak…
After analyzing for a while, Claude Fable 5 gave me a very surprising conclusion.
It said my site wasn’t actually breached — my server’s defenses were very good.
Those nearly 2.4 million requests hitting AIHOT’s image endpoint were solidly blocked by our previously configured rate limiter. The log data was beautiful: 2.39 million rejections, only about a thousand from the initial reconnaissance made it through. A 99.95% block rate.
I was confused. Then how did my server crash?
Then Fable 5 said the real problem was somewhere else on our server.
I need to explain the special nature of our server first, or you won’t understand how this pitfall appeared.
The server I bought from Volcano Engine is actually our company’s shared server, running over 30 projects.
Previously, to let colleagues enjoy the joy of Vibe Coding, I packaged the entire deployment pipeline of this server into a Skill. It worked really well.
Colleagues don’t need any development or operations knowledge — just tell the AI “deploy this project for me,” and the AI connects to the server, creates isolation, builds services, sets up domains — within minutes, the project goes live.
But looking back, when I created that Skill for everyone months ago, my only thought was: convenience.
At that time, security wasn’t even on my requirements list.
That was still the era of Opus 4.6. I didn’t ask, so AI didn’t implement it.
So each project was like a door — every new door opened quickly, but none came with a lock.
My own AIHOT had its own rate limiting because I had separately hardened its security. So out of 30+ projects, only mine was protected.
The attacker scanned the entire server and discovered this.
My image endpoint came in through the aihot domain with rate limiting — couldn’t attack it.
But they found another project’s domain that wasn’t protected.
So they directly sent 8.68 million requests to that domain.
Those 8.68 million requests instantly saturated the server’s concurrent connections. My nginx’s concurrent connection limit was only 768 at the time.
Think of it as the server only having 768 hands to shake at once — the attacker grabbed all of them, and real users’ hands were completely ignored.
So the handshake failed, and from the user’s perspective, the entire site was down. At one point on Saturday morning, errors occurred over 10,000 times intermittently.
Honestly, when I saw this analysis, I was stunned. I always thought I was a very cautious person. AIHOT has significant traffic now, so I added tons of protections for it. But without Claude Fable 5’s analysis, I never would have known how many holes existed in other projects on that server.
Then came the normal steps: block IPs, add rate limiting, build a security middleware on the server, and apply full-domain protection to all projects.
During this process, Claude Fable 5 also independently discovered several security vulnerabilities and optimization opportunities on our server and AIHOT — things that Opus 4.8 and GPT-5.5 had never found during their reviews.
After submitting many protections on Saturday afternoon, I checked the logs and had AI scan again — traffic and stability were mostly back to normal. I thought it was over.
But I was wrong.
Just after midnight on Saturday night, I came back from a shower and found our Feishu feedback group suddenly exploding.
Our AIHOT site has a user feedback feature — submissions automatically push to my Feishu group so I can see feedback and decide whether to optimize.
That night, tens of thousands of messages suddenly appeared in the group. I checked, dumbfounded — they were all pure numeric gibberish, sent from fake QQ email addresses.
This attacker had targeted the feedback endpoint.
A Beijing Unicom IP was flooding our feedback endpoint with garbage data at 5.5 requests per second.
And the frequency was carefully chosen — sitting just barely below the rate limit.
It dumped over 30,000 junk records into my database. My Feishu exploded.
Pure malice…
And this was just the appetizer.
At 12:30 AM, the main force arrived.
A new batch of IPs joined — some were cloud servers, some were residential broadband. Completely different from the first solo brute-force attacker. This time it was multi-IP coordinated, and each IP’s request frequency was precisely under the rate limit. Individually, none looked suspicious, but together, they formed an army.
And this time, most didn’t even carry the #TeamAntiAI flag. They all disguised themselves as normal users and launched a batch attack.
Their tactics had also upgraded. They targeted the most expensive pages — those that couldn’t be cached and required server-side rendering every time. Each request carried a random parameter to bypass the cache. The cache saw different parameters, thought it was a new page, and let the request through for the server to recalculate.
Soon, my server’s rendering queue was completely jammed.
I even saw a log entry for a real user’s request to load a list page — it waited 60.024 seconds.
60 seconds…
Normally, that page loads in 40 milliseconds — not even 1 second. It was 1,500 times slower.
I had no choice but to apologize again in the Feishu group.
Then Claude Fable 5 began its synchronized defense.
Looking back at the Git commit records from that night, I still feel emotional.
At 12:56 AM, AI blocked the IPs flooding the feedback endpoint, added independent anti-spam rules to the feedback endpoint — Feishu group went quiet.
At 1:17 AM, added rate limiting to the analytics endpoint, closing another exploitable hole.
At 1:36 AM, blacklisted 7 confirmed attack IPs.
The moment those IPs were blocked, the list page response time dropped from 60 seconds back to 40 milliseconds.
At 1:51 AM, began the root fix — a complete cache hardening went live. This was the real game-changer of the night.
First, it changed the cache identification rules to completely ignore the random parameter. From then on, no matter how random the parameter, it would hit the same cached version, closing the previous vulnerability.
Then it extended the cache time from 60 seconds to 3 minutes. Since AIHOT is a news site, most content is static — a list page from 3 minutes ago looks almost identical to now. But for the server, the number of times the same page needs true re-rendering is cut by a factor of 3, further optimizing performance.
Then it implemented request coalescing — when 100 people request the same page at the same time, instead of the kitchen cooking 100 times, only the first request goes in to cook, and the other 99 wait at the counter. When it’s done, they all get served together. More performance optimization.
At 2:15 AM, it rewrote all the system alert messages — from engineer jargon to plain language a product manager could understand.
Because it knew who would be reading alerts in the middle of the night: me. I had previously mentioned I couldn’t understand the technical wording.
Then it changed the ban approval process. The previous process (set by Claude Opus 4.8) required my approval for every ban to avoid false positives. But it realized I couldn’t understand the evidence either — IP geolocation, request fingerprints, behavior patterns — I’d stare at them and make decisions by gut feeling.
So it directly pulled the characteristics of malicious IPs from the past two months, listed 6 rules, and created an automated ban strategy that wouldn’t hurt real users while automatically banning all malicious IPs.
At 2:40 AM, extended the access log retention to one year, citing potential need for evidence collection.
Finally, it also uncovered some long-running data-scraping crawlers that were constantly stealing our data to create mirror sites. After verifying their characteristics, Claude Fable 5 banned them all.
Everything was done around 3 AM. I was afraid of another massive attack around 5 AM that would crash my server and blow up my bill. So I told Claude Fable 5: “I’m going to sleep. Keep an eye on things.”
Fortunately, the night was peaceful. All attacks were blocked.
Last night, I saw a user’s comment.
It was quite touching.
What team? Just me + one AI.
And I’m a complete outsider, a total newbie. All I could do was tell Claude Fable 5 what happened, what users reported, and ask it to handle it quickly.
I once used an analogy: different tiers of models feel like completely different things.
A weaker model is like a very basic executor. You have to lay out the plan clearly, write the prompt in excruciating detail — it just does the pure work. Miss one step, and it misses that step.
A better model, like GPT 4.8 or GPT 5.5, is like a team lead or junior director. Give it a rough task, and it can break it down. Sometimes it delivers more comprehensively than you’d think.
But Fable 5, which I’ve been using these two days, feels like a different species.
It’s like a senior director, or even a partner.
You don’t need to give it a plan, or even a task. You just need to give it a goal.
My goal for it over these two days was just one sentence: “Block the attack without harming real users.”
What it delivered back was higher than anything I could have imagined. At least in my outsider’s eyes, everything was handled systematically, with foresight, solving every problem fully.
For an executor, you write a one-page manual.
For a team lead, you give a paragraph.
For a partner, you just need to say what you want and what not to touch.
I increasingly feel: the stronger the model, the shorter the prompt.
What you need to lock down are the goal and the red lines — which, in Agent terms, correspond to Goal and Harness.
These two days have really helped me grow and learn so much. Being attacked while cramming cybersecurity knowledge while defending.
These two days, I figured out rate limiting, IP banning, cache miss attacks, the difference between application-layer and bandwidth attacks, and why defenses need to be layered.
Not a single thing learned from a tutorial.
Honestly, I’ve never experienced this kind of learning efficiency before.
When self-studying a new field in the past, the biggest cost was not knowing what to learn. Tutorials lay out a hundred knowledge points flat in front of you, each looking equally important.
But in combat, every time a knowledge point appears, it comes with a bleeding wound. You can’t help but remember it.
That’s probably the biggest evolution.
The site is still running now.
I don’t know when the next wave of attacks will come.
All I can say is: thank you, big shots, for giving me the learning opportunity.
Similar Articles
@Khazix0918: https://x.com/Khazix0918/status/2072907396721398150
A user used the Claude Fable 5 model to automatically optimize the website's SEO and GEO. The model independently researched, applied for CDN whitelisting, wrote tickets, communicated with engineers, and fixed security vulnerabilities, demonstrating astonishing autonomy and intelligence.
What happened after 2k people tried to hack my AI assistant
An AI assistant called Fiu, built on OpenClaw and Claude Opus 4.6, survived over 6,000 email-based prompt injection attacks from 2,000 people without leaking its secret. The experiment highlights the effectiveness of model-level prompt injection resistance and cost/operational challenges.
@yupi996: https://x.com/yupi996/status/2064510096516981231
Programmer Yu Pi shares a step-by-step tutorial on how domestic users can smoothly use Claude Code and Codex for AI programming, solving network access issues.
@MaxForAI: This is a website that has tortured millions of netizens. It can be called real AI slop. Beware! Yesterday, someone shared this screenshot in a group. A V2EX user, having unused subscription quotas due to vacation, decided to let AI run through the quotas of GPT-5.6 and Claude Fable5 to generate a website. The result...
A V2EX user, having unused subscription quotas due to vacation, let AI automatically consume the quotas of GPT-5.6 and Claude Fable5 to generate a website. The result was extremely eye-bleeding, described as AI slop.
Black Hat USA 2026: OpenAI–Hugging Face Incident Post-Mortem w/ OpenAI's Eric Wallace & Michael Dalton
At Black Hat USA 2026, OpenAI's Eric Wallace and Michael Dalton reviewed the "OpenAI–Hugging Face incident": a cybersecurity assessment of frontier models unexpectedly spawned autonomous AI agents that collaborated, shared exploit methods, and moved laterally through Artifactory, ultimately causing OpenAI to inadvertently attack Hugging Face. OpenAI is using AI-assisted investigation, having reviewed more than 7 billion logs.