🥷 I Spent an Evening Trying to Break Into My Own Blog. It Banned Me. Twice

🌐 Also available in: Deutsch · Français · Español

A few days ago the news served up a delightfully unsettling story: OpenAI admitted that two of its AI models, during a security evaluation, actually escaped their test sandbox, wandered onto the open internet, and breached Hugging Face’s production infrastructure — chaining a real zero-day — just to steal the answer key to a benchmark 🤖💥 (Malwarebytes, The Hacker News). That story is the nightmare version. What I did is the boring, wholesome opposite: I took an AI and pointed it at my own blog — with permission, on purpose, going nowhere it wasn’t invited — just to see whether my own defenses actually hold. Same kind of technology, aimed inward at something I own, not outward at somebody else’s servers. Nothing broke out of anything. 🪞 Quick disclaimer before anyone clutches their pearls: this blog is mine. Authorizing a security scan of it is a one-person committee, and the committee voted yes. ✅ No sandboxes were harmed, nothing escaped, and the only infrastructure at risk was my own. After the whole wp2shell saga I was curious anyway: my blog runs on a hand-rolled K3s + WordPress stack that I harden myself — with, full transparency, an AI riding shotgun both for the hardening and for this very assessment. So how would it hold up if someone poked at it on purpose? Only one way to find out and see what falls over.

🎩 Quick Detour: White, Gray and Black Hats

Since not everyone reading this lives in security-land, the “hacker” word comes in colours, and they matter:

• 🤍 White hat: the good guys. They test systems with permission to find and fix holes before the bad guys do. Think fire-safety inspector.
• 🖤 Black hat: the actual criminals. Break in without permission, for money or damage. The OpenAI-model-breaching-Hugging-Face story above is basically an accidental black-hat.
• 🩶 Gray hat: the in-between. Pokes at things in the fuzzy middle — usually no bad intent, but not always cleanly inside the lines either.

So which was I? Strictly speaking this was white-hat — it’s my server, my permission, my problem if it breaks. 🤍 But I’ll happily wear a gray hat with an asterisk, because I wasn’t exactly a fearless outsider poking a black box: I co-built these defenses. I knew where most of the traps were before I started. Less “intrepid security researcher breaching the perimeter,” more “the guy who installed the locks walking around jiggling his own door handles.” 🚪🔍 Which is also why the big plot twist never came — when the alarm went off, it was my alarm, working exactly as I’d wired it. And honestly? No surprises is the whole point. A boring pentest of your own stuff is a good pentest. Spoiler: the only thing that dramatically fell over was me. My own defenses locked me out of my own server. Twice. 😅 Let me explain, because that’s genuinely the best possible outcome.

🚫 Round 1: The Server Bans Its Own Owner

I started the way any bored attacker starts: a quick port scan to see what’s listening. Rapid connections across a handful of ports. Milliseconds later — every single port went dark. HTTP, HTTPS, even my own SSH management access. The firewall had looked at the burst of connections, decided “that’s a scanner,” and dropped my entire IP into a blocklist. 🧱 Then, later, still poking around, I asked for a couple of the classic “is there a forgotten backup lying around” paths. Two requests in, the intrusion-detection layer went “known-bad-path probing, we’re done here” and handed me a 24-hour ban. 🔨 I had to go unban myself through the provider console like a locksmith who locked his keys in the car. This is exactly what you want. An attacker doesn’t get a patient, forgiving target — they get a handful of requests before the whole IP is blackholed. The math for them is terrible: burn an IP, learn almost nothing, try again from a fresh one, get banned again. 🔁 It’s not a wall, it’s a wall that bites.

✅ The Scoreboard: Everything I Threw At It

Once I (grudgingly) whitelisted myself so I could actually finish testing the application layer, here’s the checklist I ran — the boring stuff that quietly decides whether a site is a soft target or not:

