Browse CTFs New CTF Sign in

Operating Systems Fundamentals: Linux, Windows & Process Security

foundation_systems Difficulty 1–2 80 min certifiable

Theory

Prerequisites

  • FND-K001: CIA Triad, Security Goals & the Modern Threat Landscape
  • FND-K003: Networking Fundamentals for Security Practitioners

Why This Lesson Matters

Attackers live inside operating systems. They create processes, write files, modify the registry, add users, install services, and read logs. Defenders detect, investigate, and contain threats by examining operating system artefacts. If you do not understand how a filesystem, process table, or authentication database works, you cannot meaningfully interpret the evidence that an attacker leaves behind.

This lesson covers both Linux and Windows because professional security work requires both. The two systems have very different architectures but share the same fundamental security primitives: identity, permission, process isolation, and logging.


1. Linux Fundamentals

1.1 Filesystem Layout

Linux uses a single unified filesystem tree rooted at /. Every drive, device, and network share is mounted somewhere in this tree.

Directory Contents Security relevance
/etc System configuration files /etc/passwd, /etc/shadow (user accounts and password hashes), /etc/cron.d (scheduled tasks)
/var/log Log files Primary evidence source: auth.log, syslog, nginx/access.log, audit/audit.log
/tmp Temporary files (world-writable) Common attacker staging area — files deleted on reboot
/home User home directories Personal files, SSH keys in ~/.ssh/
/root Root user home directory Highly sensitive
/bin, /usr/bin System binaries LOLBins live here (bash, python3, curl)
/sbin, /usr/sbin Admin binaries useradd, iptables, mount
/proc Virtual filesystem for process info /proc/[pid]/cmdline shows running command; /proc/net/tcp shows connections
/dev Device files /dev/sda = disk; /dev/null = discard; /dev/urandom = random

1.2 Users and Groups

Every process runs as a user. Every file is owned by a user and a group. The relationship between process identity and file permissions determines what a process can do.

Key files:

/etc/passwd  — user accounts (username, UID, GID, home dir, shell)
              Format: username:x:uid:gid:comment:home:shell
              Example: alice:x:1001:1001:Alice Smith:/home/alice:/bin/bash

/etc/shadow  — password hashes (root-readable only)
              Format: username:$6$salt$hash:lastchange:min:max:warn:inactive:expire
              The $6$ prefix = SHA-512 crypt; $y$ = yescrypt (modern)

/etc/group   — group memberships
              Format: groupname:x:gid:member1,member2

UIDs of interest:

UID Meaning Security note
0 root Full system control; any process with UID 0 is omnipotent
1–999 System / service accounts Created by packages; should not have a login shell
1000+ Normal users Standard interactive accounts

1.3 File Permissions

Linux file permissions are a 12-bit field displayed as a 10-character string:

-rwxr-xr--
│└─┘└─┘└─┘
│ owner group others
└─ type: - = file, d = directory, l = symlink

Each triplet (rwx) means: - r (4) — read - w (2) — write - x (1) — execute (for files); traverse (for directories)

Octal notation: 755 = rwxr-xr-x = owner full, group+others read+execute.

ls -la /etc/shadow
# -rw-r----- 1 root shadow 1234 Jun 8 00:00 /etc/shadow
# Only root (rw-) and members of group shadow (r--) can read it

# Change permissions
chmod 600 private_key.pem       # owner read/write only
chmod 755 script.sh             # owner full, group/others execute

# Change ownership
chown alice:alice file.txt
chown root:shadow /etc/shadow

# Find world-writable files (potential attacker staging areas)
find / -perm -o+w -type f 2>/dev/null | grep -v /proc

SUID and SGID bits: The SUID (Set User ID) bit on an executable causes it to run as the file's owner rather than the calling user. This is how passwd can modify /etc/shadow even when run by a non-root user — it is owned by root with SUID set.

ls -la /usr/bin/passwd
# -rwsr-xr-x 1 root root ... /usr/bin/passwd
#    ^ the 's' in owner execute position = SUID set

# Find all SUID binaries on the system (privilege escalation research)
find / -perm -4000 -type f 2>/dev/null

SUID binaries are a prime target for privilege escalation. If a SUID binary can be abused to execute arbitrary code (shell escape, command injection), an attacker gains root.

1.4 Processes

# List all running processes
ps aux
# USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

# Process tree (shows parent-child relationships)
ps auxf
pstree -p

# Real-time process monitor
top
htop

# Show the full command line of a specific PID
cat /proc/1234/cmdline | tr '' ' '

# Show files opened by a process
lsof -p 1234

# Show network connections
ss -tlnp          # TCP listening sockets
ss -anp           # all sockets with process info
netstat -tlnp     # legacy alternative

