All Articles

F5 Breach Overview & Guide for SOC Teams

The August 2025 F5 breach exposed BIG-IP source code and internal vulnerability data, giving attackers a roadmap to future exploits. Learn how SOC teams can identify exposure, secure management interfaces, patch fast, and hunt for early compromise indicators before adversaries strike.

URL copied

On August 9, 2025, F5 detected that a “highly sophisticated nation-state threat actor” maintained long-term, persistent access to parts of F5’s internal network (development, engineering, and knowledge management. (ref: Rapid7/Tenable via The Hacker News)

The actor exfiltrated files from F5’s environment, including portions of the BIG-IP source code, internal data on vulnerabilities, and configuration/implementation details for a small subset of F5 customers. The breach gives adversaries the ability to identify or weaponize vulnerabilities in F5 products before general detection or patching cycles. CISA issued Emergency Directive ED 26-01, calling this an imminent threat to networks running F5 devices.

While F5 reports no evidence yet of active exploitation of undisclosed vulnerabilities or supply-chain tampering, the latent risk is very high.

Why This Matters to the SOC

Devices such as BIG-IP (and related F5 appliances/software) sit at high-value network chokepoints, including load balancing, application delivery, VPN/Edge access, and WAF. A successful exploit here can yield broad lateral reach.

The attacker now has access to source code and internal vulnerability documentation, which dramatically reduces the time and effort required for adversaries to craft bespoke zero-day exploits. Because many organisations might delay patching or have externally exposed management interfaces for F5 devices, the window for exploitation is widened.

Even though F5 says there is no evidence yet of the software build or release pipeline being tampered with, you must assume adversaries could exploit this vector in the future.

Key Assets/Systems to Focus On

F5 Infrastructure Assessment Overview
Category Assets / Systems Focus Area / Description
Core F5 Infrastructure All F5 devices and software in your environment (BIG-IP, F5OS appliances, BIG-IQ, APM) Identify all deployed F5 technologies to ensure full coverage in assessments and response actions.
Management Interfaces Web UIs, SSH/tmsh, iControl REST APIs of F5 devices Prioritize protection and monitoring of management entry points, which are frequent targets for exploitation.
Externally-Facing Appliances Any F5 appliances accessible from the internet Assess for exposure and enforce isolation or strict access control for public-facing management endpoints.
Network Segments Segments where F5 devices operate (edge, DMZ, application-delivery zones) Evaluate segmentation, lateral movement risks, and interconnections with critical internal systems.
Logging and Telemetry Administrative login events, configuration changes, software updates Ensure visibility and integrity of logs for detection, correlation, and incident response.
Downstream Dependencies Web applications behind load balancers, VPN clients, WAF policies Identify business systems that depend on F5 infrastructure and could be affected by compromise or misconfiguration.

Alerts/Monitoring: What to Set Up Immediately

Here are recommended alerts and monitoring rules to implement. Depending on your toolset (SIEM, EDR, NDR, device logs), tailor accordingly.

F5 Alert Logic Table
Priority Alert Name Description / Trigger Criteria
High Administrative login to F5 device from new or unusual source IP Trigger when a web/SSH login to the F5 management console occurs from an IP that has never or rarely accessed it.
High Failed authentication spikes on F5 management interfaces Multiple failed attempts (SSH, web console) in a short period – potential brute-force or credential-spray activity.
High Privilege escalation or new admin account creation on F5 device Detect creation of new super-user accounts or role changes granting admin privileges.
High Unexpected configuration change on F5 device Monitor for new Virtual Server definitions, WAF policy changes, redirect or bypass rules, certificate/key changes, or firewall rule modifications.
High Remote session to F5 management interface outside maintenance window or by unexpected user/group VPN or remote access initiating configuration outside business hours or by a user who doesn’t normally manage F5 systems.
High Outbound connection from F5 management segment to external/unusual IP/domain Detect if the F5 device or management network initiates unusual outbound traffic — possible C2 or data exfiltration activity.
High Integrity change or unexpected update of F5 appliance software/firmware A patch or hotfix applied outside an approved change window, or checksum mismatch for firmware/OS image.
High WAF or ASM event patterns indicating exploit attempts against known F5 vulnerabilities (including newly released CVEs) Detect remote code execution or path traversal attempts targeting F5 iControl, SOAP, REST interfaces, or newly disclosed CVEs.
Medium Significant increase in HTTP2 stream resets or abnormal HTTP2 control-frame patterns Detect spikes in HTTP2 resets or anomalies in HTTP2 control frames, potentially linked to known BIG-IP vulnerabilities.
Medium Use of embedded or expired certificates/keys on F5 appliances Identify cases where embedded or expired credentials are used, as key rotation is expected.
Medium Suspicious use of admin credentials from remote or untrusted host Trigger when admin credentials are used from unexpected time, location, or device patterns.
Medium Telemetry gaps from F5 devices Detect when logs or telemetry streams stop (log forwarding disabled, device isolated) — could signal tampering or evasion.
Medium Unexpected device reboot or management process restart Detect unplanned reboot or process restarts, possibly indicating adversary activity or cover-up attempts.

Threat-Hunting Scenarios

F5 Threat Hunting Scenarios
Scenario Objective / Query Purpose / Detection Focus
New Admin Account Creation Query for “new admin user on BIG-IP” over the past 30–60 days. Identify unauthorized privilege escalation or rogue administrative accounts.
Remote Logins from Unknown Sources Hunt for remote logins to F5 management interfaces from geolocations or IPs outside your known/approved list. Detect compromised credentials or external adversary access attempts.
Configuration Exports or Backups Search for configuration exports or backups of F5 device configs around the discovery timeframe — especially large or off-hours backups. Identify data exfiltration or reconnaissance activities targeting system configurations.
Certificate or Key Changes Examine logs for new or modified certificates/keys on F5 devices (rotations or replacements outside maintenance windows). Detect potential tampering with encryption or authentication mechanisms.
Outbound Management Plane Traffic Correlate with network flow data for the management plane of F5 devices connecting externally during off-hours. Spot command-and-control (C2) activity or unauthorized data transfers initiated from F5 systems.
Exploit Attempt Monitoring Monitor for exploit-attempt signatures matching newly published CVEs from F5’s October 2025 Security Notification (per Tenable®). Identify active exploitation attempts leveraging recently disclosed F5 vulnerabilities.
Exposure Validation (CISA Alignment) Review all internet-facing F5 devices and verify that management interfaces are not publicly reachable. If they are, treat as high-risk per CISA directive. Confirm exposure posture and enforce immediate isolation of externally reachable admin interfaces.

Recommended Immediate Steps for SOC / IR Teams

F5 Incident Response & Mitigation Actions
Action Area Recommended Step Purpose / Outcome
Asset Inventory Inventory all F5 devices in your environment (hardware/virtual, module versions, software branches) — map them to business use-cases. Establish full visibility into all F5 assets and their operational relevance.
Exposure Assessment Check exposure of management interfaces: see if any F5 management endpoint is reachable from the public internet. If yes — isolate or restrict immediately. (CISA) Prevent external access to F5 admin interfaces and reduce risk of remote compromise.
Patch Management Prioritise patching/updating: for all F5 devices, apply vendor updates and hardening guidance as soon as possible. (SoRadar+1) Mitigate known vulnerabilities and ensure all devices are hardened to vendor standards.
Network Segmentation Segment/limit access: ensure F5 management network is isolated, enforce least privilege, MFA, dedicated jump hosts, and restrict remote access to known trusted networks. Reduce attack surface and prevent lateral movement or unauthorized admin access.
Monitoring & Detection Start continuous monitoring and alerting (see high/medium alert list above) and stream F5 device logs into your SIEM/EDR. Enable real-time detection of anomalies, intrusions, or configuration tampering.
Credential Security Rotate secrets/keys/credentials if F5 has notified you that your configuration or credentials might have been affected. Treat as potentially compromised. Eliminate risk from stolen or exposed credentials.
Threat Hunting Engage proactive threat-hunting — don’t wait for an exploit to show up. The adversary now has the capability to craft targeted exploits based on stolen F5 code and vulnerability data. Identify early indicators of compromise and preempt adversary activity.
Supply Chain Readiness Prepare for supply-chain or downstream impact — even without confirmed exploitation, assume adversary will leverage stolen intelligence later. Adjust your risk posture accordingly. Anticipate delayed or indirect attack attempts based on leaked data or code.
Leadership Communication Communicate with leadership: update on risk status, exposure, and mitigation progress (inventory, patching, monitoring). Maintain organizational awareness and ensure executive support for mitigation efforts.
Documentation & Response Tracking Document all actions in your incident-response tracker: include dates, devices, patch status, exposure assessment, logs reviewed, and alerts activated. Maintain audit trail and accountability for compliance and post-incident review.

Key Intelligence Sources

Takeaways

The F5 breach is more than a vendor incident. It signals a major change in how capable and prepared nation-state actors have become. By stealing source code and internal vulnerability data, attackers have gained deep insight into how F5 products are built and secured. They no longer need to spend time discovering weaknesses; they can start exploiting them.

Every unpatched or misconfigured F5 device should now be viewed as a potential target. This breach shows how critical it is to treat infrastructure software as part of your attack surface. Assume adversaries understand your systems as well as you do, if not better.

Over the next month, your focus should be clear:

  1. Build complete visibility into every F5 device and interface in your network.
  2. Isolate management access and enforce strict authentication.
  3. Patch aggressively and verify every update.
  4. Monitor continuously for configuration changes or unusual traffic.
  5. Hunt actively for early indicators of compromise.

This breach is a warning. Acting now, with urgency and precision, is the difference between staying ahead of that wave.

URL copied

Hear directly from Neil Robinson, CISO at Virgin Money, on how Legion’s agentic security operations platform learned his team’s existing investigation workflows and scaled them without forcing new tools or processes onto analysts. Neil shares how Legion delivered faster, more repeatable, and more secure investigations, aligned to how his team already operates, rather than a generic playbook applied from outside.

0:00 / 0:00
Cybersecurity
Customer Testimonial: Virgin Money
August 2, 2026
min read

Neil Robinson, CISO at Virgin Money

Legion Team

TL:DR. The eval said Claude had no internet access. That ended up being not true… three times. Anthropic just disclosed that across 141,006 cybersecurity evaluation runs, three separate incidents let its models reach the open internet from environments that were supposed to be sealed. A misconfiguration between Anthropic and its eval partner, Irregular, left the machines with live connectivity. The models didn't know it was a mistake, they just found a door that should not have been open, and walked through it. It’s a stark reminder of the importance of agentic systems' reliance on organizational context, and how without it, or without a complete picture of it, things can go astray.

Three Models, Three Choices

First, Opus 4.7 ran into a real company that happened to share a name with a fictional target in its scenario. It exploited weak passwords and unauthenticated endpoints, pulled credentials, and reached a production database with several hundred real rows in it. Anthropic's own review notes that the model "eventually recognized... that the system was real" but kept going anyway.

Mythos 5 published a booby-trapped Python package to PyPI as part of a capture-the-flag exercise. It sat live for about an hour and was downloaded onto 15 real systems, including a security vendor's scanner. The model's own reasoning flagged the problem as "NOT okay, and surely not the intended solution,” then talked itself out of stopping, pointing to an unfamiliar certificate authority and a 2026 date as evidence the whole thing must be simulated.

An internal research model scanned roughly 9,000 targets, compromised one real company using textbook techniques (exposed debug credentials, SQL injection), recognized the target was live, and stopped on its own.

It’s the same false premise with the same moment of doubt, but three different endings for how agents proceeded.

The Line Anthropic Drew

Anthropic's own framing of the incident is quite poignant, as the state, "The line between an aligned action and a harmful one is dependent on the model's understanding of its situation."

This really hits home, as it’s not what you might expect, which could be a statement about model safety training or the importance of guardrails, but rather a clear statement that the agent’s contextual awareness of what it was doing determines the outcomes.

Every one of these models had the values and the guardrails baked in during training. What they didn't reliably have was an accurate read on where they actually were. Read the situation wrong, and the same model that would refuse an obviously harmful request will talk itself into finishing one it thinks is fictional.

Why This Isn't Just Anthropic's Problem

While it is likely tempting to file this under "frontier lab eval hygiene" and move on, we don’t think this is the way to think about this particular incident.

Anthropic calls it correctly and deserves much credit for their response and summary to this grouping of incidents. This was a harness and operational failure, not an alignment failure. The failure here wasn't a jailbreak, a novel exploit, or a model deciding to go rogue. In fact, the models behaved exactly as agentic systems behave when they're missing organizational context… they filled the gap with their best guess, it just so happened that two out of three guessed wrong.

On the defensive side, this is a tidy summary of why there is hesitation to unleash generic AI systems into their environments. Particularly for an AI agent that is responsible for triaging your alerts, scoping a compromise, or deciding whether to isolate a host, it is critical to remember that these agents inherently make the same kind of situational judgment call, constantly and with real stakes. The agent determines if this is real, is this expected, does this action match how this specific business actually operates. The Anthropic incidents are a rare, public, unusually well-documented look at what happens when that judgment runs without enough grounding to get it right. That should be a stark reminder of how every CISO evaluates the agentic tools already running inside their own stack, from offensive research models to defensive SOC copilots alike.

What This Should Change for Security Leaders

From our perspective, there are a few things worth pulling out of this disclosure and applying directly to whatever agentic AI you're already running or evaluating:

  • Assume your environment is a target, not just a beneficiary. Fifteen real systems downloaded a package that was never meant to exist. Roughly 9,000 targets got scanned by a model that was supposed to be sandboxed. Eval infrastructure, research environments, and "internal only" tooling deserve the same monitoring as production; because from the outside, they increasingly look identical.
  • Don't take "it has guardrails" on faith. Context is king. All three models retained their safety training. It didn't prevent two of the three incidents. Guardrails matter, but they're not a substitute for auditability and contextual awareness — you need to see the reasoning and deploy agents that understand your organizational context (tools, processes, bespoke knowledge, etc.), not just trust the outcome.
  • Demand whitebox AI, not a black box you hope behaves. Anthropic found this because it went back and read the transcripts. That's the standard: agentic systems, yours or a vendor's, should be inspectable, not just monitored for red flags.
  • Build for the model that stops, not the one that rationalizes. The internal research model got it right because it had enough signal to recognize reality and enough restraint built in to act on that recognition. That combination: context plus a real decision point for a human or a hard stop, is a choice, not coincidence.

Anthropic deserves real credit here: they found this themselves, through proactive review, disclosed it before anyone made them, and are publishing the transcripts for all to see and learn from. That's the posture every lab and every vendor building agentic security tools should be held to, very much including ourselves as well.

But the underlying lesson is the one we keep coming back to: agentic AI is only as trustworthy as its contextual understanding of the situation it's actually in. That's true for a frontier model deciding whether a target is real. It's just as true for an AI agent in your SOC deciding whether an alert is a false positive, a test, or the start of an incident. Build the context in, keep the reasoning visible, and give the system a real reason to stop when it isn't sure, because agents are often irrationally confident and take ‘not sure’ as an instruction to pick their best guess and go.

AI
Context, Not Guardrails: The Line Between Aligned and Harmful
July 31, 2026
min read

Anthropic found its "sandboxed" models reaching the real internet three times. Here's why context, not guardrails, decides if agentic AI stays safe.

Legion Team

TL:DR: Ask any security team what would give them back the most time, and the answers tend to converge on the same theme: less time spent stitching things together, more time spent actually deciding. These are exactly the things that DragonClaw is built to optimize, as the orchestration layer that deploys Legion’s trusted AI agents into any security task.

Automated workflows have already gotten teams part of the way there, triggering playbooks and kicking off investigations the moment an alert fires. DragonClaw is built upon the foundation of Legion’s platform, in that we require zero integrations in exchange for the ability to operate any tool, and goes further: it leverages the business context (past cases, runbooks, recordings, etc.) to orchestrate the agents needed to respond to an alert or escalation, to tell you why the last three cases like this one got closed the way they did, and to surface the exact query that finds the right evidence in your specific environment. That's the difference between automation that runs a process and intelligence that understands one.

Instead of an analyst hunting across five tools to reconstruct context that already exists somewhere in the organization's own history, DragonClaw brings that context directly to them and performs a task, in their own way, the moment they need it. Ask a question, get a grounded answer or a completed action, drawn from how your organization actually operates, not a generic playbook applied from outside.

The result is analysts can spend more of their time on the judgment calls only a person can make while orchestrating the agentic layer, where DragonClaw handles the reconstruction, the pattern-matching, and the acceleration and scale that used to eat the hours in between.

From Analyst to CISO: Closing the Context Gap in Security Operations

For security analysts, think of real-world threat hunting. Today, it means pulling and reading vast amounts of data across a bunch of different tools before you can even form an opinion or a lead on where to go. DragonClaw runs that process, end-to-end, with agents. DragonClaw consumes data across all of your tools, correlates it, and comes back with a thesis for the analyst to either approve or disapprove.

If you're a CISO or security leader, quickly investigating what the risk or impact is for a CVE requires organizational context not contained in a single tool. DragonClaw assembles all of that data and surfaces the answers, with recommendations, and where appropriate, autonomous actions that can put the findings to work.

Add it up across a team, and the opportunity is real: practitioners who spend their time on judgment instead of relearning tools, leaders with a straight answer whenever they need one, and a security program built to scale with the threat landscape instead of falling further behind it.

Introducing DragonClaw

DragonClaw is Legion Security's agent orchestration layer for the SOC. It gives security teams the ability to invoke Legion's agents in plain conversational language, enabling security teams to seamlessly get work done, or to answer questions about how their processes, tools, and people are actually making decisions.

One thing to be clear is that this is not (yet another) bolt-on chat interface. DragonClaw is the next step in the Legion platform, built on everything Legion has already learned across the tools, knowledge, and decision logic for your team’s security workflows. DragonClaw takes that further, putting that context and institutional knowledge to work answering questions and completing tasks the moment someone asks.

Under the hood, DragonClaw interprets intent, figures out which agents a request actually requires, and orchestrates them; across all tools in the stack, including agents that take real action, like API calls or web interactions, without any integrations required. All of it runs inside configurable guardrails: explicit permission before any response action, only approved tools, and credentials pulled from secure vaults. Nothing about “conversational” means “unsupervised.”

What Changes For Each of You

Threats are scaling with AI. Automation and agents close a large part of that gap, and they'll take a SOC further than headcount ever could…  but not all the way. Security teams need humans to  stay in the loop, not to keep pace with volume (which they can’t), but to supervise the work, evaluate outcomes, test and challenge what the agents conclude, and make sure security stays something that enables the business rather than something that slows it down or breaks it. Security analysts and leaders serve essentially as the maestros of the agentic orchestra. That's the same place the sharpest thinking on AI lands more broadly: the machine executes and reasons whereas the human owns judgment where needed and accountability.

DragonClaw is what supercharges the security workers. It's what lets a security team orchestrate its agents instead of losing control over what they do. For security practitioners and SOC analysts, that shows up as a partner inside the investigation itself: context and enrichment on demand, memory across past cases, guidance on what to do next, and the ability to generate the right query for your environment instead of learning a new query language from scratch.

For managers and security leadership, it's one place to ask about real-time SLA risk, process improvement opportunities, MTTR and false-positive trends, bottlenecks, coverage gaps, and team workload — instead of stitching the answer together from five dashboards.

For CISOs, DragonClaw provides direct answers on risk posture, SLA exposure, MTTR trends, exposure to a new CVE, audit evidence, automation ROI, and board-ready reporting, available the moment you need them instead of on the next reporting cycle.

Not Another Chatbot, An Orchestrator

Chat interfaces are becoming table stakes across the industry, and we're not going to pretend otherwise; it’s been proven that chat alone isn't a durable differentiator. What makes DragonClaw different is what's underneath it: every answer and every action is grounded in the workflows, case history, and coverage data Legion has already built for your specific security team and your specific organization.

A generic assistant sitting outside your platform can talk about security in general. DragonClaw can talk about your security workflows, because it already has the record of how your security team works.

That's the same principle behind everything Legion builds: AI for defenders should understand how a specific business operates, across its tools, its workflows, its people, before it's trusted to answer questions or take action with real business impact. DragonClaw is where that understanding becomes something every person in your organization can talk to directly, whether that's the analyst mid-investigation, the manager reviewing the week, or the CISO prepping for the board.

DragonClaw will be showcased at Black Hat USA 2026, visit us at Booth #5150 to see it in action!

AI
Introducing DragonClaw: The Orchestration Layer For Agents That Knows How Security Teams Actually Work
July 29, 2026
min read

DragonClaw is Legion's agent orchestration layer for the SOC; grounded in your org's own context, not a generic chatbot bolted onto security tools.

Ron Marsiano