Hunting the Edge: Lessons from the F5 Breach

Why continuous hunting + smart use of your data > dumping all netflow logs to your SIEM

By the time F5 disclosed its August 2025 breach, the story had already calcified into headlines: source code stolen, a sophisticated nation-state actor, a CISA directive, patch immediately. Public commentary suggests the dwell time may have extended beyond a year. For those of us who live in telemetry and hypotheses, the real question is not how the attacker got in. It’s what we could have seen if we had been looking the right way.

F5 confirmed that attackers accessed its internal corporate environment and stole portions of BIG-IP source code and vulnerability information. There’s no evidence of build-pipeline tampering or supply-chain compromise. The operational impact was significant enough for CISA to issue Emergency Directive 26-01, ordering federal agencies to verify their F5 devices. When that level of directive drops, the blast radius is real.

I’ve spoken about continuous hunting (more on that in a future post), but for the time being; let’s define continuous hunting as the near-real time identification and conviction of anomalous behavior as suspicious, malicious or benign. With that in mind, if we had been hunting continuously inside that ecosystem, what would we have seen?

Edge Devices Are Easy to Ignore

Edge devices are the quietest members of the network family. They route, balance, terminate TLS, and keep packets moving. They generate oceans of data but very little signal (yet do consume a disproportionate amount of SIEM logs). In most modern intrusions involving network appliances (F5, Citrix, Fortinet, Palo Alto) the pattern repeats. The attacker exploits the control plane, establishes persistence, exfiltrates configuration data, and lives quietly in the management layer until someone upgrades or reboots.

If we were watching continuously, early signs were probably visible. Rare administrative logins stand out first. Edge appliances have stable administrator patterns. A new source IP, a different region, an odd hour. Configuration exports often follow because attackers like to save before they steal. Then there’s control-plane egress. The management interface should talk inbound, not out.

None of this requires machine learning. It requires collection, baselining, and curiosity.

What Compromise Looks Like and Why This Went Unnoticed

Imagine the sequence through a hunter’s lens. Foothold: a credentialed login appears at an odd hour from a source outside the change-control list. Recon follows with configuration enumeration, bursts of tmsh or iControl REST calls that touch modules rarely used together. Persistence gets established through a new local admin or SSH key. Exfiltration shows up as encrypted outbound traffic from a host that usually stays silent. Cleanup attempts look like truncated logs, timestamp resets, missing audit entries. Each stage alone looks ordinary. Together, they tell a story.

Our telemetry map doesn’t match our attack surface. We instrument endpoints, SaaS, containers, and APIs well enough. The edge paradoxically remains half blind (remember that comment about the logs?) typically because of operational oversight. Infrastructure teams own the devices, and their logs rarely flow into the SOC. Storage limits push filtering so aggressively that what remains is enough to prove uptime, not enough to prove innocence. Because these boxes are labeled security infrastructure, network defenders treat them as trusted. Attackers see them as privileged and unmonitored.

Getting Smarter About Network Telemetry

Most organizations think about network telemetry as an all-or-nothing choice. Either you capture full packet data and drown in storage costs, or you collect nothing and hope your endpoint tools catch everything. While there’s (some) merit in the second approach, almost all of us default to the first. This eats up budget, compute and throughput. The good news is, you can build effective detection for edge infrastructure without bankrupting your logging budget, you just have to be deliberate about what you collect and why.

Start with inventory (and by this I mean the real inventory). Not the asset management spreadsheet that IT updates twice a year. List every F5, Citrix, Fortinet, and Palo Alto device. Include the test boxes that someone spun up three years ago for a project that got cancelled.

Get the version and patch levels, management IPs, admin users, and who actually logs into these things. This needs to live somewhere that gets updated automatically. A CSV file becomes obsolete the moment you save it. Configure remote syslog or API streaming into your SIEM or log aggregation platform. Yes, even if you have to fight with the network team about it. Even minimal normalization of these logs creates detection value.

Now baselining…this is where most teams give up because it sounds hard. It’s not hard, it’s just work. Collect a month of normal administrative activity. Plot logins per day, command types, source IPs. Build simple distributions. Once you know what Tuesday at 2pm looks like for your edge infrastructure, deviations become obvious. An admin who logs in every weekday at 9am showing up at 3am on Sunday stands out. Commands that usually happen one at a time arriving in bursts of fifteen become questions.

On to identity correlation, which is vital and we’re wont to skip. Map every local admin credential to an actual human being or to documented automation. Every single one. If you find credentials that are orphaned or ambiguous, that’s your first hunt right there (trust me, I’ve used this)…go figure out what they’re for. If you can’t connect a credential to a person or a service account with a documented purpose, you’ve found something that shouldn’t exist. I’ve seen organizations with dozens of local admin accounts on their edge devices that nobody can explain. That’s not operational drift, that’s a control failure.

Network flow data is where you can get detection value cheaply. Full NetFlow is expensive and noisy. You don’t need every flow record from every device. You need directional breadcrumbs from management networks.

A few specific firewall logs can tell you when a management interface starts behaving wrong. The device that should only receive SSH connections from your jump box suddenly resolving public DNS? Weird. Making outbound HTTPS to AWS S3 or Azure Blob Storage? Investigate immediately. You don’t need deep packet inspection. You don’t need to reassemble sessions. You just need to know that directionality changed.