Why process trees matter for security: Attackers often spawn shells from unexpected parent processes. A bash shell whose parent is nginx is suspicious. A PowerShell process whose parent is winword.exe indicates a malicious document. Process tree analysis is central to both EDR detection logic and incident investigation.

1.5 Essential Linux Commands for Security Work

# File content and searching
cat /var/log/auth.log
less /var/log/syslog          # paginated; q to quit
grep "Failed password" /var/log/auth.log
grep -r "password" /etc/      # recursive search

# Find files
find /home -name "*.key" 2>/dev/null
find /tmp -mmin -10            # modified in last 10 minutes
find / -size +10M -type f 2>/dev/null   # large files

# Network
curl -v http://target          # HTTP request with verbose headers
wget -O- http://target         # download to stdout
nc -lvnp 4444                  # netcat listener (for labs)
ss -antp                       # active TCP connections

# User and permission investigation
id                             # show current user UID/GID/groups
whoami                         # current username
sudo -l                        # what can this user sudo?
cat /etc/sudoers               # sudoers configuration (if readable)
last                           # recent logins
lastlog                        # last login per user
w                              # currently logged-in users

# Hashing
sha256sum file.txt
md5sum file.txt
echo -n "password" | sha256sum  # hash a string

2. Windows Fundamentals

2.1 Filesystem and Directory Structure

C:WindowsSystem32         — Core OS binaries (64-bit)
C:WindowsSysWOW64         — 32-bit binaries on 64-bit Windows
C:Users<username>        — User profile (Desktop, Documents, Downloads)
C:Users<username>AppData — Application data (often holds malware)
  Roaming                  — Profile synced across machines
  Local                    — Machine-local data
  LocalLow                 — Low-integrity process data
C:ProgramData              — All-users application data
C:Temp / C:WindowsTemp  — Temporary files (attacker staging)

2.2 The Registry

The Windows Registry is a hierarchical database of system and application configuration. It is one of the most important artefacts in Windows forensics and is heavily abused for persistence.

Root keys:

Key Abbreviation Contents
HKEY_LOCAL_MACHINE HKLM System-wide settings, installed software, services
HKEY_CURRENT_USER HKCU Current user settings and profile
HKEY_USERS HKU All user profiles
HKEY_CLASSES_ROOT HKCR File associations and COM registrations
HKEY_CURRENT_CONFIG HKCC Current hardware profile

Critical persistence locations (attacker favourites):

HKCUSoftwareMicrosoftWindowsCurrentVersionRun
HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun
— Programs in these keys start on every user login / system boot

HKLMSYSTEMCurrentControlSetServices
— Windows services; attackers create new services for persistence

HKCUSoftwareMicrosoftWindows NTCurrentVersionWinlogon
— Can be used to hijack the login process
# Query a registry key
Get-ItemProperty "HKCU:SoftwareMicrosoftWindowsCurrentVersionRun"

# List all run key entries
reg query "HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun"

# Search for a value across the registry
reg query HKLM /f "suspicious" /s

2.3 Windows Users, Groups & Access Tokens

Every Windows process runs under an access token that specifies: - The user's SID (Security Identifier) - Group SIDs the user belongs to - Privileges (special rights beyond object permissions)

Important built-in accounts:

Account SID Privilege level
SYSTEM S-1-5-18 Highest — full access to all local resources
Administrator S-1-5-21-...-500 Local admin
Guests S-1-5-21-...-501 Very restricted
NETWORK SERVICE S-1-5-20 Limited service account
LOCAL SERVICE S-1-5-19 Lower than NETWORK SERVICE

NTFS permissions work similarly to Linux but are ACL-based (Access Control Lists) instead of the Unix rwx triplet:

Permission Meaning
Full Control Read, write, execute, delete, change permissions
Modify Read, write, execute, delete
Read & Execute Read and run the file
Read View file contents
Write Modify or create files
Special Granular sub-permissions
# Show permissions on a file
icacls C:WindowsSystem32cmd.exe

# Add permissions
icacls C:path   ofile /grant "Alice:(R,W)"

# Remove permissions
icacls C:path   ofile /remove "Alice"

2.4 Windows Event Logging

Windows logs security events in the Windows Event Log system. The Security log is the primary source for authentication and authorisation events.

Critical Event IDs:

