« Red Team Engineer

Phase 04 — OS Internals & Privilege Escalation (Windows + Linux)

Operation Cedar Lattice, Phase 04. Phase 03 took you from external recon, through a foothold VPN, into Meridian Freight International's internal network and produced a pivot map. You now have your first footholds — one Windows host, one Linux host — but only as a low-privileged principal: a service account, an IIS app-pool identity, or a standard user. Domain admin, the cloud, and the data store are all downstream of one thing: turning a user into NT AUTHORITY\SYSTEM on Windows and root (uid 0) on Linux. That is local privilege escalation, and it is what this phase builds.

The deliverable a real engagement produces here is not "we got SYSTEM." It is, for each foothold, a path-to-privilege analysis: the misconfiguration, the ATT&CK technique, the concrete escalation path, the telemetry it emits, and the detection that catches it — the artifact the purple team replays and Meridian keeps.

Safety. Authorized-lab only. Both labs are analyzers / auditors over synthetic host facts (enumerated services, ACLs, token privileges, SUID files, capabilities, sudo rules). There is no live exploitation, no service write, no token theft, no GTFOBins one-liner — they classify enumeration output the way WinPEAS/Seatbelt/LinPEAS/pspy do and explain the path and its detection. Same boundary as the security track's offensive-methodology-mastery/ labs.

Why this phase exists

A foothold is not an outcome — it is a starting position. Most of the interesting damage (credential theft, persistence that survives, lateral movement with SYSTEM/root rights) requires local privilege escalation first. And privesc, on both operating systems, is overwhelmingly not a memory-corruption exploit: it is abuse of a legitimate OS mechanism that a low-privileged principal can influence — a service the SCM launches, a token privilege handed to a service account, a SUID binary with a shell escape, a sudo rule that is too generous.

To find those paths you must understand the OS internals the mechanism rests on: on Windows, the process/thread/token model, SIDs and privileges, integrity levels and UAC, services and their DACLs, the registry; on Linux, uid/gid/euid, SUID/SGID, capabilities, sudo, PATH, cron, namespaces. This is the JD's "OS security across operating systems / Linux" and "privilege escalation." And because every misconfiguration emits telemetry, understanding the mechanism is also how you write the detection — which is what turns this offensive knowledge into a hireable, defensible asset.

Learning Objectives

By the end of this phase you can, without notes:

1. Explain the Windows security model end to end: a process has a primary access token carrying the user SID, group SIDs, and a list of privileges; objects carry a security descriptor (owner + DACL of ACEs); a check is token vs. DACL. Explain integrity levels and why UAC is not a security boundary.
2. Name the privilege-escalation paths a Windows host exposes and the internal reason each works: unquoted service paths, weak service binary/DACL permissions, SeImpersonate/ SeAssignPrimaryToken (the potato family), SeDebug/SeBackup/SeRestore, weak registry-autorun ACLs, DLL search-order hijacking, writable scheduled tasks — each with its ATT&CK id and its detection.
3. Explain the Linux privilege model: real/effective/saved uid/gid, SUID/SGID and the euid=0 it confers, file capabilities as decomposed root, sudo, PATH resolution, and cron execution context; and the namespace/cgroup surface behind container escapes.
4. Name the privilege-escalation paths a Linux host exposes: dangerous SUID (GTFOBins), dangerous capabilities (cap_setuid, cap_dac_override, …), sudo misconfig (NOPASSWD, wildcard, LD_PRELOAD/GTFOBins binary), writable root PATH, writable cron, root-equivalent groups — each with its ATT&CK id and its detection.
5. For any technique, predict the telemetry it emits — Windows Sysmon (EID 1/7/11/13), Security log (4688 process create, 4673/4674 sensitive-privilege use, 4624 logon, 4698 task, 7045 service) and Linux auditd execve — and write a detection that fires.
6. Run the enumeration → identify path → escalate (on an owned range) → harden → detect loop and produce the per-foothold privesc finding with its remediation.

The two models, side by side

                WINDOWS                                   LINUX
  identity      access TOKEN (user SID + group SIDs       uid/gid (real/effective/saved);
                + PRIVILEGES) on every process            supplementary groups
  authorization object security descriptor: owner +       file mode bits (rwx) = DAC;
                DACL (ordered ACEs); check = token×DACL    + POSIX capabilities; + LSM (SELinux)
  "become root" steal/impersonate a SYSTEM token;         get euid 0: SUID shell escape; a cap;
                abuse a privilege; hijack a SYSTEM         sudo to a shell; hijack a root-run
                service/task/autorun                       binary (PATH/cron/LD_PRELOAD)
  NOT a boundary UAC (a convenience prompt)                a setuid bit you don't control is
                                                           the boundary; nosuid mounts remove it
  telemetry     Sysmon + Security Event Log + ETW          auditd (execve) + eBPF + syslog

Memorize the shape once: identity → what may it touch → how do you become the all-powerful principal → what does the OS log about it. Each platform is a re-labeling of those four questions.

Concepts

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), a complete solution.py, adversarial test_lab.py, README.md, requirements.txt — pure Python (stdlib + pytest), offline, deterministic, with the detection pairing built in.

cd lab-01-windows-privesc-analyzer
LAB_MODULE=solution python3 -m pytest -q   # reference passes (15 tests)
python3 -m pytest -q                         # your implementation after the TODOs

cd ../lab-02-linux-privesc-auditor
LAB_MODULE=solution python3 -m pytest -q   # reference passes (16 tests)

Deliverables

• A Windows privesc analyzer that ingests a host snapshot and reports each misconfiguration (unquoted service path, writable service binary/DACL, dangerous token privilege, weak autorun ACL, writable scheduled task) with its ATT&CK technique, concrete path to SYSTEM, and Sysmon/Event-Log detection.
• A Linux privesc auditor that ingests an enumeration snapshot and reports each escalation path (dangerous SUID, dangerous capability, sudo NOPASSWD/wildcard/LD_PRELOAD, writable PATH, writable cron, root-equivalent group) with its ATT&CK technique, root note, and auditd detection.
• The two per-foothold privesc findings for Operation Cedar Lattice (the first Windows host and the first Linux host), each with its hardening and detection — the Phase 04 artifact.
• The fluency to explain both OS models and walk a privilege-escalation path and its detection in an interview, and to scope a safe privesc exercise on an owned range (snapshot, stop conditions, teardown).

Readings (primary sources)

• Windows Internals, 7th ed. (Russinovich, Allievi, Ionescu, Solomon) — Parts 1 & 2: processes, threads, access tokens, SIDs, privileges, integrity levels, the object manager and security descriptors, services.
• Microsoft Docs: Access Tokens, Privilege Constants, Mandatory Integrity Control, How UAC Works, Service Security and Access Rights.
• MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation), T1134 (Access Token Manipulation), T1548 (Abuse Elevation Control Mechanism), T1574 (Hijack Execution Flow — unquoted path, service permissions, DLL search order), T1543.003 (Windows Service), T1547.001 (Run keys), T1053 (Scheduled Task/Cron).
• GTFOBins (Unix binaries with shell escapes) and LOLBAS (Windows living-off-the-land binaries).
• The Linux capabilities(7) man page; the sudoers(5) man page; auditd / auditctl documentation; the PrintSpoofer/RoguePotato write-ups for the SeImpersonate family (concept + detection only).

Common Mistakes

• Treating UAC as a privilege boundary. It is a convenience prompt; an admin-split-token user is one auto-elevating bypass away. Microsoft explicitly says UAC is not a security boundary.
• Confusing a SID with a privilege. A SID is who you are; a privilege (SeImpersonate) is what you may do. Escalation usually abuses a privilege, not an identity.
• Reporting an unquoted service path with no writable intermediate dir. The unquoted path is only exploitable if you can write an interceptor at a higher-precedence prefix. State the precondition.
• Calling a Linux file with cap_setuid "non-root." A capability is root, scoped. getcap -r / is as important as finding SUID bits.
• Trusting sudo -l output without reading the runas spec and env_keep. A wildcard, a pager, or a kept LD_PRELOAD turns an innocuous-looking rule into a root shell.
• Finding the path but not the detection. A privesc finding without the Sysmon/auditd rule that catches it fails this track's detection-pairing bar — and delivers no lasting value to the client.
• Escalating off a snapshot/owned range. Privilege escalation is destructive and noisy; snapshot first, name stop conditions, and revert after.

Interview Questions

1. Walk me through the Windows access-token model. What is the difference between a SID, a group SID, and a privilege, and how does an object's DACL get checked against a token?
2. Why is UAC not a security boundary? What does that mean for how you treat a "medium-integrity admin" host?
3. Explain the SeImpersonatePrivilege "potato" family — what is the privilege, why do service accounts have it, what is the escalation, and how would you detect it?
4. What makes an unquoted service path exploitable, and what is the exact additional precondition?
5. On Linux, what is the difference between SUID and a file capability like cap_setuid? Why does a defender need to enumerate both?
6. Give me three ways a too-generous sudo rule becomes a root shell, and the auditd rule that catches each.
7. You have a foothold as a low-priv user on a Windows host and a Linux host. Describe your enumeration order and what you are looking for on each, and the telemetry each step would emit.
8. A SOC asks you to turn your privesc findings into durable detections. Pick two (one per OS) and write the detection logic and what it would false-positive on.

(Full principal-level answers are in WARMUP.md.)

Portfolio artifact

The per-foothold privilege-escalation findings for Operation Cedar Lattice: for the first Windows host, the analyzer output (the misconfiguration, ATT&CK technique, path to SYSTEM, hardening, and the Sysmon/Event-Log detection); for the first Linux host, the auditor output (the path to root with its ATT&CK technique, the auditd rule, and the hardening). Both over synthetic host facts — no live targets, no exploitation, no weaponization. This is 04-05-windows-ad/ in the capstone portfolio.

Guides

• WARMUP.md — the from-zero deep dive: the Windows process/thread/token model, SIDs & privileges, integrity levels & UAC, the potato/SeImpersonate family, unquoted paths, weak service/registry DACLs, DLL hijacking, scheduled tasks; then the Linux uid/gid model, SUID/SGID, capabilities, sudo, PATH/cron, namespaces — each with its telemetry, detection, and misconceptions.
• HITCHHIKERS-GUIDE.md — how to run the privesc loop on the owned range: enumerate with WinPEAS/Seatbelt and LinPEAS/pspy, identify a seeded misconfiguration, walk the escalation, then harden it and write the Sysmon/auditd detection, and tear down.