Sampled flow data works fine for this. One in every hundred packets gives you enough signal. Simple egress summaries from your border firewalls work. Even just monitoring DNS queries from management VLANs catches a lot. Most management interfaces should have predictable outbound patterns: NTP, maybe some specific update servers, DNS to internal resolvers. Anything else is anomalous.

Outbound traffic from management networks is also important. I mean it. In a well-configured environment, your F5 management interface should basically never initiate outbound connections. When it does, that’s the kind of signal that should wake someone up. Not literally, don’t page people at 2am for a single event, but it should go into a high-priority queue that gets reviewed first thing in the morning.

Budget constraints are real, and everyone has them. Prioritize visibility this way: authentication logs first, command or API logs second, flow metadata third, and only then consider packet capture. Authentication logs tell you who. Command logs tell you what. Flow metadata tells you where. You can catch most compromises with just those three layers. Packet capture is expensive and most of the time you don’t need it until you’re already in incident response mode.

How About a Practical Example?

As a visual learner, here’s a table that should hopefully provide some context/direction about how to evaluate and use network telemetry.

Rule of thumb: collect just enough directional metadata to prove whether a management interface ever talked to the internet.

And now on to a practical example of a low-cost hunt that actually works. Take your firewall logs from management network segments. Group outbound connections by destination over a rolling 30-day window. Any new destination in the last seven days that wasn’t in the previous 23 days gets flagged for review.

That’s the whole query. It catches C2, exfiltration staging, and reconnaissance traffic. The false positive rate is manageable if you tune it for your environment. Yes, sometimes a new update server appears. Yes, sometimes an admin fat-fingers a configuration and the device tries to reach something weird. But those are quick to triage and the signal-to-noise ratio is good enough to be useful.

Authentication logs are even simpler. Pull your authentication logs from all edge devices. For each user account, calculate the set of source IPs used in the last 90 days. Alert when any account authenticates from an IP not in their historical set. Tune it by allowing geographic proximity if your admins travel (within say 50 miles is probably fine), but the core logic is straightforward. New source IP means new question. This catches credential theft, compromised jump boxes, and attackers pivoting from other parts of your network.

Actually, let me back up on that authentication one because it’s worth expanding. The 90-day window matters. Too short and you get flooded with false positives from legitimate admin behavior. Too long and you miss attackers who are patient enough to establish a pattern. 90 days seems to be the sweet spot for most environments I’ve worked with, but you might need to adjust based on how often your team rotates, how many admins you have, and whether people work remotely. The point is to establish a baseline that’s stable enough to be meaningful but fresh enough to catch anomalies.

You also want to exclude known-good sources from triggering alerts. Your jump boxes, your bastion hosts, your VPN concentrators if that’s how admins connect. Whitelist those. But be careful about the whitelist. Keep it small. Every entry is a place an attacker can hide if they compromise that source first. Note; do not whitelist entire /24 networks “because that’s the admin subnet”…that’ll open up a whole can of worms for lateral movement from a compromised admin workstation.

The automation piece matters but not the way vendors pitch it. You don’t need AI-powered behavioral analytics that costs six figures and requires a data science team. You can start with cron jobs and SQL queries. Schedule hunts to run weekly. Query for logins from new source IPs. Look for admin commands outside business hours. Check for configuration exports. Alert on any management interface egress that isn’t on your whitelist. These queries are simple. What makes them valuable is running them consistently and actually reading the results.

What I’m describing is not revolutionary, rather some tactical blocking and tackling. But most organizations aren’t doing it because edge devices fall into this weird gap between network operations and security operations. Network teams treat them as appliances that just work. Security teams treat them as out of scope because they’re not endpoints. The result is that nobody owns the problem of hunting on them.

You don’t need exotic telemetry or expensive tools. You need consistent collection, basic baselining, and the discipline to actually look at what you’re collecting. Most organizations already have 70% of the data they need sitting in syslog servers or SIEM platforms. They just aren’t asking it the right questions.

Document what normal looks like for your edge infrastructure. Write it down. Put it in version control. Review it quarterly. This sounds boring and bureaucratic but the organizations that recover fastest from breaches are the ones that can point to documented baselines and say “here’s what changed.” Everyone else is guessing under pressure while executives ask why nobody noticed.

What This Breach Actually Taught Us

As we wrap, I believe this breach was never just about F5, it’s about telemetry misuse. People either store everything or they store just enough data for compliance, not detection. The edge exposes that imbalance. Infrastructure isn’t invisible, it’s just a strange no-mans land of operational ambiguity and a deluge of telemetry. So you’re stuck with either ‘finding that needle in a stack of needles’ while also figuring out whose actually going to push a patch. How do we solve this problem? Treat edge devices like endpoints: they have credentials, run code, and hold trust.

And what about continuous hunting? I’d posit it beats periodic review. The adversary that lived inside F5 moved slowly because fast attacks trigger alerts. Slow attacks require someone (or something) to be looking for patterns over time.

More on the reclassification of edge devices. Feed their logs (using some of the tricks we outlined above) into analytics pipelines as everything else. Close the loop between operations and hunting. Network teams see maintenance logins, while hunters understand dwell time. Together those views are greater than the sum of their parts.

The meta-point? Telemetry is still your source of truth, and if you build hunts to trigger meaningful signals not only will you get faster MTTD, but early warnings while what’s happening in your environment is still a pattern, not a headline.

Stay secure, and stay curious my friends.

Damien