Event ID Channel Event Security use
4624 Security Successful logon Track who logged in, from where, how
4625 Security Failed logon Brute-force detection
4634/4647 Security Logoff Session duration analysis
4648 Security Logon with explicit credentials Pass-the-hash / pass-the-ticket detection
4672 Security Special privileges assigned to logon Admin / SYSTEM logon
4688 Security Process creation Command execution tracking
4698 Security Scheduled task created Persistence installation
4720 Security User account created Backdoor account creation
4732 Security User added to privileged group Privilege escalation
7045 System Service installed Malware service persistence
1 Sysmon Process creation (with cmdline) More detailed than 4688
3 Sysmon Network connection C2 communication detection
11 Sysmon File created Malware dropper detection
# Query Event Log (PowerShell)
Get-WinEvent -LogName Security -MaxEvents 50 |
  Where-Object {$_.Id -eq 4625} |
  Select-Object TimeCreated, Message

# Using wevtutil
wevtutil qe Security /q:"*[System[EventID=4624]]" /f:text /c:10

# Export Security log
wevtutil epl Security C:evidencesecurity.evtx

2.5 Processes and Services on Windows

# List all running processes with PIDs and parent PIDs
Get-Process
tasklist /v

# Show process tree
Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, CommandLine

# List services
Get-Service
sc query type= all state= all

# Show running services with their binary paths
Get-WmiObject Win32_Service | Select-Object Name, PathName, StartMode, State

# Network connections with owning process
netstat -b         # (elevated required)
Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess

3. Logs and What They Tell You

3.1 Linux Log Files

Log file Contents Key events
/var/log/auth.log Authentication events (Debian/Ubuntu) SSH logins, sudo use, PAM failures
/var/log/secure Authentication events (RHEL/CentOS) Same as auth.log
/var/log/syslog or /var/log/messages General system messages Service starts, kernel messages
/var/log/nginx/access.log HTTP requests (nginx) Web attack patterns
/var/log/apache2/access.log HTTP requests (Apache) Same
/var/log/cron Cron job execution Malicious cron persistence
/var/log/audit/audit.log SELinux/auditd events Detailed system call monitoring

Combined Log Format (HTTP logs):

10.0.0.5 - alice [08/Jun/2026:14:32:17 +0000] "GET /admin HTTP/1.1" 403 512 "-" "Mozilla/5.0"
└──────┘   └───┘  └──────────────────────────┘  └──────────────────┘ └─┘ └─┘   └──────────────────┘
  src IP   user          timestamp                      request       code bytes   user-agent

3.2 Log Injection via X-Forwarded-For

The X-Forwarded-For (XFF) header tells a reverse proxy the original client IP. If the application logs the XFF header without sanitisation, an attacker can inject fake log entries:

# Normal request
GET /api/data HTTP/1.1
X-Forwarded-For: 192.168.1.100

# Injected log entry via XFF
GET /api/data HTTP/1.1
X-Forwarded-For: 192.168.1.100
10.0.0.1 - admin [08/Jun/2026:14:32:17 +0000] "GET /secret HTTP/1.1" 200 4096

# The log now contains a fake entry as if admin requested /secret

This technique can be used to: - Frame another user in access logs - Cover an attacker's own tracks by injecting noise - Bypass IP-based rate limiting (if the application trusts XFF for rate limiting) - Inject data into log aggregation pipelines (SIEM log injection)

Detection: Compare raw headers with log entries. Look for newlines (, %0a) or CRLF sequences in XFF header values.


4. Common Mistakes

Mistake 1: Running everything as root (Linux) or Administrator (Windows). A process that runs as root and is compromised gives the attacker root privileges immediately. Run services as dedicated low-privilege service accounts. Apply the principle of least privilege.

Mistake 2: Leaving default credentials on system accounts. Many Linux distributions ship with default passwords for service accounts. Windows systems joined to domains may have local administrator accounts with default or shared passwords. Audit these before deployment.

Mistake 3: Trusting X-Forwarded-For for security decisions. The XFF header is attacker-controlled. Never use it as the sole basis for access control decisions, rate limiting, or audit logging of client identity. Use it only as supplemental information.

Mistake 4: Forgetting that /tmp is world-writable. Malware frequently stages in /tmp because every user can write there. Any file that appears in /tmp that you did not place there is suspicious. Monitor /tmp for executable files.

Mistake 5: Missing the SysWOW64 directory on Windows. 32-bit malware on a 64-bit Windows system loads from C:WindowsSysWOW64 not System32. Security tools and log parsers that do not account for this miss a common malware staging area.


5. Guided Example — Investigate a Suspicious Login

Scenario: You receive an alert that user alice logged in at 3:47 AM from an unusual IP. You need to investigate.

Step 1: Find the logon event in the auth log

grep "alice" /var/log/auth.log | grep "Accepted"
# Jun  8 03:47:22 server sshd[1234]: Accepted password for alice from 185.220.101.5 port 49221 ssh2

Step 2: Check what alice did after login

# Find processes started by alice's session
grep "alice" /var/log/auth.log | tail -50
# Check bash history (if not cleared)
cat /home/alice/.bash_history

