In this section
Network and Perimeter Triage: The Perimeter Attack Surface
The evidence that was there the whole time
Replay the incidents you have already triaged in this course. In TR2 you read a suspect sign-in. In TR5 you read a service principal authenticating from an attacker IP. Each time, the evidence you worked from was an identity event, the sign-in, the token, the grant, and each time that event was the moment the attack surfaced in the logs you happened to be watching. But the attacker did not begin at the sign-in. They began on the wire: scanning the perimeter, brute-forcing an edge device, landing a foothold, beaconing out to their infrastructure, moving data. By the time the identity logs caught the attack, the network had already recorded hours of it, in the firewall log, in the egress flows, in the connection events on the host. Nobody read it, because network telemetry is treated as noise to be filtered rather than evidence to be triaged.
That is the gap this module closes. The perimeter is both an attack surface in its own right, edge devices get compromised directly, and a feeder into everything else: the network foothold is what becomes the identity incident you already know how to triage. Reading the network layer is the discipline of catching the attack at the point where it is earliest and least disguised, on the wire, before it puts on the costume of a legitimate sign-in. This sub is about what that layer is, what it can and cannot tell you, and why its evidence usually predates the identity evidence by hours.
The identity alert is real, but it is the tail of the chain. Everything that produced it sat on the wire, recorded, for over two hours before it fired.
The perimeter is a target and a doorway
Two things make the perimeter worth triaging, and they are different. First, the edge devices themselves are targets: the firewall, the VPN concentrator, the router, the proxy. These are internet-facing by definition, they run complex software with their own vulnerabilities, and they are routinely under-monitored because they are seen as infrastructure rather than as the high-value attack surface they are. An attacker who compromises the VPN portal or the firewall management plane has a foothold at the edge of the network, often with the access and trust those devices are granted internally. The edge device is a crown jewel that looks like plumbing, the same pattern you saw with the seam host in TR5.
Second, and this is the spec's framing for the module, the perimeter is a doorway: the network compromise is a feeder for the identity attacks the rest of the course is built around. The attacker rarely wants the firewall for its own sake. They want what the foothold behind it gives them: a position to harvest credentials, to relay authentication, to reach internal systems, and ultimately to cross into the identity layer where the valuable access lives. So a network incident is not a separate category from the identity incidents you have triaged; it is frequently the earlier chapter of the same story. Triaging the network well means recognising the doorway before the attacker has walked all the way through it.
It is worth being precise about why the edge is so often the weak point, because it shapes what you look for. Edge devices frequently sit outside the telemetry the rest of the estate enjoys: they are not endpoints, so the EDR does not cover them; they log to their own formats that may or may not reach the SIEM; and their compromise often looks like ordinary administrative or VPN activity rather than malware. The result is that an edge compromise can run for a long time generating evidence that exists but is never read, the firewall faithfully logging the brute-force and the anomalous allow while no one is correlating them. That combination, high value, low coverage, evidence-present-but-unread, is exactly what makes the perimeter both the attacker's preferred entry and the triage opportunity this module trains you to take.
The edge gets attacked for itself and as a way in. Either way, the network evidence sits earlier in the timeline than the identity evidence you would otherwise wait for.
What the network layer can and cannot tell you
Before triaging network evidence you have to be honest about what it is. The network layer records connections: who talked to whom, when, on what port, using what protocol, and how much data moved. That is a great deal, it is enough to see a brute-force, a beacon, an exfiltration, an anomalous allow, but it has hard limits, and reading network evidence as if it told you more than it does is the fastest way to a wrong call. It generally does not tell you the content of the traffic, because most of it is encrypted; it does not tell you intent, only behaviour; and it does not by itself tell you which user or process was behind a connection, only which host. The network sees the shape of the conversation, not its words.
That boundary is why this is triage and not forensics, and why the module ends (6.8) on what the network cannot tell you. For now, hold the two halves together: the network layer is rich enough to catch an attack early and cheaply, and limited enough that confirming what you caught usually means pivoting to host or identity evidence. A network triage that respects both halves is fast and accurate; one that ignores the limits invents certainty the evidence does not support.
Read network evidence for what it gives, and stop where it stops. The limits on the right are why a network finding is a lead to confirm, not a verdict on its own.
The common mistake
Treating network telemetry as noise to be filtered down to alerts, rather than evidence to be triaged. Firewall and proxy logs are enormous, mostly benign, and most teams tune them aggressively or ignore everything that is not already an alert, which means the early, undisguised evidence of an attack, the brute-force pattern, the periodic beacon, the anomalous allow, scrolls past unread while everyone waits for the identity alert that comes hours later. The mirror mistake is over-reading the network: concluding from a connection alone what the attacker intended or who was behind it, when the traffic is encrypted and the log shows a host, not a person. Both errors come from not knowing what the layer is. It is evidence, so triage it; it is limited evidence, so do not ask it for what it cannot give. The network half of an incident is the earliest and cheapest to catch and the easiest to over-interpret, and reading it well means doing both: looking, and knowing the limit of what you see.
Seeing it in the evidence
The thesis, in one query: the network recorded the whole attack hours before it reached identity. The same incident, in two worlds, with the network world first.
Where to find it
The perimeter firewall log (Palo Alto / Fortinet / equivalent, often surfaced as CommonSecurityLog in a SIEM, or pan:traffic in Splunk) records every permitted and denied session at the edge: source, destination, port, action, and volume. Endpoint network telemetry (DeviceNetworkEvents) records the same connections from the host's side, with the initiating process. The identity layer (SigninLogs) records the authentication that the network foothold eventually feeds. The three are one incident; the firewall and host network evidence sit earliest, the sign-in latest.
SIEM Console
Perimeter and host-network logs are high-volume, so the triage move is to pivot on a single indicator, here an external IP, and let the firewall and endpoint network evidence show the attack's shape across the whole window. The same IP that appears in a late identity alert will usually have a long earlier history on the wire; that history is the part most triage never opens.
pan-traffic (src_ip="45.137.21.88" OR dest_ip="45.137.21.88")
| stats count, min(_time) AS first_seen, max(_time) AS last_seen by actionCommonSecurityLog
| where SourceIP == "45.137.21.88" or DestinationIP == "45.137.21.88"
| summarize events = count(), firstSeen = min(TimeGenerated), lastSeen = max(TimeGenerated) by DeviceAction# On the firewall: filter the traffic log to the suspect peer
show log traffic direction equal both source 45.137.21.88
show log traffic direction equal both destination 45.137.21.88Read the output
The firewall query returns the attacker IP's full history at the edge: a cluster of denied inbound attempts, a permitted inbound session that should not be there, and a run of permitted outbound sessions, the first seen hours before anything else. Now compare that first-seen time to when the same attacker IP appears in the identity layer: the svc-netops sign-in lands more than two hours later. That gap is the entire point of the module. The network recorded the brute-force, the breach, and the beaconing while the attack was still on the wire and undisguised; the identity layer only caught it once the attacker had what they came for and used it to authenticate. Every later sub reads one part of this network record, the firewall actions, the beacon, the exfil, the edge compromise, and then ties it back to the identity layer it fed. Run the panel and read the timestamps: the network half came first.
Your turn
A sign-in alert fires: a service account authenticating from an external hosting IP, flagged high risk. The identity team triages it as an anomalous sign-in, resets the account, and prepares to close. Before they do, what should the existence of an external attacker IP in a sign-in prompt you to check, and why might the most important evidence be hours older than the alert?
Reveal
The external attacker IP in the sign-in should prompt you to check the network layer for that same IP, because a service credential being used from external hosting infrastructure rarely originates in the cloud, it usually means the credential was captured somewhere, and "somewhere" is often a network foothold that the perimeter and host-network logs recorded earlier. So you pivot on the IP across the firewall log and the endpoint network telemetry, looking for its history before the sign-in: inbound attempts against the edge, an anomalous allow, outbound beaconing, a data transfer. The reason the most important evidence is older than the alert is that the identity event is the last step of a longer chain, not the first. By the time a captured credential is used to authenticate, the attacker has already breached the perimeter, established a foothold, and very likely beaconed and exfiltrated, all of which the network recorded hours earlier and none of which the sign-in alert reflects. Resetting the account addresses the symptom the identity team can see while leaving the foothold that produced it untouched, so the attacker simply captures or uses another credential. The correct move is to treat the sign-in as the visible tip of a network incident and triage backward into the network evidence, where the attack is earlier, less disguised, and still shows the foothold you actually have to contain. The lesson is the module's premise: the network half of an incident usually predates the identity half, and the IP is the thread that connects them.
Where this leads: you have the shape of the problem, the network as an early, rich, limited evidence layer that feeds identity. The skill that unlocks all of it is reading the most basic network record there is without dismissing it as noise. The next sub goes to the most fundamental network evidence there is and the skill the rest of the module builds on: reading the firewall log, where allow, deny, and alert each mean something different, and where the row that does not belong is the breach.