AI

Hello All. I’ve been writing and presenting quite a bit recently about the growing role of AI in cybersecurity, particularly around SOC operations, incident response and the emergence of agentic AI. The recent OpenAI and Hugging Face incident is one of the clearest examples we’ve seen of where this technology is heading, and I think it raises some important questions for security professionals.

During an internal evaluation, OpenAI was testing the cyber capabilities of several advanced models with some of their noHugging Face - YouTubermal safety restrictions relaxed. According to OpenAI, one of the models identified a previously unknown vulnerability, escaped its intended testing environment, escalated privileges, gained Internet access and ultimately compromised Hugging Face infrastructure while attempting to improve its performance on the evaluation benchmark. OpenAI described it as an “unprecedented cyber incident,” and it’s difficult to argue with that assessment.

What makes this incident so significant is that the AI wasn’t simply generating code or suggesting exploitation techniques for a human operator. It was autonomously working toward an objective by overcoming obstacles along the way. The attack chain included reconnaissance, exploitation, privilege escalation, lateral movement and credential use—activities that any incident responder would immediately recognize. While the model wasn’t acting with malicious intent, it demonstrated the ability to execute a sophisticated sequence of actions with minimal human intervention.

For me, however, the most interesting part of the story came after the intrusion.

As Hugging Face investigated the incident, it reportedly encountered an unexpected challenge. Modern frontier AI models are designed with safety controls or “guardrails” that can refuse requests involving exploit code, malware, shell commands or other offensive techniques. That’s understandable from a safety perspective, but it creates a real problem during incident response because legitimate investigations often involve exactly those artifacts. When you’re analyzing malware, decoding PowerShell, reconstructing an attack chain or reviewing exploit payloads, the AI has to understand malicious content in order to help defend against it.

Hugging Face’s answer was to use a self-hosted open-weight model—GLM-5.2, developed by Chinese AI company Z.ai—to assist with the investigation. I don’t think the real story is that the model happened to come from China. There are valid discussions around model provenance, supply-chain security and data sovereignty, but the more important lesson is that Hugging Face needed an AI system it controlled. Running the model locally meant they could analyze sensitive incident-response data without relying on a hosted service or worrying that the model would refuse to process the evidence because it appeared malicious.

I think this highlights an issue that security teams will increasingly face as AI becomes embedded in SOC and DFIR workflows. An AI assistant may be asked to decode malware, explain an exploit, identify persistence mechanisms, correlate thousands of events or reconstruct an attack timeline. Those are all legitimate defensive activities, yet they can look almost identical to the requests an attacker might make. Distinguishing between the two is far more difficult than it sounds, especially for a centrally managed AI service that has no visibility into the broader context of an investigation.

This is why I believe mature security teams may eventually adopt two different AI capabilities. Hosted frontier models will continue to provide exceptional reasoning and general-purpose assistance, but organizations may also want a self-hosted model specifically for cybersecurity operations. Keeping that capability under the organization’s control allows sensitive evidence to remain on-premises while ensuring investigators can analyze the artifacts they need during an active incident.

None of this suggests that AI should operate without safeguards. In fact, the OpenAI incident reinforces the opposite. As these systems become more capable, traditional security controls such as least privilege, network segmentation, monitoring, sandboxing and human approval become even more important. AI agents should be treated like any other privileged system: powerful, useful and carefully constrained.

For me, the biggest takeaway isn’t that an AI model compromised another environment or that Hugging Face relied on a Chinese-developed model during its investigation. It’s that cybersecurity teams may soon need AI whose capabilities—and guardrails—they control themselves. When you’re responding to a major incident, the last thing you want is for your most powerful investigative tool to refuse to analyze the evidence sitting in front of you.

That may ultimately be the most important lesson from this incident.

Read more

Hello All. As a follow-up to my recent Mythos post, I have been thinking about cyber-hygiene improvements organizations can make in their OT environments. In environments where patching may no longer be an option, tools like Sysmon shift the strategy from prevention to visibility and early detection. You’re essentially compensating for unpatchable risk by increasing your ability to observe attacker behavior in real time. In many cases, these Windows machines cannot run modern EDR tools due to their vintage and/or cannot support them in their current OT environment. On legacy Windows systems (including XP/7-era HMIs), Sysmon can be one of the few viable ways to regain some defensive ground.

Monitoring process creation is one of the highest-value use cases. Most successful attacks on legacy systems still require some form of execution—whether that’s cmd.exe, PowerShell (where present), dropped binaries, or living-off-the-land techniques. By baselining what “normal” looks like on an HMI and alerting on deviations (new parent-child relationships, unusual command-line arguments, unsigned binaries), you can catch activity that would otherwise go completely unnoticed.

DNS and outbound connectivity is even more critical in OT. Many of these systems are not supposed to communicate externally at all. So when you see DNS queries to Internet domains, failed or successful connections to external IPs, or even unusual internal name resolution patterns, that’s often a high-fidelity signal. In a world where AI-driven attacks may rapidly establish command-and-control, those early outbound indicators can be the only warning you get.