Step 3: Check for persistence installations

# New cron jobs
cat /etc/cron.d/*
crontab -u alice -l

# New SUID binaries (run at time of alert)
find / -perm -4000 -newer /var/log/auth.log -type f 2>/dev/null

# New services (systemd)
systemctl list-units --state=failed
ls -la /etc/systemd/system/ --sort=time | head

Step 4: Check network activity

ss -antp   # current connections (may be gone if session ended)
# Check system logs for outbound connections around 03:47
grep "03:4[5-9]" /var/log/syslog | grep -i "connect|tcp"

Step 5: Assess and report

Based on the evidence: - Source IP 185.220.101.5 → look up in threat intelligence (Tor exit node? known attacker IP?) - Password auth at 3:47 AM from unusual IP → indicator of credential compromise - Document: CIA impact (Confidentiality — system accessed; possibly Integrity/Availability if changes were made), threat actor category (cybercriminal or targeted attacker), escalate to CIR


6. Practice Exercises

  1. On a Linux system, run find / -perm -4000 -type f 2>/dev/null. For each SUID binary listed, explain why it legitimately needs SUID.

  2. You see the following entry in /var/log/auth.log: Jun 8 14:23:01 server sudo: mallory : TTY=pts/1 ; PWD=/tmp ; USER=root ; COMMAND=/bin/bash

  3. What happened?
  4. Is this suspicious? Why?
  5. What evidence would you collect next?

  6. On Windows, run Get-WinEvent -LogName Security -MaxEvents 100 | Where-Object {$_.Id -eq 4625} | Group-Object -Property Message | Sort Count -Descending. What does this show you? What would a high count indicate?

  7. Write a grep one-liner that extracts all unique source IP addresses from an Nginx access log.


7. Lab

Assessment mode: flag

challenge_spec_id: 242 — X-Forwarded-For log injection

You are given an HTTP access log access.log that has been tampered with. An attacker injected fake log entries via the X-Forwarded-For header.

Your task: 1. Read the access log 2. Identify entries that contain injected content (lines that should not exist based on the XFF value) 3. Extract the flag that the attacker embedded in the injected log entry

The flag is in PREFIX{...} format, embedded in the injected XFF value.


8. Framework Alignment

Framework Domain / Role Competency Confidence
CCSSF-COA Cyber Security Operations Analyst OS log analysis, event correlation High
CCSSF-DFA Digital Forensics Analyst File system and process artefact analysis High
CCSSF-CIR Cyber Incident Responder System triage and evidence collection High
CCSSF-ENG Security Engineer Hardening, least privilege, log architecture High
NICE 2.2.0 Cyber Defense Analyst (PR-CDA-001) K0042 — Incident response methodology High
NICE 2.2.0 Digital Forensics Analyst (INV-FOR-002) K0117 — OS security features High
NICE 2.2.0 All roles K0060 — Linux operating system High

9. Further Reading

  • The Linux Command Line (2nd ed.) — William Shotts — Free online; the most readable introduction to Linux command-line work
  • Linux Privilege Escalation — HackTricks — https://book.hacktricks.xyz/linux-hardening/privilege-escalation — Practical reference for understanding what attackers look for
  • Windows Internals (7th ed.) — Yosifovich, Ionescu — The authoritative reference for Windows security architecture
  • SANS Poster: Windows Forensic Analysis — Quick-reference card for Windows forensic artefacts
  • Sysmon Configuration Guide — SwiftOnSecurity — https://github.com/SwiftOnSecurity/sysmon-config — The community standard for Sysmon deployment
  • auditd Rules — bfuzzy1 — https://github.com/bfuzzy1/auditd-attack — ATT&CK-mapped Linux audit rules

Learning Objectives

["Navigate the Linux filesystem tree and identify the security-relevant contents of /etc, /var/log, /tmp, and /proc", "Interpret Linux file permission notation (rwx triplets and SUID/SGID bits) and find all SUID binaries on a system", "Identify the Windows Event IDs associated with logon, process creation, service installation, and scheduled task creation, and query them using Get-WinEvent", "Detect a log injection attack via the X-Forwarded-For header in an HTTP access log and extract embedded data"]

Lesson Outline

Prerequisites → Why this matters → Linux (filesystem layout, users/groups, file permissions with SUID, process investigation, essential commands) → Windows (filesystem, registry persistence locations, access tokens, Event Log with critical IDs, process investigation) → Logs and what they tell you (Linux log files, Combined Log Format, XFF injection technique) → Common mistakes → Guided investigation example → Practice exercises → Lab (flag, spec 242) → Framework alignment → Further reading

Challenge Lab

Reinforce your learning with a hands-on generated challenge based on this card's competency.