What two real incidents taught us about keeping pace with an AI-speed adversary.
Three weeks ago, I wrote that your SOC isn't slow; the fight has simply gotten faster. I ended with a question: what was the first thing your team changed when AI appeared on the other side of that fight?
I didn't expect my own colleagues to prove the point just days later, and in public.
Within days of that post, Gotham engineers were responding to live incidents. Brian Wagner spent a week investigating the NetScaler® attacks and developing detection scripts and mitigations with customers and the broader security community. Pablo Vidal led an investigation into whether our remote-access gateways had been hit before we patched them, moving from the initial alert to a scoped, contained conclusion in under an hour. Meanwhile, the rest of the team was putting these measures in place for our customers.
Brian and Pablo each documented what happened and both accounts are worth reading in full. Together, they show that this faster pace is no longer theoretical. This is what it looked like in practice.
Two Field Reports From the Same Fight
Week one: from Reddit chatter to incident response
On Saturday, September 26, Brian saw Reddit threads about an unpublished NetScaler vulnerability. Organizations were already taking appliances offline, even though the vendor had not yet issued guidance. By Sunday morning, he was working through the problem with Claude: how could we get ahead of it, troubleshoot it, and respond in real time?
What came next was less a support case than a live development sprint. Starting with a published IOC script and the vendor bulletin, Brian built a check script that could run directly on an appliance or analyze collected log bundles offline. Each bundle from our environment and our customers helped improve the script. At the same time, the team built a growing firewall blocklist of attacker infrastructure, sometimes releasing a new version every 10 to 15 minutes.
Then came a second wave: crafted sign-in requests crashing the authentication service and forcing reboots, even on patched gateways. Brian's working theory was that attackers were planting payloads in logs and forcing a reboot to trigger them. The team combined their approach with the vendor's guidance into a single mitigation script: config backup, ACL-based IP blocking, responder policies, and a matching rollback. Appliances stabilized as soon as customers applied it.
Read Brian's full write-up: From Reddit Chatter to Incident Response: A Week Inside the NetScaler Attacks.
Week two: from alert to answer in minutes
Pablo's story picks up where Ken Phelan's Twenty-Three Hours left off. We patched our remote-access gateways on Saturday, and the attackers appeared about 23 hours later. The patch held. But every critical patch now raises the same questions: were we hit before we patched, did anything get in, and did anything phone home?
Pablo answered those questions with an AI assistant connected to firewall management and log APIs through MCP servers. In a single session, it checked every indicator against 30 days of firewall logs, matched the results to the appliance's timestamps, expanded the search to look for earlier reconnaissance, and confirmed that no internal systems had called back out. It also staged block rules linked to the incident and change tickets, then drafted the write-up.
The old way was a couple of hours of manual searching and spreadsheets. This took well under an hour, and checking a new indicator later that day took minutes.
Read Pablo's full write-up: From Alert to Answer in Minutes.
What the Two Weeks Proved
The first post made several claims. These incidents put them to the test.
The patch is not the finish line
In both cases, the vendor fix marked the start of the real work. For Brian, that meant defending against a second wave of attacks. Pablo's hunt was necessary because exploitation can begin before a patch is available, or immediately after it is released.
Ken's Twenty-Three Hours puts a number on it. Mandiant's time-to-exploit was 63 days in 2018 and five days in 2023. Then it went negative: minus one day in 2024 and an estimated minus seven days in 2025.
Attackers are now exploiting vulnerabilities roughly a week before a fix exists. That's less a threat model than a DeLorean. If your process treats "patched" as "closed," you're still working on the attacker's old timeline.
Ken's broader point is that incident response needs to become routine. In many organizations, it is still treated like a red button behind glass: a binder and a retainer that no one has ever used. A better model is a process practiced often enough to feel routine, where a clean result means something because the team knows what a dirty one looks like. Pablo's sub-hour investigation shows what that looks like from the engineer's chair.
Correlation is the job; AI is the accelerant
I argued that log correlation is where AI delivers the most value. Pablo sharpened that point: no single data point was conclusive. Traffic to an IP address on port 443 is ordinary. A command-injection string might come from a scanner. But when those details are matched against the rules that allowed the traffic and no callback is found, they support a defensible conclusion. The AI didn’t make that judgment; it assembled the evidence quickly enough for a person to make it.
AI widens what one person can do
This was the most striking part. Brian describes himself as an infrastructure specialist, yet in one week he was assessing compromise, writing mitigations, and supporting incident response across several organizations. At times, he released a new script version every 10 to 15 minutes. This goes to show that AI isn’t replacing an analyst, but that it can help an experienced engineer operate as a broader defender under pressure.
Guardrails are what make speed safe
In my first post, I said agents without access controls and audit trails are "unsupervised delegation." Pablo's setup is a working answer to that:
- Read-only API accounts for hunting by default
- AI can stage block rules; an engineer verifies and installs them
- Change control still applies in an emergency, with ticket numbers on every object
- Secrets stay in protected storage, never in prompts or notes
- Query limits and retention gaps are stated plainly, so "no results" never masquerades as "no activity"
Brian's mitigation script shipped with a configuration backup and a rollback. Same instinct, different tool: move fast, and make it reversible.
Humans set the direction; community multiplies it
Both accounts lead to the same conclusion. AI handled much of the labor, but people supplied the judgment: deciding which indicators mattered, recognizing when a pattern looked wrong, and weighing what the business could tolerate. Brian's experience also reinforced something I understated in the first post: the value of community. Customers shared logs, peers at M7 Global Partners tested scripts, and independent researchers built one another's findings into public checkers. Attackers share tools; defenders improve their odds when they share information faster.
The irony is real
AI was likely involved in finding these NetScaler vulnerabilities and developing the exploits. The same class of tools helped us detect, scope, and mitigate them within days. Technology does not favor either side; speed does.
The Updated Takeaway
In the first post, I suggested a simple audit: measure how much analyst time still goes to manual triage, static-rule tuning, and copy-and-paste log correlation. Based on the past two weeks, I would add three questions that every security leader should be able to answer before the next critical bulletin arrives:
- Can we run the "were we hit before we patched?" check in under an hour? That means retained logs, connected tools, and a rehearsed routine, not a two-day project.
- Where are our AI guardrails written down? Read-only by default, human approval for changes, rollback on every mitigation, and an audit trail that tells the story on its own.
- Who do we compare notes with? A peer community, a partner, or a researcher network. In a week like the NetScaler attacks, nobody has the whole picture alone.
The attackers changed their pace. Over the past few weeks, I watched my colleagues change ours. The difference did not come from buying a product. It came from experienced people using the right tools, following sensible guardrails, and sharing what they learned.
That leaves the same question, now with more urgency: when the next zero-day hits, how long will it take your team to determine whether you were affected?
If the answer is "longer than we'd like," let's talk. Contact your Gotham Account Manager or email info@gothamtg.com.
NetScaler is a registered trademark of Cloud Software Group.