// networking basics — module 08

Module 8 — Operating Systems Under a Security Lens: Linux & Windows

Thesis: You already know Linux. Now revisit it through a security lens and — crucially — pick up Windows, which most Linux-first learners under-know and which dominates real enterprise environments. Every OS enforces identity, permissions, processes, and logging: the names differ between Linux and Windows, but the concepts are the same. Learn the mapping and no environment is foreign.

Prerequisite: Module 7 — Cryptography Fundamentals, and the entire Linux Foundations course (especially Modules 4, 5, and 7 — permissions, processes, and systemd). This module leans on all of it.

8.1 Why both operating systems, and why now

Real environments are mixed. Servers might be Linux; the workstations, the mail, and the identity system are almost certainly Windows. If you only know Linux, half the battlefield is invisible to you — and it's the half most attacks actually traverse. This module's job is to make you conversant in the Windows security model and to show you that it's the same ideas you already know from Linux, wearing different names. It closes with Active Directory, the thing that ties enterprise Windows together and is the top target in most real engagements.

8.2 Linux, security-relevant recap

You know these from the Linux course; here's the security framing to carry forward. (Depth lives in that course — this is the lens.)

• Users, groups, permissions — the rwx model (Linux Module 4), plus the dangerous specials: setuid/setgid binaries run with the file owner's privileges, not the caller's, which is why a misconfigured setuid-root binary is a classic privilege-escalation path.
• Processes — how programs run, parent/child relationships, and how to inspect them (Linux Module 5). Malicious processes hide among legitimate ones.
• Where logs live — /var/log, and the systemd journal via journalctl (Linux Module 7). The primary defensive telemetry on Linux. (Module 11 makes this central.)
• Services — systemd/journald managing daemons; a service is also a favorite persistence mechanism for an attacker.
• Scheduled tasks — cron (and systemd timers): legitimate automation, and a classic way attackers keep a foothold that survives reboots.

Hold onto the shape: identity (users/groups) → permissions (rwx/setuid) → execution (processes/services) → records (logs). Windows has every one of these.

8.3 Windows — the gap to close

Now the part most Linux learners are missing. Windows is architecturally different from Unix, but it solves the same problems.

8.3.1 The registry

The registry is Windows' central, hierarchical configuration database — a giant tree of keys and values that stores settings for the OS, hardware, and applications. Where Linux scatters config across plaintext files in /etc, Windows centralizes enormous amounts of it in the registry. It's organized into top-level hives (e.g., HKEY_LOCAL_MACHINE for system-wide settings, HKEY_CURRENT_USER for the logged-in user).

Security-wise the registry is a double gift: it's where a lot of persistence hides (auto-run keys that launch a program at boot/login are an attacker favorite), and it's a forensic goldmine for a defender (it records installed software, run history, and configuration changes with timestamps). Learn to navigate it read-only with regedit.

8.3.2 The Windows security model — SIDs, tokens, UAC

• User accounts — local and (in a domain) network identities.
• SIDs (Security Identifiers) — Windows identifies every user and group by a unique SID string, not by name. The name is just a label; the SID is the real identity the system checks (the analog of a Linux UID/GID, but globally unique and structured).
• Access tokens — when you log in, Windows builds an access token listing your SID and all your group SIDs and privileges. Every action you take carries this token, and the system checks it against what you're trying to touch. (Conceptually like your Linux process carrying its UID/GIDs — and, like those, a target for theft/impersonation.)
• UAC (User Account Control) — the "do you want to allow this app to make changes?" prompt. Even an administrator normally runs with a reduced token and must elevate to do administrative things. It's Windows' least-privilege-by-default mechanism, roughly analogous to needing sudo rather than living as root.

8.3.3 NTFS permissions / ACLs

Where Linux has the compact rwx-for-owner/group/other model, Windows' NTFS filesystem uses ACLs (Access Control Lists): each file or folder carries a list of entries, each granting or denying specific, granular rights (read, write, execute, delete, take ownership, change permissions…) to specific SIDs. It's more granular than rwx but the same idea — who may do what to this object. Being able to read an ACL is the Windows equivalent of reading ls -l.

8.3.4 Processes and services

Windows runs background programs as services (the analog of Linux daemons/systemd units), managed via the Services console or sc/PowerShell. Foreground programs are processes, inspectable in Task Manager or, better, tools like Process Explorer. As on Linux, malware masquerades as legitimate processes and installs itself as a service for persistence — so knowing what normal looks like is the defensive skill.

8.3.5 Windows Event Logs

This is the primary defensive telemetry on Windows — the counterpart to Linux's journal. Windows records events into channels viewable in Event Viewer:

• Security — logons (success and failure), privilege use, account changes. The channel a defender lives in.
• System — OS and driver events, service starts/stops.
• Application — events from installed programs.

Events are identified by Event IDs (e.g., 4624 = successful logon, 4625 = failed logon) — numbers you'll come to recognize the way you recognize ports. Module 11 makes this telemetry central; for now, know where it lives and that it's the Windows analog of journalctl.

8.3.6 The command lines: cmd and PowerShell

Windows has two shells. cmd is the old, limited command prompt. PowerShell is the modern, powerful one — an object-oriented shell and scripting language that is the administration and automation layer for Windows (and a favorite of attackers, precisely because it's powerful and pre-installed). It's the Windows counterpart to Bash. You'll preview it here and use it in Module 10.

8.4 Active Directory — because both tracks live in it

A company with hundreds of Windows machines can't manage users and policy on each one individually. Active Directory (AD) is Microsoft's centralized directory service that manages authentication, authorization, and policy for an entire organization from one place. Understand its shape:

• Domain — a logical group of users, computers, and resources sharing one directory and one authentication authority.
• Domain Controller (DC) — the server(s) that run AD: they hold the directory database and authenticate everyone. Compromise a DC and you effectively own the domain.
• OUs (Organizational Units) — containers that organize objects (users, computers) into a hierarchy for management.
• Group Policy (GPO) — centralized configuration pushed to machines and users across the domain (password rules, allowed software, security settings). One change, applied everywhere.

              ┌───────────────────────┐
              │   Domain Controller   │  ← runs AD; authenticates everyone
              │   (holds the directory)│
              └───────────┬───────────┘
                          │ authentication + policy
        ┌─────────────────┼─────────────────┐
        │                 │                 │
   ┌────▼────┐       ┌────▼────┐       ┌────▼────┐
   │ Users   │       │ Computers│      │  GPOs   │
   │ (OUs)   │       │  (OUs)   │      │(policy) │
   └─────────┘       └──────────┘      └─────────┘

Why AD is "the crown jewels": it centralizes identity for the whole organization, so compromising the domain often means controlling everything — every machine, every account, every file share. That single fact is why AD is the number-one target in most real-world attacks and the number-one thing enterprise defenders harden and monitor. You'll meet its authentication protocols (NTLM, Kerberos) in Module 9.

8.5 The cross-cutting idea

Step back and see the symmetry. Every OS enforces the same four things; only the names differ:

Learn the concepts once and you can read either system. That's the whole point of putting this module before the split — the terrain of both tracks is these OS internals.

8.6 → Red/Blue

Red teams enumerate and attack Active Directory (the top target in most engagements), abuse setuid binaries and misconfigured services to escalate privilege, steal access tokens, and pivot across Windows and Linux hosts. Blue teams harden AD and Group Policy, monitor Windows Event Logs and the Linux journal, watch for malicious use of built-in tools (PowerShell, cron, services), and hunt for persistence in registry auto-runs and scheduled tasks. The same OS internals are the battleground for both — one side abuses them, the other watches them.

Lab 8

You need a Windows VM for the Windows half (Module 1's third machine — Microsoft's free evaluation images work). Do the Linux items on your lab Linux box.

1. Read the Windows security log. On the Windows VM, open Event Viewer → Windows Logs → Security. Deliberately log off and mistype your password once, then log in correctly. Find the failed logon (Event ID 4625) and the successful logon (4624). This is the telemetry Module 11 builds on.

2. Compare permission models. On Windows, right-click a folder → Properties → Security tab and read its NTFS ACL (which users/groups have which rights). On Linux, ls -l a directory and read its rwx. Write down how the two express the same idea differently.

3. Navigate the registry (read-only mind). Open regedit and browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. These are the programs that auto-start — exactly where persistence hides. Look, don't change.

4. Meet PowerShell. In PowerShell run Get-Process (Windows' ps) and Get-Service (list services). Note it returns objects, not just text — the thing that makes it powerful (and a Module 10 topic).

5. Diagram AD. In your own words, draw and label what a domain controller centralizes for an organization (authentication, authorization, policy) and why compromising it is catastrophic. Reference §8.4.

6. Build the mapping table from memory. Reproduce the §8.5 table (Linux term ↔︎ Windows term) without looking.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

1. What is the Windows registry, and why is it both a config store and a forensic goldmine?
2. What is a SID, an access token, and UAC — and what is each one's Linux analog?
3. How do NTFS ACLs differ from Linux rwx, and what do they have in common?
4. Which Windows Event Log channel does a defender watch, and what do Event IDs 4624 and 4625 mean?
5. What is PowerShell, why is it powerful, and why do attackers love it?
6. What is Active Directory? Define domain, domain controller, OU, and Group Policy.
7. Why is AD "the crown jewels," and what happens if a domain controller is compromised?
8. Recite the Linux ↔︎ Windows concept mapping for identity, privilege elevation, permissions, services, and logs.

And perform cold:

• On a Windows VM, find a successful and a failed logon in the Security log by Event ID.
• Read an NTFS ACL and a Linux rwx listing and explain how each answers "who can do what to this file."

When all of that is effortless: Module 9 — Identity, Authentication & Access