Objective 1.2 · Lesson 1 of 2

Reason from host and network indicators

Indicators point towards questions. They become useful when you compare them with expected behaviour and seek independent evidence that could support or disprove your interpretation.

Establish what changed and for whom

An anomaly is a departure from an appropriate baseline, not an automatic verdict of compromise. Compare a device with its own recent activity and with similar devices performing the same role. A developer workstation, backup server, and reception tablet have different expected processes, destinations, and traffic volumes. Maintenance windows and newly deployed software can also change the baseline.

Record what you actually observed before naming an attack. Include the time window, asset identity, affected account, measurement, and baseline used. Then list plausible benign and malicious explanations. High CPU usage could reflect a scheduled calculation, a software fault, or unauthorised computation. Process ownership, installation history, and outbound connections help distinguish these possibilities.

Use network patterns to guide the next question

One host contacting many ports or destinations may be performing enumeration. Repeated small outbound connections may indicate automated check-ins, but monitoring agents also behave periodically. Traffic on an unexpected port is worth examining because port numbers are conventions, not proof of an application’s identity. Protocol details and process attribution provide stronger context than the port alone.

A newly observed device may be rogue, newly purchased, or an existing asset with a changed address. Correlate DHCP, switch, wireless, and inventory records before assuming it is an intruder. For possible exfiltration, compare transfer volume, destination, timing, user activity, and data access. An outbound transfer establishes movement; it does not by itself prove sensitive data left.

Read host behaviour as a sequence

A process name or digital signature is only part of its identity. Inspect the executable path, parent process, account, command line, start time, and resulting file changes. Living-off-the-land binaries and scripts use legitimate system utilities for unintended purposes. A trusted utility launched by an unusual parent to access sensitive files deserves attention even when its signature is valid.

Look for connected changes: newly installed software, a persistence-related configuration change, collection of documents into an archive, and an unfamiliar outbound destination. Each adds context, but avoid filling missing steps with assumptions. Compare the sequence with deployment records and authorised tasks. Preserve the relevant evidence before removing software or changing configuration, because remediation can erase the explanation.

Keep these points in mind

  • Baseline by role and context rather than treating all assets alike.
  • A port, signature, or process name cannot establish intent alone.
  • Corroborate sequences and preserve evidence before altering the host.

Pause and practise

A workstation sends a large archive after running a signed shell utility. Name a malicious hypothesis, a benign alternative, and two discriminating checks.

Show a worked response

The archive may represent data collection for exfiltration, or it may be an approved support bundle. Check the parent process and command context, then compare destination ownership and the export’s contents or classification with the support request. A signed shell does not settle intent; retain uncertainty until the evidence distinguishes the cases.

Next lesson →
← Module overview