Module 3: Operating systems & the command line

Estimated time: 5-6 hours (including labs) · Prerequisites: M1 (your Linux VM), M2

Security tooling lives in the terminal. Servers you'll investigate often have no graphical desktop at all, SOC platforms expect you to write text queries, and one command line can do in seconds what would take fifty mouse clicks, then be scripted to run a thousand times. Comfort at the command line is one of the clearest signals that separates job-ready candidates from course-collectors.

Supports Security+ SY0-701 domains: 4.0 Security Operations (and parts of 2.0 Threats, Vulnerabilities, and Mitigations).

What you'll get from this module

• Navigate the Linux filesystem and know what lives in /etc, /var/log and /home.
• Read and search files with cat, less and grep, the analyst's bread and butter.
• Read Linux permissions (rwx notation) and understand users, root and sudo.
• List and manage processes, and install software with a package manager.
• Use PowerShell for the equivalent jobs on Windows.
• Know where logs live on both operating systems, the bridge to SOC work in M8.

---

1. Why the command line, really

Three reasons this module exists:

1. That's where the machines are. Most servers, cloud instances and security appliances run Linux with no desktop. If you can't work in a terminal, you can't work on them.
2. Speed and precision. "Find every failed login in this 2 GB log from last Tuesday" is one grep command. Try that with a mouse.
3. Scriptability. Anything you can type, you can automate. SOC teams script their repetitive triage; the analysts who can do that get promoted.

You don't need to become a wizard. You need working fluency: navigate, read, search, and understand what you're looking at.

---

2. Linux: the filesystem map

Linux has no C: drive. Everything hangs off a single root directory, /. Three locations matter immediately:

Directory	What lives there	Why security cares
/etc	System configuration files	Attackers modify configs to weaken or persist; /etc/passwd lists user accounts
/var/log	System and application logs	This is where evidence lives. Your future workplace, in miniature
/home	Each user's personal files (/home/alice)	User data, stolen or ransomed; per-user config often abused for persistence

Getting around needs exactly three commands:

pwd             # print working directory — "where am I?"
ls -la          # list files, long format, including hidden ones
cd /var/log     # change directory (cd .. goes up one level)

Files starting with a dot (like .bashrc) are hidden, which is why analysts habitually use ls -la, not plain ls. Attackers know about dot-files too.

---

3. Linux: reading and searching files

Command	Job	Example
cat	Print a whole file	cat /etc/hostname
less	Page through a big file (q to quit, /word to search)	less /var/log/syslog
grep	Print only lines matching a pattern	grep "error" /var/log/syslog

grep is the single most important command in this module. Useful variations:

grep -i "failed" auth.log       # -i: ignore case
grep -c "failed" auth.log       # -c: just count the matches
grep -v "session opened" auth.log   # -v: everything EXCEPT this pattern

Filtering millions of log lines down to the interesting dozen is log analysis. Everything fancier (SIEM queries in M8) is this idea with a nicer interface.

---

4. Linux: users, permissions and sudo

M1 introduced rwx notation; now you can read it in the wild. In ls -la output:

-rwxr-x--- 1 alice analysts 4096 Jul 9 10:30 triage.sh

• First character: - file, d directory.
• Then three sets of three: owner (rwx), group (r-x), everyone else (---): read, write, execute; a dash means "not permitted". Here alice can do anything, the analysts group can read and run it, everyone else gets nothing.
• chmod changes permissions; chown changes the owner. You'll mostly read permissions rather than set them: a world-writable config file or a startup script owned by the wrong user is a finding.

Root and sudo: root is the all-powerful administrator account. Rather than logging in as root (dangerous, no guardrails), authorised users prefix single commands with sudo ("do as superuser"): sudo cat /var/log/auth.log. Every sudo use is logged: least privilege (M1) plus accountability, and exactly why attackers who land on a Linux box immediately hunt for a path from a normal user to root (privilege escalation).

---

5. Linux: processes and packages

Every running program is a process with a numeric PID:

ps aux          # snapshot of all processes
top             # live view (q to quit)
kill 1234       # ask process 1234 to stop (kill -9 forces it)

An analyst's habit worth forming now: skim ps aux and ask "what is that, and should it be running?" Malware is just a process with something to hide.

Package managers install software from vetted repositories. On Ubuntu/Debian it's apt:

sudo apt update             # refresh the catalogue
sudo apt install curl       # install a package

This is also how Linux systems get security patches: one line in a policy document ("apply updates promptly") becomes these two commands in practice.

---

6. Windows: cmd, PowerShell, and event logs

Windows has two command lines: the legacy cmd (where ipconfig lives, fine for quick checks) and PowerShell, the modern one, and the one that matters. PowerShell commands are consistent Verb-Noun pairs that return structured objects, not just text:

PowerShell	Job	Linux cousin
Get-Process	List running processes	ps aux
Get-Service	List services and their status	None
Get-ChildItem	List files (alias: ls)	ls
Get-Content file.txt	Read a file (alias: cat)	cat
Select-String "error" file.txt	Search inside files	grep

Windows logging is event logs: structured records viewable in Event Viewer (search the Start menu) or queried with Get-WinEvent in PowerShell (you may see Get-EventLog in older guides, same idea, older command). The one to remember is the Security log, where every logon attempt lands with an Event ID: e.g. 4624 (successful logon) and 4625 (failed logon). A pile of 4625s followed by a 4624 on the same account is the classic shape of a password-guessing attack that eventually worked. SOC analysts read these IDs the way musicians read notes.

Double-edged sword: PowerShell is so capable that attackers use it too ("living off the land", abusing tools already on the system). That's why organisations log PowerShell activity itself, and why understanding it makes you better at spotting its abuse.

---

7. Where the logs live (the bridge to M8)

One table to carry forward:

OS	Location	Highlights
Linux	/var/log/	auth.log (logins & sudo, Ubuntu/Debian; called secure on Red Hat), syslog (general system events)
Windows	Event logs (Event Viewer / Get-WinEvent)	Security (logons: 4624/4625), System, Application

In M8 you'll centralise logs like these into a SIEM and hunt through them at scale. The skills are the ones you just learned: grep and Select-String with a bigger engine.

---

🧪 Lab 3A: Guided practice (free, hosted)

These platforms give you real machines in the browser. We link to them, their content is theirs, and it's excellent.

• TryHackMe: tryhackme.com, create a free account, then search for the free rooms "Linux Fundamentals Part 1", "Part 2" and "Part 3". They're the standard on-ramp: a browser-based Linux machine plus guided exercises. Work through at least Part 1 and Part 2.
• OverTheWire: Bandit, overthewire.org/wargames/bandit, a free, no-signup wargame you reach over SSH from your own terminal. Each level is a small puzzle solved with the commands from this module. Aim for level 10 or so; it's genuinely fun and interviewers recognise it. (You have permission to poke at Bandit, that's its purpose. The standing rule stays: only test systems you own or have written permission for.)

🧪 Lab 3B: Log spelunking in your own VM

Back in your M1 Ubuntu VM:

1. Open a terminal and go to the logs: cd /var/log then ls -la. Note which files your normal user can't read, permissions doing their job.
2. Look at authentication events:

   sudo less /var/log/auth.log      # page through; q to quit

   Find your own recent logins and that very sudo command being logged.
3. Hunt with grep:

   sudo grep -i "sudo" /var/log/auth.log      # every privilege elevation
   sudo grep -ciE "fail" /var/log/auth.log    # count failed auth events

   (We use -E "fail" rather than "failed" on purpose: a failed desktop login is logged as "authentication failure", while SSH logs "Failed password", matching fail catches both.)
4. Deliberately create evidence: log out, type your password wrong once on purpose, log back in, then find that failure in auth.log with sudo grep -iE "fail" /var/log/auth.log. You've just done, in miniature, what a SOC analyst does with a suspected brute-force: form a question, query the log, read the answer.

Lab success = you completed TryHackMe Linux Fundamentals Part 1-2 (or Bandit to ~level 5), and you found your own failed login in auth.log.

---

Self-check

Answer before you reveal, the attempt is what makes it stick. Your score and card ratings are saved on this device only.

Scored self-check

Check your understanding

Commit to an answer before you check: the attempt is what makes it stick. Your first answer to each question is the one scored; practising again afterwards doesn't change it. Saved on this device only.

Question 1 of 7You’ve just landed on an unfamiliar Ubuntu server to investigate a suspected compromise. Which directory do you head to first to see what’s been happening on the machine?

/etc/home/var/log

Question 2 of 7Your manager wants a quick number: how many lines in auth.log mention "failed"? Which command answers with just the count?

grep -i "failed" auth.loggrep -v "failed" auth.logless auth.loggrep -c "failed" auth.log

Question 3 of 7During a review you find a config file owned by root with permissions -rw-r--r--. What can a normal (non-root) user do with it?

Nothing: root-owned files are off limits to everyone elseRead it and edit itRead it, but not edit itExecute it as a script

Question 4 of 7Skimming ps aux on a server you’re triaging, you spot a process whose name means nothing to you. What’s the analyst habit this module wants you to build?

kill -9 it immediately, better safe than sorryAsk "what is that, and should it be running?"Ignore it. Real malware wouldn’t show up in ps aux anywayRun sudo apt update to refresh the catalogue

Question 5 of 7In the Windows Security event log you see forty 4625 events against one account in ten minutes, then a single 4624 on the same account. What are you most likely looking at?

A user who forgot their password and got there eventuallyNormal noise: 4624 is just another failed logonA successful logon followed by account lockoutsA password-guessing attack that eventually worked. Escalate immediately

Question 6 of 7A colleague asks why your organisation bothers logging PowerShell activity when it’s a legitimate admin tool. What’s the answer?

Because that’s where logon attempts are recordedBecause attackers use PowerShell too, "living off the land" with tools already on the systemBecause cmd is replacing PowerShell, so its activity needs archiving

Question 7 of 7You suspect someone has been guessing passwords on an Ubuntu server. Where do you look, and what finds the evidence fastest?

/var/log/auth.log, with sudo grep -iE "fail"/var/log/syslog, paging through with less/etc/passwd, printed with catThe Security event log, queried with Get-WinEvent

These commands, flags and log locations have to live at your fingertips, not in your notes, a live investigation doesn't pause while you look up what 4625 means. Rate yourself honestly and the cards come back on a spaced schedule.

Flashcards · spaced repetition

Drill the key terms

Say your answer out loud (or in your head) before revealing. Recall is the workout. "Knew it" pushes a card's next review further out; "Review again" brings it back today.

Card 1 of 18

Prompt

/etc

---

Next module

➡️ M4: Security fundamentals: the CIA triad, threat actors, cryptography basics, and the vocabulary of the profession.