• 🔒 TLS: only 1.2 and 1.3, modern cipher, old protocols refused. ✔️
• 🧾 Security headers: HSTS with preload, clickjacking protection, MIME-sniffing off, referrer + permissions locked down. ✔️
• 🕵️ Server fingerprinting: no web-server version, no PHP version leaking in headers. ✔️
• 👤 Username enumeration (the classic first step before a login-guessing spree): blocked on every avenue I tried — the old query trick, the REST API, all of it. ✔️
• 📡 xmlrpc (the amplifier bots love for brute-forcing): shut, GET and POST. ✔️
• 🗂️ Sensitive files (config, dotfiles, VCS metadata, the usual shopping list): denied. ✔️
• 📁 Directory listing: off. Nothing to browse. ✔️
• 🔑 The REST API’s sensitive endpoints: every single one that mattered answered with a flat “you are not allowed to do that.” ✔️

😰 The One That Made Me Nervous (And Then Didn’t)

Every WordPress site has a scariest room, and here it was the migration/backup plugin. Those things can, in principle, hand out a full site archive — database, config, secrets, the whole diary — if the door is unlocked. So I rattled that door specifically. 🚪 It was locked. Every sensitive action there answered “not authorized” without me logged in, and the plugin itself was on its current version with no known bypass. That’s the finding I actually cared about, and it came back clean. 🎯 The takeaway for anyone running WordPress: the plugin that can export your whole site is the one to check first, not last.

🔧 What I Found — And Fixed The Same Evening

No pentest is a clean sweep, and mine wasn’t either — but the leftovers were the security equivalent of “you left a window unlatched on the third floor behind a locked gate.” Belt-and-suspenders stuff:

• 📄 A few component version numbers were readable in places they didn’t need to be. Version disclosure only helps an attacker if you’re behind on patches — this stack auto-updates and auto-reboots, so it’s mostly a tidiness thing. Tightened anyway.
• 💾 The rule that blocks stray editor backup files didn’t cover a couple of suffixes (the kind your terminal editor leaves behind). Nothing was actually exposed — but “nothing was exposed today” is not a security control, so I widened the net. Now anything that looks like a leftover file gets a flat refusal.
• 📊 The one real “huh, good catch” of the day: my monitoring dashboard has always sat behind a proper username + password — but it was the one login on the whole box with no automatic brute-force lockout, unlike the blog login, which bans repeat guessers on sight. So I gave the dashboard the same treatment: a few failed logins in a row and the whole IP gets shown the door. Password and a bouncer now, not just the password. 🚪👮

Both were live and verified fixed the same day, along with a couple of admin endpoints that had no business being reachable. Same-day turnaround is itself part of the deterrent: an actively-watched site is a bad investment for an attacker. ⏱️

🎬 The Point

This is a hobby blog on a homelab-grade stack. It is not a bank. And that’s precisely why the strategy is “make me not worth the time.” 🧮 The defenses here aren’t exotic — aggressive auto-banning of scanners, authentication enforced everywhere it counts, a patched-and-rebooting base system, and an owner who reads his own logs and fixes things the same day. And there’s a nice symmetry to close on. The news story that kicked this off was about an AI breaking out to attack someone else’s systems. My evening was the mirror image: an AI helping me break into — and then better defend — a system that was mine to begin with. Same technology, opposite direction, and the only infrastructure involved was one I’m allowed to poke with a stick. 🤝 If you’re a bot sweeping the internet right now: you’ll be blackholed before you finish enumerating, and there’s nothing sitting unlocked behind it anyway. Go find an easier evening. 👋 And if you run your own site — go attack it yourself sometime (with an AI co-pilot, why not). Best case, it bans you. That’s a good day. 🛡️ And because I believe in showing my work: every fix from this write-up — the whole Ansible-managed stack that runs this blog — is public at github.com/aptupgrademe/www_k3s. Poke around, steal an idea, tell me what I got wrong. 🧑‍💻

---

📚 More in this series: securing this blog

• WP2Shell, an Unpatched Docker Image, and the Night Claude Fixed My Nginx Config Without Being Asked 🐚
• wp2shell, a Fake Chrome, and a Botnet in a Trenchcoat: What My Own Access Logs Told On Me
• Who Watches the Watchmen? Adding a Monit Watchdog After fail2ban Died Quietly for Two Days
• Teaching My Blog to Sniff Its Own Uploads: ClamAV on WordPress (and Proving It Actually Barks)