Chapter 6 — Digital forensics and malware analysis: controlled evaluation
Lesson map
Lesson 06 published. Map, example, EX026.
flowchart TD
N0["Learning outcomes"]
N1["6.1 The question"]
N2["6.2 Rotating logs"]
N3["Lab — retention under different rates"]
N4["6.3 Reading the result"]
N5["6.4 Distinguishing clearing from rotation"]
N6["6.5 Controlled test"]
N7["6.6 Readiness change"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX026"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 The question"]
N2["6.2 Rotating logs"]
N3["Lab — retention under different rates"]
N4["6.3 Reading the result"]
N5["6.4 Distinguishing clearing from rotation"]
N6["6.5 Controlled test"]
N7["6.6 Readiness change"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]
[Learning outcomes]
|
v
[6.1 The question]
|
v
[6.2 Rotating logs]
|
v
[Lab — retention under different rates]
|
v
[6.3 Reading the result]
|
v
[6.4 Distinguishing clearing from rotation]
|
v
[6.5 Controlled test]
|
v
[6.6 Readiness change]
|
v
[Worked example] --> [Exercise EX026]
Learning outcomes
You will (1) evaluate how long log evidence survives; (2) model retention under different event rates; (3) design a controlled test of logging configuration; (4) apply results to readiness.
6.1 The question
During the incident, Aiyana found that security logs on several workstations started only hours before the attack. Did the attacker clear them, or did they simply rotate? Marta orders a controlled evaluation. The answer matters for the report: a cleared log is an attacker action and a finding, while a rotated log is a configuration limit and a readiness gap. Calling every short log 'cleared' would overstate what the attacker did, and calling every one 'rotated' could hide anti-forensic activity. Marta wants a tested method that separates the two patterns on each affected host.
6.2 Rotating logs
Many logs have fixed sizes; when full, the oldest entries are overwritten. How long an event survives depends on log capacity and event rate. The arithmetic is simple: time kept equals capacity divided by event rate. A workstation log that holds weeks of quiet activity can hold only hours when ransomware or an attacker generates thousands of events per hour. The lab below shows how strongly the event rate changes the history a log keeps. Security logs on Corvane workstations use a fixed size of this kind.
Lab — retention under different rates
"""How long do events survive in a fixed-size rotating log? (synthetic)"""
capacity = 20_000 # events the log holds
for label, rate in [("quiet", 150), ("normal", 600), ("attack burst", 4000)]:
print(f"{label:12} {rate:5} events/h -> oldest event kept ~{capacity/rate:6.1f} h")
Run with python3 lab_retention.py. Verified output:
quiet 150 events/h -> oldest event kept ~ 133.3 h
normal 600 events/h -> oldest event kept ~ 33.3 h
attack burst 4000 events/h -> oldest event kept ~ 5.0 h
6.3 Reading the result
A log holding 20,000 events keeps about 133 hours of history at 150 events per hour, 33 hours at 600, and only 5 hours during a burst of 4,000 events per hour. An attacker's noisy activity — or the ransomware's own file operations, if logged — can push out earlier evidence within hours, without any deliberate clearing. The model explains why several workstation logs began only hours before the attack without any clearing. During CF-21 activity, rates far above normal would push the oldest entries out quickly. It does not show which hosts were cleared; that needs the log-cleared event or an abrupt start, checked host by host.
6.4 Distinguishing clearing from rotation
Deliberate clearing typically leaves its own record (a log-cleared event) and an abrupt start; rotation shows a continuous log whose oldest entry simply moves forward. Aiyana checks both patterns on the affected hosts: two show cleared events, the rest show rotation. The check is host by host: for each short log Aiyana looks for a log-cleared record at its start and for continuity in the entries that follow. WS-07 fits the clearing pattern, consistent with its role as the first-infected host. Reporting the two patterns separately keeps the attacker's actions distinct from Corvane's configuration.
6.5 Controlled test
On test machines with the production configuration, the team generates realistic synthetic activity and measures how long events survive, confirming the model within 10%. The test uses the same log size and audit settings as Corvane's production workstations, with synthetic activity at quiet, normal and burst rates. Measured survival times fall within 10% of the model's 133, 33 and 5 hours. The model can then be cited in the report as tested, not just calculated. The test settings, activity scripts and measurements are kept so the test can be repeated when log sizes change.
6.6 Readiness change
Forward security logs to the central collector in near real time and enlarge local logs, so rotation no longer destroys evidence. With central forwarding, an event survives once the collector receives it, whatever happens later to the local log. Larger local logs add a buffer if forwarding is interrupted. The change addresses the WS-12 pattern directly; it does not stop an attacker clearing local logs, but the forwarded copy remains. Both changes enter the readiness policy and are tested in the twice-yearly technical exercises.
6.7 Reporting
The report distinguishes hosts with cleared logs (attacker action) from rotation (configuration limit). For CF-21 the report names WS-07 and the other cleared host as attacker action, with the log-cleared events as evidence. The rotated hosts, such as WS-12, are listed under limits, with the model and controlled test explaining why their history was short. Readers can then see which gaps were caused by the attacker and which by configuration. The model's assumptions, such as steady event rates, are stated with it so readers know its limits.
Worked example
WS-07's log begins at 01:05 with a log-cleared event recorded under an administrator account; WS-12's begins at 22:40 with no such event and continuous entries. Aiyana reports WS-07 as deliberately cleared and WS-12 as rotated during high activity.
Synthetic case. The rates are generated by the lab script.
Errors and limits
The model assumes steady rates; real bursts vary, so test with realistic activity.
Exercises
- EX026 — Lab retention. Report retention hours at the three rates. Rubric: 3 = ~133, ~33, ~5 hours; 2 = two; 1 = one; 0 = none.
- EX027 — Clearing vs rotation. How do the two patterns differ? Rubric: 3 = cleared event and abrupt start vs continuous log with moving oldest entry; 2 = partial; 1 = same; 0 = none.
- EX028 — WS-07 and WS-12. How was each host classified? Rubric: 3 = WS-07 cleared; WS-12 rotated; 2 = one; 1 = reversed; 0 = none.
- EX029 — Readiness change. What configuration change was recommended? Rubric: 3 = near-real-time central forwarding; larger logs; 2 = one; 1 = vague; 0 = none.
- EX030 — Model check. How was the model validated? Rubric: 3 = controlled test with production config, within 10%; 2 = partial; 1 = assumed; 0 = none.
Synthesis
Controlled evaluation separates attacker action from configuration limits and drives readiness changes.
Continue studying — chapter 06 of 12
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →