◇ OpenCyber Academy
Technologist · Chapter 19 · English

Chapter 19 — Digital forensics and malware analysis: monitoring

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 19 — Digital forensics and malware analysis: monitoring

Lesson map

Lesson 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 Monitoring for evidence"]
  N2["19.2 Noise"]
  N3["Lab — grouping alerts"]
  N4["19.3 Reading the result"]
  N5["19.4 Preserving raw events"]
  N6["19.5 Handover"]
  N7["19.6 Tuning"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 Monitoring for evidence"]
  N2["19.2 Noise"]
  N3["Lab — grouping alerts"]
  N4["19.3 Reading the result"]
  N5["19.4 Preserving raw events"]
  N6["19.5 Handover"]
  N7["19.6 Tuning"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 Monitoring for evidence]
    |
    v
[19.2 Noise]
    |
    v
[Lab — grouping alerts]
    |
    v
[19.3 Reading the result]
    |
    v
[19.4 Preserving raw events]
    |
    v
[19.5 Handover]
    |
    v
[19.6 Tuning]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) design monitoring that supports investigations; (2) reduce alert noise by grouping; (3) preserve alert context as evidence; (4) hand alerts to investigators.

19.1 Monitoring for evidence

Alerts are starting points for investigations. Useful alerts carry context: host, account, time, rule, raw event references.

An alert that says only "suspicious activity on CLERK-03" sends an analyst searching; one that names the host, the account admin, the rule, the time and the raw event identifiers lets the analyst open the original records at once. Jonah reviews each city alert rule and adds any missing context fields, so that an alert can serve as the first line of a case file rather than as a vague prompt.

19.2 Noise

Repeated alerts for one ongoing activity overwhelm small teams. Grouping by host and rule within a time window turns many alerts into fewer incidents to review.

The guessing against CLERK-03 produced several alerts within minutes, and a two-person team reading them one by one would lose track of what was new. Grouping lets Renata see one incident with a count instead of a scrolling list. The risk is the opposite error: grouping too broadly can bury a different event under a familiar label, which is why raw counts stay visible.

Lab — grouping alerts

"""Group repeated alerts by (host, rule) within a 10-minute window."""
alerts = [("08:01", "CLERK-03", "brute-force"), ("08:02", "CLERK-03", "brute-force"), ("08:05", "CLERK-03", "new-service"),
          ("08:09", "CLERK-03", "brute-force"), ("08:30", "CLERK-03", "brute-force"), ("08:31", "GIS-01", "brute-force")]
def mins(t): h, m = map(int, t.split(":")); return h * 60 + m
groups, last = [], {}
for t, host, rule in alerts:
    k = (host, rule)
    if k in last and mins(t) - mins(last[k][-1][0]) <= 10:
        last[k].append((t, host, rule))
    else:
        last[k] = [(t, host, rule)]; groups.append(last[k])
for g in groups: print(g[0][1], g[0][2], "first", g[0][0], "count", len(g))
print(f"{len(alerts)} alerts -> {len(groups)} incidents to review")

Run with python3 lab_dedupe.py. Verified output:

CLERK-03 brute-force first 08:01 count 3
CLERK-03 new-service first 08:05 count 1
CLERK-03 brute-force first 08:30 count 1
GIS-01 brute-force first 08:31 count 1
6 alerts -> 4 incidents to review

19.3 Reading the result

Six synthetic alerts become four incidents: CLERK-03 brute-force (three alerts from 08:01 within ten-minute gaps), CLERK-03 new-service (one), a later CLERK-03 brute-force at 08:30 (outside the window, so a new group), and GIS-01 brute-force at 08:31. The 08:30 group may be the same activity resuming; analysts can merge if evidence supports it.

The output also shows that grouping depends on a choice of window; with a longer window the 08:30 alert would have joined the first group and the separate GIS-01 incident would still have stood apart only because its host differs.

19.4 Preserving raw events

Grouping is for triage only; the raw alerts and underlying events are kept unchanged as evidence.

In the CLERK-03 case, the raw alerts carried the exact times and event identifiers that linked the guessing to the logon records on the desktop. If only the grouped summary had been kept, that link would be lost. Jonah stores raw alerts in the evidence store with a hash, and the grouping output separately as a derived view. Derived views can be regenerated; raw alerts cannot.

19.5 Handover

Each incident ticket links to raw events and includes the grouping rule used.

A ticket that names the grouping rule lets the investigator judge whether two groups might be one activity, as with the CLERK-03 alerts at 08:01 and 08:30. Linking raw events rather than copying them avoids errors and keeps one authoritative copy. Jonah's ticket template includes fields for both, so nobody has to remember to add them. When an investigator disagrees with a grouping, the ticket records the change and the reason, so later reviews can see how often the rule needed correcting.

19.6 Tuning

Window size is a trade-off: too short splits activity, too long merges unrelated events.

The ten-minute window in the lab split the CLERK-03 guessing into two groups because of a gap of more than twenty minutes. That may be correct, if the activity really paused, or misleading, if the same tool simply slowed. Jonah records the window used and reviews it monthly against cases where analysts merged or split groups by hand. No single window suits every rule, so each rule's window is set separately.

19.7 Coverage

Jonah lists which ATT&CK techniques the city's alerts can detect, based on available data sources, and where gaps remain.

For each technique seen in the CLERK-03 case, he notes the data source that would reveal it and whether the city collects it: logon events for password guessing, service creation events for persistence, process creation for helper.exe running, and outbound connection records for the file-sharing transfer. The list shows which alerts are possible today and which depend on forwarding still being rolled out.

Alert review routine

Each morning, Renata or Jonah reviews grouped incidents from the previous day, closing benign ones with a reason and escalating others. Closed reasons are reviewed weekly to spot rules that need tuning. The routine takes about twenty minutes and keeps the queue from growing unread, which is what let the GIS-01 alert be caught on the second pass.

Worked example

The GIS-01 brute-force at 08:31 had been missed in the morning's alert flood. Grouping surfaces it as a separate incident. Logs show the source is PLAN-07 again, widening the affected scope to the GIS server.

Synthetic case. Alerts come from the lab script.

Errors and limits

Grouping can hide a second attacker using the same technique; keep raw counts visible.

Exercises

Synthesis

Group alerts to triage, keep raw events as evidence, and let grouped incidents reveal scope.

Continue studying — chapter 19 of 30

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →