Read Captures as Evidence
A packet capture is a record from one observation point. It can show that a frame or packet crossed that point, but it may not show the originating user, the responsible process, or the meaning of encrypted content. Begin with capture location, start and end time, interface, filter, truncation settings, clock quality, and chain of custody. These details determine which conclusions the capture can support.
Work from broad to narrow. Summarize endpoints, protocols, volumes, duration, and direction before opening individual conversations. Then correlate DNS answers, connection timing, HTTP metadata, TLS metadata, proxy records, endpoint process events, and workload identity. This avoids selecting one dramatic packet and building the whole story around it.
Use a Safe Evidence Vocabulary
Every course network record is offline, synthetic, or sanitized capture-derived metadata. Domain names end in .example or .invalid. IPv4 endpoints come from the TEST-NET ranges 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24. No packet payload or replayable capture is supplied. Learners must stop if a record contains a globally routable endpoint or an unlisted domain.
| Evidence layer | It can support | It cannot establish alone |
|---|---|---|
| DNS | Requested name, answer, timing, resolver path, and repetition | Which process made the request or whether the answer was used |
| Flow | Endpoints, ports, direction, byte counts, duration, and recurrence | Application intent or encrypted content |
| HTTP metadata | Method, host, path category, status, size, and timing when visible | Trustworthiness merely because the protocol is common |
| TLS metadata | Handshake properties, server name when present, certificate context, and session timing | The plaintext request or response |
Patterns Worth Investigating, Not Labeling
- RAT, botnet, or C2 hypothesis: repeated low-volume sessions, a rare destination, or a consistent interval can justify correlation with process and identity evidence. Monitoring, health checks, update agents, and message consumers can look similar.
- Worm hypothesis: one source contacting many peers or services over a short period may indicate propagation, but discovery, inventory, patching, and load testing are common alternatives.
- Web-shell hypothesis: an unusual inbound request followed by a new server-side child process and outbound flow is stronger than any one event. The course represents the request and action with harmless labels only.
- Cryptominer hypothesis: long-lived pool-like sessions plus sustained compute and an unexplained process deserve review. Long sessions are normal for many streaming and messaging systems.
- Cloud or container compromise: combine egress with pod, workload identity, image digest, deployment, and policy records. An address alone does not identify the responsible container.
Encrypted traffic shifts the analysis toward metadata and endpoint correlation. Do not weaken production encryption or deploy interception casually to recover visibility. Decide which application-level audit events can provide the missing context while respecting privacy.
Move From Packet to Testable Hypothesis
- State the observation without intent: who communicated, when, for how long, and how much.
- Add context: expected service, asset role, process, workload identity, change window, and destination history.
- Write a primary hypothesis and at least one benign alternative.
- Name the next evidence that could support or weaken each explanation.
- Choose a proportionate control, such as preserving evidence, isolating one workload, or restricting an unapproved destination.
A good network report survives loss of payload visibility. It explains why the sequence matters, which evidence is missing, and how the proposed detection will be tested against normal software behavior.
Protect Privacy and Evidence Quality
Real captures may contain personal information, authentication material, internal names, application content, and regulated data. Do not upload employer captures to public tools or use them in this course. Sanitization must preserve the relationship needed for learning while replacing identities and content. Record what was transformed so later reviewers do not mistake a sanitized value for original evidence.
Keep original authorized evidence separate, access controlled, and governed by the incident process. The learner works only with the provided derivative JSONL metadata and its documented sanitization rules.
Suggested Study Plan (6 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 1h 26m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1h 11m | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1h 11m | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 1h 15m | A flow summary, a correlated timeline, a three-hypothesis evidence matrix, and a privacy-aware detection and response recommendation. |
| Knowledge check and review | 57 minutes | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: A host connects to the same destination every sixty seconds. Is that enough to call the traffic command and control?
Reveal the defensive reasoning
No. Periodicity is one feature shared by health checks, telemetry, updates, queues, and malicious control traffic. Correlate destination rarity, process and workload identity, bytes, protocol metadata, deployment history, and surrounding endpoint behavior. Record both the C2 hypothesis and legitimate alternatives.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.