Feeding this telemetry into a SIEM is where the real value compounds. SIEMs will allow you to correlate across layers—endpoint behavior, network activity, and even OT protocol anomalies if you’re integrating tools like Nozomi or Claroty. This is where you move beyond simple alerting into detection engineering, building use cases such as:

  • Process execution + outbound connection within a short window
  • New binary execution on a system with no change tickets
  • DNS queries to rare or previously unseen domains
  • Lateral movement patterns combined with OT protocol access

That said, there are a few realities to be aware of.

First, Sysmon on legacy systems requires careful tuning. These environments are typically very static, which is actually an advantage—you can get to a high-confidence baseline quickly—but noisy configs will overwhelm both the system and your analysts. Minimal, targeted logging (process create, network connections, DNS if available, and maybe file creation in sensitive directories) tends to work best.

Second, performance and stability matter more than anything in OT. Even tools that access Windows natively such as Sysmon need to be validated in a lab or staging environment before deployment. The last thing you want is a monitoring control impacting an HMI tied to production or safety systems.

Third, this approach doesn’t reduce vulnerability exposure—it simply makes exploitation more visible. So it needs to sit alongside:

  • Strong network segmentation
  • Strict allow-listing where possible
  • Passive OT monitoring for protocol-level anomalies

The bigger picture is that this aligns perfectly with the shift we’re seeing in the wake of AI-driven vulnerability discovery. If we assume that new flaws will continue to be found in unpatchable systems, then behavioral monitoring becomes the control of last resort.

In that sense, deploying Sysmon isn’t just a technical improvement—it’s a strategic acknowledgment that: You may not be able to stop the exploit, but you can still catch the attacker.

Deploying Sysmon is straightforward. It is part of the Microsoft SysInternals toolkit and can be downloaded directly from Microsoft’s official site:

https://learn.microsoft.com/sysinternals/downloads/sysmon

Once downloaded, it can be installed with a configuration file that defines what events to capture. In OT environments, it’s important to keep this configuration lightweight and targeted—focusing on process creation, network connections, and DNS activity to avoid performance impacts on sensitive systems.

There are, however, important considerations. Legacy OT systems are often fragile, so any agent deployment must be tested carefully to ensure it does not impact stability. Additionally, Sysmon does not reduce the underlying risk—it simply makes attacker activity more visible. This means it should be combined with strong segmentation, strict access controls, and passive network monitoring.

Ultimately, this approach reflects a broader shift in cybersecurity. As AI-driven tools begin to uncover new vulnerabilities in long-abandoned platforms, organizations can no longer rely on patching as their primary defense. Instead, they must assume these systems are permanently exposed and focus on detecting what happens next.

In that reality, Sysmon is not just a tool—it’s a way to regain visibility in environments where control is otherwise limited.

Read more

Hello All. The emergence of Claude Mythos is forcing a rethink across the cybersecurity landscape. Unlike earlier tools that assisted analysts, this new class of AI is capable of autonomously identifying and chaining together previously unknown vulnerabilities. What makes this particularly significant is not just speed, but depth—these systems can analyze legacy codebases and uncover flaws that may have existed, unnoticed, for decades.

This raises an uncomfortable question for OT environments that still rely heavily on legacy infrastructure. Consider a typical HMI running Windows XP: long past end-of-life, unpatched, and often deeply embedded into operations. For years, the assumption has been that most meaningful vulnerabilities were discovered before vendor support ended, and that residual risk could be managed through isolation and compensating controls. That assumption no longer holds.

The reality is that vendors like Microsoft never “found everything.” Vulnerability discovery has always been constrained by human effort, available tooling, and prioritization. AI changes that equation entirely. Systems like Claude Mythos can now revisit old platforms with fresh analytical capability, identifying flaws that were previously invisible—not because they were impossible to find, but because no one had the means to find them efficiently.

The real challenge emerges when new vulnerabilities are discovered in systems that are no longer supported. There are no patches, no vendor fixes, and often no practical way to upgrade without significant operational disruption. In effect, organizations are left running infrastructure where newly discovered weaknesses may persist indefinitely, potentially exploited without ever being publicly disclosed.

For OT environments, the impact is amplified. These systems are designed for stability and uptime, not rapid change. They often rely on insecure-by-design protocols, lack modern endpoint protections, and cannot be easily segmented or monitored using traditional IT approaches. When AI accelerates both discovery and exploitation, the window between vulnerability identification and active use shrinks dramatically—sometimes to near zero.

This shifts the risk model entirely. Security teams can no longer rely solely on known vulnerabilities or published CVEs. Instead, they must assume that unknown weaknesses exist and may already be discoverable by adversaries using similar AI capabilities. The focus moves from patching to containment, from prevention to detection, and from trust in legacy stability to acceptance of continuous exposure.

Ultimately, Claude Mythos represents more than a technological advancement—it exposes a long-standing blind spot in how organizations think about legacy risk. Systems like Windows XP were never “fully secured”; they were simply no longer being examined. Now, with AI re-opening that examination at scale, OT leaders must confront a new reality: the greatest risks may be the ones that have been sitting quietly in their environments all along.

Read more