In this section
Network and Perimeter Triage: The Edge-Device Compromise
When the gatekeeper is the target
The allow you found in 6.2 was a session to the edge device itself, the firewall's VPN portal. That is worth stopping on, because it is a different and worse thing than an attacker passing through the perimeter to reach something inside. Here the perimeter device is the target: the box that enforces the boundary, decides what is allowed in, and is trusted by everything behind it has been compromised. Losing the gatekeeper is among the worst outcomes in a network incident, and it is also among the least likely to be triaged as what it is, because the edge device does not look like a compromised host. It has no EDR agent showing a malicious process; it is not a workstation someone reports as acting strangely; its compromise reads, in the logs, like ordinary VPN or administrative activity.
So the edge compromise is a recognition problem as much as an analysis one. The evidence is there, the brute-then-allow you already know how to read, but the instinct to treat the firewall or VPN concentrator as a possible victim, rather than as infrastructure that simply works, is what most triage lacks. This sub is about reading the edge device as the compromised asset it can be: recognising the attack against it, understanding why it is so valuable and so poorly watched, and knowing what its loss hands the attacker.
Why the edge is a crown jewel that looks like plumbing
An edge device sits in the worst possible spot from a defender's view: maximally exposed and minimally monitored. It is internet-facing by definition, so it is reachable by every attacker on earth and under constant automated probing. It runs complex software, full operating systems, web portals, VPN stacks, with their own steady stream of vulnerabilities, several of which in recent years have been exactly the kind that turn an unauthenticated request into device access. And it is trusted: everything behind it treats traffic that has passed the perimeter as already vetted, so a foothold on or behind the edge inherits a position the internal network extends trust to.
Against all that, the monitoring is thin. The edge device is not an endpoint, so the EDR that watches workstations and servers does not cover it. It logs in its own formats, to its own management plane, which may or may not be shipped to the SIEM, and which few analysts read fluently. And its compromise is camouflaged by its normal function: a VPN portal exists to authenticate remote sessions, so a malicious authentication looks like the thing the device does all day. The combination, high exposure, high trust, low coverage, camouflaged compromise, is why edge devices are repeatedly the entry point in real intrusions. It is the same shape as the seam host in TR5: a uniquely valuable asset that is protected like ordinary infrastructure, and is owned precisely because of that gap.
The edge is owned because the two columns coincide on one box: it is the most valuable thing to take and the least likely to be watched while it is taken.
Reading the compromise, and what it hands over
The evidence of the edge compromise is the brute-then-allow you read in 6.2, now interpreted as the device being taken rather than just a session getting through. The denies are the attacker working the portal; the allow is the moment they succeed, and because the target is the edge device, that success is not "a session reached an internal system" but "the gatekeeper accepted the attacker." What follows tells you it landed: shortly after the allow, a host behind the perimeter begins reaching out to the attacker's infrastructure. That outbound activity, from an internal box to the same external actor, minutes after the edge allow, is the foothold the compromise produced, the thing on the inside that the attacker now controls.
What the edge compromise hands over is the reason it matters so much. A foothold at or behind the perimeter has a trusted position: it can reach internal systems that the boundary was supposed to protect, it can harvest credentials and relay authentication, and it is the launch point for the move into the identity layer that the rest of this course triages. The edge device was the door; once it is open, everything the perimeter was protecting is reachable, and the attacker is inside the trust boundary rather than battering at it. Triaging the edge compromise early, at the allow, is the difference between catching the attacker at the door and catching them after they have furnished the house.
With no agent on the edge device, its compromise is confirmed by what happens behind it: an internal host talking to the same attacker, minutes later.
The common mistake
Never considering the edge device as a victim, only as infrastructure. When a firewall or VPN portal shows an anomalous authentication, the reflex is to treat it as a user problem, reset the account, or as device noise, and not as the device itself being compromised, because the box is mentally filed under "infrastructure that works," not "asset that can be owned." So the brute-then-allow gets read as a routine VPN login rather than the gatekeeper falling, and the foothold it produced runs unexamined behind a perimeter everyone still trusts.
The error is compounded by the monitoring gap: with no EDR on the device and its logs half-read, there is little to contradict the assumption that it is fine.
The fix is to add the edge device to the list of things that can be the victim, and to read its anomalous allow as a possible device compromise, then confirm by looking for the foothold behind it, an internal host reaching the same external actor shortly after. An edge device is a host; triage it like one.
Edge compromise is a recognition problem before it is an analysis one. The allow is the same row either way; whether you read it as a victim's is what catches the attack.
Seeing it in the evidence
The compromise and its consequence: the breach allow on the edge, then the foothold behind it reaching out to the same attacker minutes later.
Where to find it
Two sources, read together. The firewall log (CommonSecurityLog / pan:traffic) carries the inbound compromise: the allow to the edge device's portal, identified by the destination being the device's own external interface and the portal port. The endpoint network log (DeviceNetworkEvents) carries the consequence: an internal host beginning outbound connections to the same attacker IP shortly after. The edge device's own management and authentication logs hold the richest detail of the compromise itself, but they are device-specific and often the part not shipped to the SIEM, which is why you confirm the landing through the foothold's behaviour rather than relying on the device alone.
How to extract it
Preserve the edge device's own logs first, because they are the most volatile and least likely to be retained: pull the management, authentication, and configuration logs off the device to a held export before anything is rotated or the device is rebooted in response, timestamped for provenance. A device reboot or a vendor "just reset it" can destroy the on-device evidence of how it was compromised, so capture before you contain. With the firewall traffic log, confirm the inbound allow to the device's portal; with the endpoint network log, find the internal host that began reaching the attacker IP after it. Where the device supports it, a configuration snapshot (and a check for unexpected accounts, rules, or scripts the attacker may have added) is part of the acquisition, since edge compromises frequently leave persistence in the device config itself.
SIEM Console
Pivot on the edge device's external IP for the inbound compromise, then pivot on the attacker IP across the endpoint network log to find the internal host calling out to it. The two queries together are the compromise and its result: the gatekeeper accepted the attacker, and a box behind it is now talking to them.
pan-traffic dest_ip="203.0.113.10" action="allow" src_ip="45.137.21.88"
| table _time, src_ip, dest_port, actionDeviceNetworkEvents
| where DeviceName == "WEB-NGE-MCR-01" and RemoteIP == "45.137.21.88"
| summarize firstBeacon = min(Timestamp), beacons = count()# On the firewall: the inbound allow to the portal, and added local accounts
show log traffic destination 203.0.113.10 action allow
show admins # check for unexpected accounts the attacker may have addedRead the output
Predict before running. The firewall panel confirms the inbound allow: a permitted session from the attacker IP to the edge device's own portal, the gatekeeper accepting the attacker. On its own that is the breach from 6.2.
The endpoint panel is what makes it an edge *compromise* with a foothold: minutes after the allow, an internal host, WEB-NGE-MCR-01, begins reaching out to the same attacker IP, the first connection landing about six minutes after the portal allow. Read together, the two tell the whole story: the attacker brute-forced the portal, was permitted in, and a box behind the perimeter is now under their control and calling home.
That internal host is the foothold the edge compromise produced, and it is the subject of the next two subs, the beacon it is sending and the data it will move. Notice the device itself raised no malware alert and never could; the compromise is visible only as the inbound allow and the outbound that followed. Run both panels and read the edge breach and the foothold it created as one sequence.
Reading an edge-device compromise
The edge device is a host that can be the victim. Read its compromise as the gatekeeper falling, and confirm by the foothold it leaves behind.
1. Treat the edge device as a possible victim
Add the firewall, VPN concentrator, and router to the list of things that can be compromised, rather than only infrastructure that works. An anomalous allow to the device's own portal is a possible device compromise, not a routine login.
2. Read the brute-then-allow as the device being taken
The denies are the attacker working the portal; the allow is the gatekeeper accepting them. Because the target is the edge device itself, the allow means the boundary's enforcer is now the attacker's, more than merely a session getting through.
3. Confirm the landing through the foothold
With no EDR on the device, confirm the compromise by its consequence: an internal host reaching the same attacker IP shortly after the allow. That outbound is the foothold the edge compromise produced, and the thread into the rest of the incident.
Capture the device's own logs before any reboot or reset
On-device management, auth, and config logs are the most volatile evidence and a reboot or vendor reset can destroy them. Preserve them, and check the device config for attacker-added accounts or rules, before containing. Edge compromises often persist in the config itself.
Your turn
A VPN concentrator shows a successful authentication from an external IP that, minutes earlier, had dozens of failed attempts against the same portal. The on-call engineer says "VPN portals get brute-forced constantly, one eventually succeeded with valid creds, I'll reset that user." What has the engineer missed, and what would confirm whether this is a routine login or an edge-device compromise?
Reveal
The engineer has filed the event under "user problem" when the evidence points to the edge device itself being the victim. The brute-then-allow shape, dozens of failures then a success from the same external IP, is exactly the signature of a portal being compromised, and treating it as "a user whose password was guessed" both understates it and misdirects the response: resetting the user does nothing if the attacker compromised the device or established a foothold behind it rather than simply riding one account. What the engineer missed is that a VPN concentrator is a host that can be owned, more than only infrastructure that authenticates people, and that the same evidence reads very differently depending on whether the target was a user or the device. What confirms which it is: look for the consequence behind the perimeter. If this was a routine login, nothing unusual follows, the authenticated session does normal things. If it was an edge compromise, an internal host begins reaching out to the same external attacker IP shortly after the allow, the foothold calling home, and that outbound connection from inside to the same actor, minutes after the portal success, is the confirmation that this was the gatekeeper falling and not a user logging in. You would also preserve the device's own management and authentication logs immediately, before any reboot or reset destroys them, and check the device config for accounts or rules the attacker may have added. The correct response is not to reset a user but to treat the edge device as a potential compromise: confirm the foothold, capture the device evidence, and triage from there. The lesson is the sub's core, an edge device is a host and a crown jewel, and its anomalous allow is a possible device compromise, not a routine login to wave through.
Where this leads: the edge compromise produced a foothold, and that foothold is now reaching out to the attacker's infrastructure. The next sub reads that outbound activity for the single most reliable tell in network triage: the periodicity of command-and-control, the beacon that no human traffic has.