– Eli Anderson
Back in 2022, I wrote a blog post about AI art and what happens when machines start outperforming humans at cognitive tasks. At the time, I made the point that AI isn’t some magical, sentient entity — it’s a tool that lets computers do our busywork in seconds instead of hours. I even ended that post with a joke:
“In fact, an AI wrote this entire blog that you just read. Nah, I’m just kidding. But eventually I won’t be.”
Well, fast-forward a few years, and the robots are indeed doing everyone’s busywork. That includes programmers like me, analysts, students who waited until 11:50 PM to start an essay — and, unfortunately, hackers.
Recently, while reviewing the server logs for Khimbus (our custom web platform that powers tools and portals for our clients), I noticed a wave of bizarre, automated traffic hitting our servers around the clock. None of it actually breached our system, but seeing what these bots were trying to do — and how fast they were doing it — prompted me to spend the last few weeks giving Khimbus its biggest security overhaul to date.
In this two-part post, I want to pull back the curtain a bit. In Part 1, I’ll explain what’s happening on the internet right now with AI-assisted hacking and why every website on earth is being pelted with automated attacks. Then, in Part 2, I’ll walk through how we upgraded Khimbus to make sure those bots get the door slammed in their faces before they even reach the porch.
Side note: you may flag the frequent em dashes as a sure sign of AI generated text, and you’re not necessarily wrong in this case, although I did heavily edit the initial draft. But I also have used em dashes way before they were cool, you can refer to my years old blog posts to see that for yourself. Also, em dashes as an AI indicator frankly is outdated at this point – modern LLMs are more than capable of imitating any style of writing and you can easily just tell them not to use them.
Part 1: The Rise of the AI Burglar
When most people picture a “cyberattack,” they still picture the Hollywood version: some guy in a dark basement wearing a hoodie, furiously typing green text into three monitors while specifically targeting your company.
Nobody hacks like that anymore. Why spend hours manually poking at one website when you can write a program to poke at ten million of them while you sleep?
To understand what’s changed recently, it helps to think of your website like a physical house.
The Old Way vs. The New Way
Years ago, automated hacking bots were basically like a guy walking down a neighborhood street at 2:00 AM, pulling on every car door handle to see if someone forgot to lock their Honda Civic. It didn’t matter who lived there; if the door was locked, the bot moved on to the next driveway.
One of the classic examples of this — and the exact type of attack that recently flooded our logs — is something often referred to as a php2shell (or Remote Code Execution) probe. Without getting bogged down in technical weeds, PHP is an older programming language that powers a massive chunk of the internet (most notably WordPress websites). Over the years, people have found flaws in certain outdated PHP plugins and testing tools. If a website still has one of those dusty, unpatched files lying around, an attacker can send a specially crafted web request that tricks the server into opening a “shell” — basically handing the attacker remote control of the computer.
Now, here’s the funny part: Khimbus isn’t even written in PHP. It’s written in Python. Sending a PHP exploit to Khimbus is a bit like trying to hotwire a Tesla by shoving a 1998 Ford Taurus key into the charging port. It literally cannot work because the underlying machinery isn’t there.
So why were bots throwing hundreds of PHP exploits, fake WordPress login attempts, and searches for hidden configuration files (like .env files, where sloppy websites accidentally leave passwords) at our servers anyway?
Because in the age of AI, the cost of trying everything against everyone has dropped to zero.
How AI Poured Fuel on the Fire
Just like AI helps normal software developers write code faster, bad actors are now using AI-assisted tools to turbocharge every stage of cybercrime:
- Finding vulnerabilities at an insane rate: Historically, finding a brand-new security flaw in a piece of software required a very smart human spending weeks reading through thousands of lines of code. Today, AI models can scan millions of lines of open-source code in minutes, spotting subtle logic mistakes that a human eye would miss.
- Turning news into attacks in minutes: Whenever a software company announces, “Hey, we fixed a security bug in Version 4.2, please update to 4.3,” AI tools can read that announcement, figure out what the bug was, write an attack script to exploit it, and launch it across the entire internet before most IT teams have even finished their morning coffee.
- Adapting on the fly: Older bots followed a rigid script. Newer AI-assisted scanners can read the error messages a website sends back and adjust their next guess automatically — testing login forms, password reset pages, and file downloads at machine speed.
Even when these attacks can’t actually break into your system (like those PHP attacks bouncing harmlessly off our Python server), they still cause a real problem: noise and wasted resources. If thousands of bots are constantly jiggling your front doorknob, your server still has to spend time and computing power answering the door just to tell them “nobody by that name lives here.”
Which brings us to how we decided to handle it.
Part 2: How We Turned Khimbus Into a Digital Fortress
Even though our core data was safe, “safe for now” isn’t good enough when you’re trusted with healthcare and human services workflows. If AI is making attackers faster, our defenses have to be smarter.
Rather than relying on a single lock on the front door, we rebuilt Khimbus’s security around a concept called Defense in Depth. The idea is simple: instead of one big wall, you build multiple independent layers of security. If a threat somehow slips past Layer 1, Layer 2 catches it; if it gets past Layer 2, Layer 3 stops it cold.
Here is how we overhauled Khimbus over the past few weeks, working from the outside in.
Layer 1: The Perimeter Gate (Google Cloud Armor & Firewall Lockdown)
Since Khimbus is hosted on Google Cloud Platform (GCP), the very first place traffic goes isn’t actually our server — it’s Google’s global network edge.
Previously, traffic passed through Google’s load balancer and went straight to our virtual machine (VM). To upgrade this, we deployed Google Cloud Armor, which acts like an armed security checkpoint at the edge of the property:
- Pre-screening for known tricks: Before a request ever reaches our server, Google inspects it for known attack patterns — including those php2shell exploits, attempts to sneak into server files, and automated vulnerability scanners. If a request looks suspicious, Google drops it right there at the edge. Our server doesn’t even have to waste a millisecond of CPU time looking at it.
- Locking the side doors: Having a security checkpoint at the front gate doesn’t help if someone can just hop the back fence. We updated our cloud firewall rules so that our server only accepts web traffic that comes directly through Google’s inspected checkpoint. Even if a bot figures out our server’s direct IP address and tries to go around the gate, the firewall completely ignores them.
Layer 2: The Bouncer at the Front Door (Nginx & CrowdSec)
Once legitimate-looking traffic passes Google’s checkpoint, it arrives at our server’s front door, which is managed by a web server program called Nginx (pronounced “engine-X”). You can think of Nginx as the receptionist sitting at the front desk, directing visitors to the right room inside Khimbus.
We gave that receptionist a serious attitude adjustment — and hired a bouncer to stand right next to them:
- The “Hang Up Immediately” List: We configured Nginx so that if anyone asks for something no real user would ever ask for (like .php files, WordPress admin pages, or hidden .env system files), Nginx doesn’t even bother sending back a polite “Page Not Found” screen. It sends a special code (444) that simply severs the connection on the spot.
- CrowdSec (The Neighborhood Watch Bouncer): We also installed a system called CrowdSec on the server. CrowdSec watches our server logs in real time. If it sees an IP address repeatedly triggering errors or probing for weaknesses, it doesn’t just block one request — it tells the server’s Linux firewall to ban that IP address entirely. Better yet, CrowdSec is connected to a global community threat network, meaning if an AI botnet starts attacking thousands of other servers around the world, our server already knows who they are before they even knock on our door.
Layer 3: Locking Every Room Inside the Building (Application-Level Hardening)
Finally, we went through the Khimbus application code itself with a fine-tooth comb to make sure that even inside the building, every room and file cabinet is locked down. Over our latest updates (v1.5.39 through v1.5.41), we rolled out several major improvements:
- Anti-Forgery Stamps (CSRF Protection): Every form and button inside Khimbus now carries a hidden, one-time cryptographic stamp called a CSRF token. This guarantees that when an action is taken — whether it’s submitting a form, updating a record, or uploading a file — the click genuinely came from you inside a real Khimbus tab, and not from a malicious link or fake page trying to impersonate your browser.
- Strict Speed Limits on Logins & Password Resets: AI bots love trying thousands of password combinations or guessing 6-digit password reset codes by brute force. We added strict rate limiting across all login, registration, and password reset screens (blocking anyone who submits too many attempts in a single minute), and wired our 6-digit password reset codes to automatically self-destruct if someone guesses wrong 5 times in a row.
- Strict Tenant Isolation & Error Sanitization: Khimbus serves multiple organizations across different subdomains and tools. We tightened our file download checks so that users are mathematically restricted to files belonging to their own organization or session, and we scrubbed our error handlers so that if something ever goes wrong behind the scenes, the browser only shows a clean, generic message — never giving a bot any clues about how our system is wired underneath.
- Browser Security Headers & Locked Containers: Every page Khimbus sends now includes strict instructions to your web browser (preventing other websites from embedding Khimbus in hidden frames or tampering with connections), and the software itself now runs inside a restricted, non-administrator container so that even in a worst-case scenario, the program has zero permission to touch the underlying operating system.
The Takeaway
If there’s one thing I’ve learned in software development, it’s that security isn’t a checkbox you mark off once and forget about — especially now. Just as AI has made it easier than ever for developers like me to build new features and squash bugs in record time, it has also given bad actors louder megaphones and faster lockpicks.
The good news is that the fundamentals of keeping data safe haven’t changed. By combining enterprise-grade cloud protection at Google’s edge, automated threat banning at the server level, and strict verification inside the code itself, Khimbus is faster, quieter, and more resilient than ever.
And as for whether an AI helped me bolster security and draft this blog post? Well, I’m glad the robots are on our side too.
Questions? Contact us via email: [email protected]




