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. A massive credential exposure campaign dubbed FortiBleed is impacting internet-facing Fortinet FortiGate firewalls and VPN gateways worldwide.

Current reporting suggests 73,000–86,000+ Fortinet devices may be affected across 194 countries, with attackers harvesting verified credentials for administrative and SSL VPN access.

Important clarification:

FortiBleed is not a new CVE or zero-day.

This appears to be a large-scale credential compromise campaign involving:

  • Credential stuffing
  • Password spraying
  • Brute-force attacks
  • Reused / previously leaked passwords
  • Exploitation of older known Fortinet exposures

In other words, this is less about a brand-new vulnerability and more about a dangerous combination of:

  • Weak password hygiene
  • Internet-exposed management interfaces
  • Missing MFA
  • Poor credential rotation

For defenders, this reinforces a hard truth that the firewall is part of your attack surface – It’s not just a defensive tool—it’s also a high-value target.

Immediate actions, I recommend:

  • Rotate all FortiGate admin and VPN credentials
  • Enforce MFA on all remote access
  • Disable internet-facing management where possible
  • Review admin logins for anomalous IPs/geographies
  • Check for unauthorized config changes
  • Patch to latest FortiOS / review Fortinet PSIRT advisories

From an OT perspective, this matters even more.

Many industrial environments still rely on vendor VPN access, jump hosts, and perimeter firewalls to protect critical operations. A compromised edge device could become the initial access point into:

  • Power utilities
  • Manufacturing
  • Water treatment
  • Transportation
  • Critical infrastructure

This is exactly why identity + access security is now just as important as patching.

Read more

Hello All. Most OT deception projects fall into one of two categories: they’re either too simple to fool anyone—or too static to provide meaningful insight.

So, I decided to build something different. Today, I’m announcing AdaptiveGrid — an open-source, adaptive OT honeypot designed to simulate real industrial environments and capture high-fidelity attacker behavior.

Why AdaptiveGrid?

Traditional OT honeypots tend to rely on:

  • Static banners
  • Basic protocol responses
  • Limited interaction depth

The problem? Modern attackers—and even basic tooling—can quickly identify these as fake.

It’s designed not just to look like an OT environment, but to behave like one.

What Makes It “Adaptive”?

At the core of AdaptiveGrid is the idea that deception should evolve during the interaction.

Instead of a fixed response model, the platform:

  • Tracks attacker behavior over time
  • Groups activity into per-attacker cases
  • Scores actions based on intent (e.g., scanning vs. exploitation)
  • Adjusts logging, alerting, and response depth dynamically

This means a simple port scan is treated very differently than:

  • Repeated authentication attempts
  • Protocol-specific manipulation
  • Attempts to access engineering interfaces or project files

Key Features

AdaptiveGrid is designed for both real-world detection and research/demo environments:

High-Interaction OT Emulation

  • EtherNet/IP (CIP), Modbus, OPC UA simulation
  • Emulated controller identities (e.g., PLC-style responses)
  • Realistic engineering workstation behavior

Enterprise + OT Hybrid Lures

  • Fake engineering portals (HTTP/HTTPS)
  • SMB shares for project file access attempts
  • Authentication traps (including credential capture)

Advanced Telemetry & Logging

  • Structured timeline.jsonl per event
  • Full session logging and artifact capture
  • Credential hashing and storage for analysis

ATT&CK-Aligned Detection

  • Automatic mapping to MITRE ATT&CK techniques
  • Clear linkage between behavior and adversary tactics

Burst & Behavior Analytics

  • Detects rapid scanning and brute-force activity
  • Identifies escalation patterns in attacker behavior
  • Use of AI to compile data and provide analysis on behavior

Per-Attacker Case Management

  • One case per attacker (not per event)
  • Full timeline of actions from recon → interaction → exploitation

AdaptiveGrid is designed to complement platforms like Claroty, Nozomi Networks, and Microsoft Defender for IoT—not replace them.

AdaptiveGrid is being released as an open-source project, with a focus on:

  • Transparency
  • Community-driven improvements
  • Realistic OT simulation for defenders, researchers, and educators

Future enhancements will include:

  • Expanded protocol support
  • Deeper controller emulation
  • Integration with SIEM/SOAR platforms
  • Optional AI-assisted alert summarization
Read more