A network connection recorded at the endpoint answers a question that a process tree alone cannot: once a program started, who did it talk to, and how. That record ties four things together, which program opened the connection, what remote host it reached, over what port and protocol, and with what timing and volume. Read as a set, those fields let a defender tell the constant background hum of ordinary software updates and cloud services apart from a flow that does not belong. The craft is not memorizing port numbers; it is knowing what conversations a given machine is supposed to have, so that an unexpected one stands out.
Tying a connection back to a process
The most valuable thing about network evidence collected on the endpoint, rather than only at a firewall, is that it can be attributed to the exact program that opened the socket. A firewall log might show that a machine spoke to a remote address; the endpoint record can add that a particular application, launched by a particular parent, under a particular account, is the one that did it. That attribution is what turns a raw connection into a story. An outbound flow from a mail client to a mail service is unremarkable. The same destination reached by a general-purpose interpreter that a document just spawned is a different sentence entirely, and it connects directly to the ancestry reasoning in Processes, Parents, and Command Lines .
Direction matters too. Most endpoints spend their day making outbound connections to services their users chose, and only a small, well-understood set of programs should ever be listening for inbound connections. A workstation that suddenly begins accepting inbound sessions, or a laptop initiating connections to another internal machine it has no reason to contact, has changed shape. Pairing the connection with the process that owns it is the single habit that most improves network triage, because it moves the question from “is this address bad” to “should this program be talking to anything at all right now.”
Ports and protocols as expectations, not verdicts
Ports and protocols describe what kind of conversation is happening, and their defensive value comes from expectation. A given machine has a normal repertoire: encrypted web traffic to known services, name-resolution lookups, time synchronization, a handful of business applications. When traffic appears on a port that machine never uses, or when a protocol shows up where it has no business, the anomaly is worth a note. Equally telling is the mismatch case, where the port suggests one kind of service but the actual protocol riding on it is something else, a common way for unwanted traffic to try to look ordinary by hiding inside a port that firewalls usually leave open.
None of this is a verdict on its own. Encrypted traffic to an unfamiliar host is not proof of anything; it is the normal state of a web that encrypts nearly everything, which is precisely why remote-host reputation and destination context matter more than the mere presence of encryption. The useful move is to hold the port, the protocol, the destination, and the owning process together and ask whether that combination fits the machine’s job. Egress controls and name-resolution logging make these expectations enforceable and visible, a topic covered in Egress Filtering and DNS Logging and in DNS and Domain Hygiene for Defenders .
Why beaconing is a story about timing
Some of the most useful network evidence is not about any single connection but about the rhythm of many. Automated software that phones home tends to do so on a schedule, and a defender who plots connections over time can sometimes see a heartbeat: small, regular contacts to the same destination at steady intervals, often at times when no person is using the machine. That pattern, frequently discussed under the umbrella of command-and-control behavior, is interesting precisely because it is so unlike human-driven traffic, which is bursty, irregular, and tied to working hours.
Reading timing well means resisting two temptations. The first is to treat every periodic connection as sinister, when in fact a great deal of legitimate software beacons on a timer, checking for updates, syncing files, reporting telemetry, and renewing sessions. The second is to ignore rhythm entirely and look only at destinations. The signal lives in the combination: a regular cadence, to a destination the machine has no business reason to contact, opened by a program that should not be initiating outbound traffic. The conceptual mechanics are laid out in Command-and-Control Concepts , and the flip side, large or unusual outbound transfers, in Exfiltration Paths .
Toy example
Imagine a fictional architecture practice, Cedarline Studio, whose designers use a laptop pool and a shared render server named Quarry. A defender reviewing endpoint telemetry notices that one laptop, belonging to a drafter named Amara, is making a small outbound connection to the same unfamiliar remote host every eleven minutes, always on a port the studio’s software never uses, and the connection is owned by a lightweight helper process rather than any application Amara opened.
Nobody calls it an attack yet. The defender writes the narrowest true statement: “Amara’s laptop contacted host X on port Y every eleven minutes between 1:00 and 4:00 in the afternoon; the owning process is a helper with no clear business purpose; the owner has not been asked.” Then the benign explanations get their turn. Is this a software updater or license check on a timer? A cloud-sync agent? A monitoring tool the studio deployed and forgot about? Each is checkable against the studio’s asset inventory and change records, and each would push confidence one way or the other. The steady cadence plus the unexpected port plus the odd owning process is what makes the note worth keeping, and every detail here is invented.
What evidence matters?
The strongest network evidence pairs the connection with the program that opened it: the owning process and its ancestry, the remote host, the port and protocol, the direction, and the timing and volume of the flow. Timing turns single events into patterns, and volume distinguishes a tiny periodic check-in from a bulk transfer that might mean data leaving. Name-resolution records add context by showing which name a program asked for before it connected, which is often more meaningful than the numeric address it ended up at.
Evidence is most useful when it is timestamped, attributable to a named source, and reproducible from stored records rather than recalled from memory. A screenshot of a connection list helps a responder remember a moment; exported endpoint and resolution logs, the asset owner’s account of what they were running, and the machine’s expected-destination baseline let someone else reach the same conclusion later. Because these records have to already exist when a question arises, retention decisions matter, which is the subject of Logs: What to Keep and Why . Keep claims narrow and confidence explicit: “this destination is unexpected for this machine” is provable, while “data was stolen” needs volume, content, and access evidence to support it.
Common mistakes and false positives
A frequent error is treating an unfamiliar remote address as guilt by itself. The modern internet routes a single service across many rotating addresses and content networks, so a destination no one recognizes is often just a normal cloud provider. Another is reading a port number as if it guaranteed a protocol, when unwanted traffic specifically tries to ride familiar ports to blend in. A third is collecting enormous volumes of connection data without first deciding which question it is meant to answer, which buries the interesting flows under the ordinary ones.
Benign software is astonishingly chatty. Update services, telemetry agents, cloud-sync clients, content-delivery networks, and session-keepalive mechanisms all produce periodic connections to unfamiliar-looking hosts, and remote-management and backup tools legitimately move large volumes on schedules. A false positive resolved carefully still pays off: it sharpens the machine’s expected-destination baseline, documents an owner’s normal workflow, and tightens the alerting so the next genuine anomaly is easier to see. The paired failure modes remain panic, which brands every unknown host an intruder, and dismissal, which explains away a genuinely odd flow because “everything talks to the cloud now.”
What to do next
Match the response to confidence and stakes. For a low-confidence oddity, confirm the destination and the owning program with the asset owner and compare against the machine’s expected-traffic baseline before doing more. For a flow with several aligned indicators, an unexpected port, an unfamiliar destination, a steady beacon, and a process that should not be initiating traffic, preserve the endpoint and resolution records, open a ticket, and consider whether the machine should be isolated while the question is answered, following the approach in Endpoint Isolation and Rejoin Planning . Write observations and conclusions in separate sentences so a later reader can tell them apart.
If a transfer is live and looks like data leaving, do not improvise on the machine. Preserve evidence, follow your incident-response plan, communicate through approved channels, and bring in qualified responders. When you are learning rather than responding, keep the scenario fictional, with invented hosts, users, and toy data, and focus on building better questions rather than reproducing adversary behavior.
How this guide was made
This page is defensive education built from public frameworks and openly available guidance, used for orientation rather than as a compliance checklist. Its examples are deliberately fictional and avoid operational detail so the guide stays safe to learn from. It makes no claim to certification, legal advice, compliance, incident-response authority, or complete coverage of the subject.
Official references
The MITRE ATT&CK Enterprise Matrix catalogs the network-based techniques, including command-and-control and exfiltration, that give connection evidence its meaning. The NIST SP 800-61 Rev. 3: Incident Response Recommendations place that evidence inside a calm analysis process, and the CIS Critical Security Controls v8 describe the network monitoring and port-management safeguards that make endpoint connection data trustworthy. Read all three as orientation, not as certifications of readiness.
Related guidebooks
Pair this with Processes, Parents, and Command Lines and Suspicious Process Indicators to connect a connection back to the program that opened it, and with Logs: What to Keep and Why so the flows you want to study are still recorded. When network activity accompanies a burst of local file changes, File Entropy and Mass-Encryption Clues helps read the two signals together.
