OpenCyber Academy
Bachelor's · Chapter 11 · English
Course code: OCA-108Chapter 11: OCA-108-C011

Chapter 11 — Operating systems

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

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["11.1 Processes and their lineage"]
  N2["11.2 Services and scheduled work"]
  N3["11.3 Sessions and accounts"]
  N4["11.4 File metadata"]
  N5["11.5 Updates"]
  N6["11.6 Log sources"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["11.1 Processes and their lineage"]
  N2["11.2 Services and scheduled work"]
  N3["11.3 Sessions and accounts"]
  N4["11.4 File metadata"]
  N5["11.5 Updates"]
  N6["11.6 Log sources"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes and connection]
    |
    v
[11.1 Processes and their lineage]
    |
    v
[11.2 Services and scheduled work]
    |
    v
[11.3 Sessions and accounts]
    |
    v
[11.4 File metadata]
    |
    v
[11.5 Updates]
    |
    v
[11.6 Log sources]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes and connection

You will be able to (1) explain processes, services, user sessions and file metadata as sources of evidence; (2) identify which operating-system log records which kind of event; (3) generate competing explanations for an unfamiliar process; and (4) choose a bounded, non-destructive check. Chapters 2 and 8 gave you systems and parsing; here you read the host itself. Chapter 27 uses these sources to verify eradication.

11.1 Processes and their lineage

A process is a running program with an identifier (PID), an owner (user account), a parent process, a command line and an executable path. Lineage — the chain of parents — is often more informative than the name: powershell.exe started by an office document is very different from powershell.exe started by a management agent. Names can be imitated; paths, signatures and parents are harder to fake consistently.

In the WS-031 example, cagent-helper.exe is started by updater.exe, itself launched by a scheduled task under SYSTEM. That chain fits an update, though it does not prove the helper's contents are legitimate.

11.2 Services and scheduled work

A service (Windows service, Linux systemd unit, macOS launch daemon) starts automatically and usually runs under a system account. Scheduled tasks and cron jobs run at set times. Both are legitimate mechanisms for updates and maintenance — and common persistence mechanisms for attackers. The question is never "is there a scheduled task?" but "was this one created by an expected actor, at an expected time, for an expected purpose?"

On WS-031 the task ClinicAgentUpdate ran at 02:00 on 5 March as SYSTEM, which matches a maintenance window. That expected timing is a point in favour of the update explanation but not proof: an attacker who controls the updater inherits its schedule and account. The task's creation date and author are worth checking against the change calendar.

11.3 Sessions and accounts

A session links activity to a sign-in: interactive (keyboard), remote (RDP/SSH), network (file share), service. Session type matters: a "logon" event for a service account every five minutes is normal; an interactive logon by that account is not.

On WS-031 the interactive sign-in by nurse-07 at 09:15 came seven hours after the helper started. The helper was already running, so her session did not start it; a timeline must keep that order clear rather than linking a user's name to a process by proximity alone. Record each session's type and source with its time.

11.4 File metadata

File systems record timestamps (commonly modification, access, metadata change and, on some systems, creation). They are useful but fragile: copying, extracting archives, antivirus scans and time-zone settings change them, and tools can set them deliberately ("timestomping"). Treat file times as clues to be corroborated, not as clocks you can trust alone. NIST SP 800-86 (2006) discusses such caveats in forensic collection; its tool-specific details need current verification.

For cagent-helper.exe on WS-031, a file creation time around 02:01 on 5 March would agree with the process record, but agreement between two artefacts on one host is weaker than comparison with other workstations or the vendor's release.

11.5 Updates

Updates install files, restart services and create processes with unfamiliar names. Many alerts after patch nights are update artefacts. Knowing the change calendar is part of host analysis.

On WS-031 the unfamiliar helper appeared during the scheduled ClinicAgent update, so the first question is whether the vendor's release explains it. Ask the change owner for the update's schedule, expected files and hashes before treating new names as hostile. Equally, an update window is a convenient hiding place, so the calendar narrows the explanations rather than ending the investigation. Keep the change calendar where analysts can read it during a shift, since an alert raised at 02:00 is assessed by whoever is on duty, not by the patching team.

11.6 Log sources

On Windows, the Security event log records sign-ins and, if configured, process creation; Sysmon (if deployed) adds richer process and network events. On Linux, journald, auth.log/secure and the audit daemon play similar roles. Which events exist depends on configuration: an unconfigured audit policy produces silence, not innocence. NIST SP 800-92 (2006) gives general log-management guidance.

Before relying on a log, confirm which events the host was configured to record during the period in question; a policy changed last month may not cover last quarter.

11.7 Worked example (synthetic): an unfamiliar process after an update

Fictional records from workstation WS-031 after a scheduled update on 5 March:

Competing explanations: (H1) a legitimate helper used by the updater, left running by a bug; (H2) a malicious binary placed in a writable directory and launched through the updater (a supply-chain or hijack scenario); (H3) a legitimate helper later replaced by a malicious file.

Bounded checks: compare the helper's hash and signature with the vendor's published release; check whether other workstations updated at 02:00 show the same helper and hash; check the directory's write permissions; read the vendor's release notes. These checks collect no personal data and change nothing. Imaging the workstation is premature until they are done.

If ten of ten workstations show the same signed helper with identical hash and the vendor documents it, H1 is likely. If WS-031 alone has a different hash, H2/H3 become likely and the case escalates.

11.8 Common errors and limits

Exercises — chapter 11

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX031 — Lineage reading. Inputs: winword.exe → cmd.exe → powershell.exe -enc ... at 10:02 on a clerk's PC. Steps: explain why the lineage matters, give one benign and one malicious explanation, and name two checks. Rubric: 3 = explains macro-launched shell pattern, benign (documented template macro) vs malicious (phishing document), checks document source and decoded command in a safe environment; 2 = partial; 1 = name-based; 0 = none.

EX032 — Session types. Inputs: service account svc-print shows network logons every 5 minutes and one interactive logon at 03:12. Steps: interpret and choose a next check. Rubric: 3 = network logons expected; interactive logon anomalous; check source host and whether the account is allowed interactive logon; 2 = flags without check; 1 = misses it; 0 = none.

EX033 — Hash comparison plan. Inputs: §11.7. Steps: write the steps to compare helper hashes across workstations without altering them. Rubric: 3 = read-only collection via management tool, SHA-256, comparison table, record collection time and method, vendor reference; 2 = missing provenance; 1 = copying files around; 0 = none.

Chapter synthesis

Read hosts through lineage, session type and corroborated metadata; know the change calendar; build competing explanations and start with read-only checks that can discriminate between them.

Worked answers

EX031. Office applications rarely need to start command shells; the chain document → shell → encoded PowerShell is a common pattern of malicious documents, so lineage raises concern more than any one name. Benign: an internal template with a documented macro that runs a script (encoded commands are still a poor practice). Malicious: a phishing attachment executing a downloader. Checks: where the document came from (mail gateway record) and whether it is a known internal template; decode the command in an isolated analysis environment without executing it; look for network connections by the PowerShell process.

EX032. Regular network logons fit a print service. An interactive logon by a service account is unusual and may indicate someone using its credential directly. Check the source workstation of the 03:12 logon, whether policy denies interactive logon to that account, and who has the credential. Consider an urgent credential review if unexplained.

EX033. Use the endpoint-management tool's read-only query to compute SHA-256 of C:\ProgramData\ClinicAgent\tmp\cagent-helper.exe on all updated workstations; record host, path, hash, file size, signature status, query time and tool version; build a table grouped by hash; compare with the vendor's published hash or a hash from a known-clean installation; do not move or delete files during comparison.