Chapter 6 — Operating systems and virtualization | Technologist Security operations and blue team

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 6 — Operating systems and virtualization

Lesson map

Lesson 06 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Operating system events"]
  N2["6.2 Audit settings"]
  N3["6.3 Processes"]
  N4["6.4 Virtualization"]
  N5["6.5 Snapshots"]
  N6["6.6 Account changes"]
  N7["6.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Operating system events"]
  N2["6.2 Audit settings"]
  N3["6.3 Processes"]
  N4["6.4 Virtualization"]
  N5["6.5 Snapshots"]
  N6["6.6 Account changes"]
  N7["6.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]

[Learning outcomes]
    |
    v
[6.1 Operating system events]
    |
    v
[6.2 Audit settings]
    |
    v
[6.3 Processes]
    |
    v
[6.4 Virtualization]
    |
    v
[6.5 Snapshots]
    |
    v
[6.6 Account changes]
    |
    v
[6.7 Case]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) explain how Windows and Linux record logons, accounts and processes; (2) describe virtual machines and their monitoring; (3) relate audit settings to detection; (4) recognise account and group changes as signals.

6.1 Operating system events

Windows records logon successes (4624), failures (4625), account creation (4720) and group membership changes (4732) when auditing is enabled. Linux records authentication in system logs. These IDs and messages are the raw material for many SOC rules.

The lab in chapter 3 uses exactly these four IDs, which is why it can tell the BrightSmile story from seven lines. On Linux the equivalent lines appear in system authentication logs with different wording, so Copperleaf's mapping turns both into the same common fields before any rule runs, as chapter 4 describes for field names.

6.2 Audit settings

Events appear only if audit policy enables them. Copperleaf's onboarding checklist sets audit policy on each client server and verifies that test events arrive.

The test matters because a rule watching for an event that is never generated will never fire, and nothing tells the analyst so. By creating a harmless test event and checking that it reaches the SIEM, the onboarding engineer proves both that the policy is set and that the agent forwards the result. BrightSmile's worked example below shows what happens when that test is skipped: process creation logging was simply never switched on at clinic 2.

6.3 Processes

Process creation events show which programs ran and which program started them. A file-encryption tool started from an unusual folder is a strong signal.

A process event records the program's path and its parent, for example a tool launched by a logged-on user from a temporary or download folder rather than from Program Files. On a clinic server that runs a database and a file share, new programs should be rare, so such a launch gives an analyst something specific to examine.

6.4 Virtualization

Many small businesses run servers as virtual machines on one physical host. The host's management console can start, stop or snapshot every server, so access to it is highly privileged and must be monitored.

For BrightSmile this means CLINIC2-SRV is one of the guests on a host that the IT contractor manages. Someone with access to that console could switch off the server or delete its snapshots without logging on to Windows at all, so events from the host matter as much as events from the server itself.

6.5 Snapshots

Snapshots capture a server's state and can help recovery, but are not a backup if stored on the same host an attacker controls.

A snapshot sits on the same host and storage as the server it copies. An attacker who reaches the host console can delete snapshots as easily as the contractor can create them, so a snapshot helps when an update goes wrong but cannot be relied on as the only way back after ransomware. Copperleaf therefore lists snapshots and backups separately on each client inventory, so that nobody mistakes the first for the second during an incident.

6.6 Account changes

New accounts and additions to administrator groups are rare in small clinics. Alerting on them catches attackers who create their own access.

At a clinic of this size an administrator account is created perhaps when a new contractor starts, which makes an unplanned 4720 followed by a 4732 for Administrators unusual. The support2 account in chapter 3 is exactly that pattern, created by a reception account that had no business creating accounts at all. Mei's rule for these events includes the creating account in the alert text, so an analyst sees immediately when reception is the creator.

6.7 Case

BrightSmile's server is a virtual machine; the host is managed by the IT contractor.

That arrangement means the clinic server's own logs come through Copperleaf's agent, while the host's activity depends on what the contractor's console records and shares. Mei notes on the inventory that host-level logs are not yet collected, so anything done directly on the host would not appear in the SIEM. Mei adds the contractor's name and contact details to the host entry, because any action on the hypervisor during an incident must go through them.

Updates

Operating system updates fix weaknesses attackers use. Copperleaf's agent reports patch levels, and clients receive a monthly list of overdue updates.

Worked example

Mei checks BrightSmile's audit settings and finds process creation logging was off on the clinic 2 server — the onboarding checklist had been skipped during a rushed setup. She enables it with the contractor and confirms with a harmless test program that events now arrive.

Synthetic case. Settings and events are invented.

Errors and limits

Enabling more auditing adds volume; enable what rules and investigations need.

Exercises

EX016 — Event IDs. What do event IDs 4720 and 4732 record? Rubric: 3 = account created; added to local group; 2 = one; 1 = vague; 0 = none.
EX017 — Hypervisor access. Why must virtualization host access be monitored? Rubric: 3 = controls all VMs: start, stop, snapshot; 2 = partial; 1 = vague; 0 = none.
EX018 — Missing setting. What was missing on clinic 2's server and how was it fixed? Rubric: 3 = process creation logging off; enabled and tested; 2 = partial; 1 = vague; 0 = none.

Synthesis

Operating system and virtualization events give strong signals, but only when auditing is configured and verified.

Continue studying — chapter 06 of 30

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →