SOC Analyst

Built-in commands only. Nothing to install, no account, nothing to sign up for.

1. 1

   Watch a name turn into an address

   Every connection starts by looking up a name. Run this against a site you use daily, then against a site in another country. Notice you get different addresses — sometimes several.

   Windows

   nslookup bbc.co.uk

   macOS

   dig bbc.co.uk +short

   Linux

   dig bbc.co.uk +short

2. 2

   Trace the path out

   This lists every router your traffic passes through to reach that address. Read the hostnames down the left — you can usually see it leave your house, reach your provider, and cross into a backbone network.

   Windows

   tracert bbc.co.uk

   macOS

   traceroute bbc.co.uk

   Linux

   traceroute bbc.co.uk

3. 3

   Find where the time goes

   Look at the millisecond figures. Somewhere there is a jump — 8ms to 90ms between two hops. That jump is usually the moment your traffic goes long-distance. Now trace somewhere far away and compare where the jump happens.

4. 4

   Break it on purpose, then put it back

   Add a line to your hosts file pointing a site you use at 127.0.0.1, and try to load it. Watch how the failure looks from the browser — the error will not tell you what you just did. Then delete the line. This is the single most useful thing on this list: you have now seen a name-resolution fault from the user's side, which is what half of all "the internet is down" tickets actually are.

   Windows

   notepad C:\Windows\System32\drivers\etc\hosts   (run as Administrator)

   macOS

   sudo nano /etc/hosts

   Linux

   sudo nano /etc/hosts

5. 5

   Optional — watch the actual conversation

   If you want to go further, install Wireshark, capture for ten seconds while loading one page, and filter for "http" or "dns". You will see the individual messages between your machine and the server. This is the one step that needs an install, which is why it is last.

Uses the log viewer already built into your operating system. Nothing to install.

1. 1

   Open the record

   Your machine has been writing down what it does, continuously, for as long as you have owned it. Most people never look.

   Windows

   eventvwr.msc  →  Windows Logs  →  System

   macOS

   Console.app  →  select your Mac under Devices

   Linux

   journalctl -b --no-pager | less

2. 2

   Find yourself in it

   Locate the moment you logged in this morning. Note the exact timestamp and the event id. You have just done the core move of every investigation: anchoring to one known event so everything else can be measured against it.

   Windows

   Security log → filter Event ID 4624 (successful logon)

   Linux

   journalctl -b | grep -i "session opened"

3. 3

   Establish what normal looks like

   Scroll a full day. Find three things that happen every single day at roughly the same time — an update check, a backup, a scheduled task. Write them down. This is baselining, and it is the skill that separates people who spot a real intrusion from people who chase noise for a year.

4. 4

   Find the one that only happened once

   Now look for something that appears exactly once in the last week. A driver failure, an unexpected shutdown, a service that crashed. Read the surrounding twenty entries either side. Can you tell a story about what happened, and what happened next as a consequence?

5. 5

   Write the timeline

   Pick five events, put them in order with timestamps, and write three sentences explaining what occurred. Show it to someone non-technical. If they understand it, you have just done the part of security work that most people are worst at — the writing, which is what actually gets acted on.

PowerShell ships with Windows; bash ships with macOS and Linux. You already have everything you need.

1. 1

   Pick a real chore

   Not a toy problem — something that genuinely annoys you. Sorting a Downloads folder full of four hundred files. Renaming photos to a consistent format. Finding every file over 500MB. It has to be real, or the payoff at the end will not land.

2. 2

   Do it by hand once, and time it

   Actually time it. Write the number down. This is the figure you are going to beat, and it is also how you will one day justify automation work to a manager who wants to know why it is worth your afternoon.

3. 3

   Make a copy to work on

   Duplicate the folder. Everything from here runs against the copy. This is not caution for beginners — it is what people do professionally, because the cost of being wrong is asymmetric.

   Windows

   Copy-Item -Path .\Downloads -Destination .\Downloads-copy -Recurse

   macOS

   cp -R ~/Downloads ~/Downloads-copy

   Linux

   cp -R ~/Downloads ~/Downloads-copy

4. 4

   Ask what it WOULD do, before it does anything

   Run the operation in preview mode first. Nothing changes; it just tells you what it intends. Read that output properly. This habit is the single biggest difference between someone safe to give automation to and someone who is not.

   Windows

   Get-ChildItem .\Downloads-copy -File | Group-Object Extension | Format-Table Name, Count

   macOS

   find ~/Downloads-copy -type f | sed "s/.*\.//" | sort | uniq -c | sort -rn

   Linux

   find ~/Downloads-copy -type f | sed "s/.*\.//" | sort | uniq -c | sort -rn

5. 5

   Now let it run

   Sort every file into a folder named after its extension. Five lines or so. It will not work first time — read the error, change one thing, run it again. That loop, repeated, is the actual job.

   Windows

   Get-ChildItem .\Downloads-copy -File | ForEach-Object { $d = ".\Downloads-copy\" + $_.Extension.TrimStart("."); New-Item -ItemType Directory -Force -Path $d | Out-Null; Move-Item $_.FullName $d }

   macOS

   cd ~/Downloads-copy && for f in *.*; do d="${f##*.}"; mkdir -p "$d"; mv "$f" "$d"/; done

   Linux

   cd ~/Downloads-copy && for f in *.*; do d="${f##*.}"; mkdir -p "$d"; mv "$f" "$d"/; done

6. 6

   Compare it to your number

   You wrote down how long it took by hand. It now takes under a second, and it will take under a second every time from now on. Sit with that for a moment — that gap, multiplied across an organisation, is the entire economic argument for automation as a career.

A spreadsheet is enough — Excel, Numbers, or free LibreOffice. There is an optional SQL path at the end if you want it. No account needed.

1. 1

   Get something real and unhelpful

   Download a CSV from a public data portal — data.gov.uk, data.gov, or your national statistics office. Pick a subject you actually care about: crime near you, rainfall, energy prices, hospital waiting times. Deliberately do not pick a tutorial dataset. Real data is messy, and the mess is the job.

2. 2

   Write your question down before you look

   One sentence, on paper, before you open the file. "Has burglary in my area gone up or down over five years?" Doing this first is what stops you finding whatever the data happens to show and calling it a finding afterwards.

3. 3

   Meet the mess

   Open it. Find the problems: blank cells, dates in three formats, a total row hiding at the bottom that will corrupt every average you take, categories renamed halfway through the period. Write a list of every defect you find before you fix any of them.

4. 4

   Clean it, and keep a record of what you changed

   Fix the defects — but write down each decision as you go. "Dropped 214 rows with no date." "Treated blank as zero." Those decisions change the answer, and being unable to say what you did to the data is the difference between analysis and guessing.

5. 5

   Answer the question

   Pivot table, chart, or a formula. Get to a number. Then do the part almost everyone skips: try to disprove it. Is the trend just one anomalous year? Did the collection method change? Would a different but equally reasonable cleaning decision have flipped the result?

   Any

   Optional SQL path — sqlite3 ships with macOS and Linux:
   
   sqlite3 data.db
   .mode csv
   .import yourfile.csv t
   SELECT year, COUNT(*) FROM t GROUP BY year ORDER BY year;

6. 6

   Say it in three sentences

   What you found, how confident you are, and what it does not tell you. Show it to someone who has not seen the data. If they ask a question you cannot answer, that is not a failure — that is you discovering the limit of your own finding, which is the most valuable output of the whole exercise.

Nmap is free and open source. One install, no account, available for every platform.

1. 1

   Establish what your own network is

   Find your own address and the range your network occupies. You need to know precisely what you own before you touch anything, and getting this wrong is how people accidentally scan their neighbour or their ISP.

   Windows

   ipconfig

   macOS

   ifconfig | grep "inet "

   Linux

   ip addr

2. 2

   Find out what is actually on it

   A ping sweep of your own range. Count the results. Almost everyone finds more than they expected — a thermostat, a TV, a printer they thought was off, a doorbell, a device they cannot identify at all. That last category is the interesting one.

   Any

   nmap -sn 192.168.1.0/24        # adjust to YOUR range from step 1

3. 3

   Identify the one you cannot name

   Pick the device you could not identify. Ask what it is — services, guessed operating system, vendor from its hardware address. Then go and physically find it in your home. This is device profiling, and it is precisely what a network access control system does automatically, all day, at enterprise scale.

   Any

   nmap -A 192.168.1.42          # the unknown device on YOUR network

4. 4

   Practise against the one legal target

   The Nmap Project runs scanme.nmap.org for exactly this purpose. Scan it once or twice — not repeatedly — and compare what a deliberately exposed host looks like against your own devices. Read the open ports and ask what each one is for.

   Any

   nmap -A scanme.nmap.org

5. 5

   Ask the question that actually matters

   You now have a list of open ports. A scanner will tell you what is open; it will never tell you whether it matters. For each finding ask: is it reachable from outside my house, what would someone get if they took it, and is there a reason it is on at all? That reasoning — exposure and impact, not severity scores — is the whole difference between running a tool and doing the job.

6. 6

   Write it up as if for someone else

   Three findings, ranked by what you would fix first, with a sentence each on why. Include one you decided NOT to worry about, and say why. Being able to justify what you deliberately ignored is what separates a useful report from a wall of noise nobody acts on.

Your own machine’s logs and a command line. Nothing to install, no account.

1. 1

   Pick something that should be rare

   Choose one event that ought to happen occasionally but not constantly on your own machine: a failed login, a service crashing, a scheduled task failing, a USB device connecting. Rare-but-real is the sweet spot — common events make useless alerts and impossible events make rules you can never test.

2. 2

   Count it over thirty days

   Before writing any rule, find out how often it actually happened. This number is your baseline, and skipping this step is the single most common reason real detections get switched off within a fortnight for being too noisy.

   Windows

   Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625; StartTime=(Get-Date).AddDays(-30)} -ErrorAction SilentlyContinue | Measure-Object | Select-Object Count

   Linux

   journalctl --since "30 days ago" | grep -ci "authentication failure"

   macOS

   log show --last 30d --predicate 'eventMessage CONTAINS "Failed"' | wc -l

3. 3

   Write the rule

   Express your detection as something runnable — a filter, a grep, a query. Not pseudocode. It needs to actually execute so it can actually be wrong, which is the only way you will learn anything from it.

   Windows

   Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625; StartTime=(Get-Date).AddHours(-24)} -ErrorAction SilentlyContinue | Group-Object -Property @{e={$_.Properties[5].Value}} | Where-Object Count -ge 3

   Linux

   journalctl --since "24 hours ago" | grep -i "authentication failure" | awk '{print $NF}' | sort | uniq -c | sort -rn | awk '$1>=3'

4. 4

   Deliberately set it off

   Trigger the thing yourself — mistype your own password four times, plug in a USB stick. Does the rule fire? A detection you have never seen fire is not a detection; it is a hypothesis. Astonishing numbers of production rules have never been tested this way.

5. 5

   Now find out how wrong it is

   Run it across the full thirty days. Every hit that was not really an attack is a false positive — and every one of those, in a real SOC, costs a human being fifteen minutes. Calculate your rate. If it is above roughly one a day for one machine, imagine that multiplied by five thousand machines and ask whether anyone would keep it switched on.

6. 6

   Tune it once, and record what you gave up

   Narrow the rule to cut the noise — raise the threshold, exclude a known-good source. Re-run it. Then write down what you can no longer catch as a result. Every tuning decision trades coverage for signal, and being unable to state what you traded away is how organisations end up blind in ways nobody has documented.