Find out whether you like it before you pay for it.

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.

One free single-file download (Terraform). No account, no cloud provider, no credit card, and nothing here can cost you money — you will be creating files on your own disk, not servers. Delete the binary afterwards if you like.

1. 1

   Get the tool

   Download Terraform from terraform.io — it is a single executable. Put it somewhere on your PATH, or just work in the folder you downloaded it to. Check it runs.

   Any

   terraform -version

2. 2

   Describe something that does not exist yet

   Make a new empty folder and create a file called main.tf. You are not writing instructions here — you are describing a desired end state, and that distinction is the whole idea.

   Any

   terraform {
     required_providers {
       local = { source = "hashicorp/local" }
     }
   }
   
   resource "local_file" "hello" {
     filename = "${path.module}/out/hello.txt"
     content  = "built by terraform\n"
   }

3. 3

   Ask what it WOULD do

   Initialise, then run a plan. Read the output properly. It tells you exactly what will be created, changed or destroyed, and nothing has happened yet. This preview-before-acting habit is most of what separates infrastructure people who are safe from ones who are not.

   Any

   terraform init
   terraform plan

4. 4

   Make it real

   Apply it. Look in the out/ folder — the file exists. Now run plan again: it reports no changes, because reality already matches your description.

   Any

   terraform apply
   terraform plan

5. 5

   Break reality and watch it notice

   Delete the file it made, by hand. Run plan again. It has detected drift — reality no longer matches the description — and it tells you precisely how to get back. Apply again and it repairs itself. This is the moment the idea usually lands.

   Any

   terraform plan
   terraform apply

6. 6

   Add three more, then destroy everything

   Change the resource to create three files instead of one using count = 3. Plan, apply. Then run destroy: everything it made is gone, and only your description remains. You can rebuild it identically, forever, from four lines of text. That property is what the whole cloud industry is built on.

   Any

   terraform destroy

Needs one other person who is not technical, and a real problem they actually have. That is the only requirement, and it is the hard part.

1. 1

   Find a real complaint

   Ask a family member, housemate or friend what annoys them about their computer or phone. Do not accept a technical description — you want the raw version. "It's slow." "The printer never works." "It keeps logging me out." That vagueness is the actual starting condition of the job.

2. 2

   Resist fixing it for ten minutes

   This is the discipline the whole trial is built around. Ask questions instead. When did it start? What changed around then? Does it happen every time, or sometimes? Show me. Watch them do it — you will almost always see something they did not mention, because they did not know it mattered.

3. 3

   Reproduce it yourself

   Make the problem happen on demand, with your own hands. If you cannot reproduce it, you cannot know you have fixed it — you can only know it has stopped happening for now, which is not the same thing and will come back.

4. 4

   Halve the problem, repeatedly

   Is it that app or all apps? That network or all networks? That account or all accounts? Each answer eliminates half of what it could be. Keep going until only one thing is left. Notice how few questions this actually takes when you choose them well.

5. 5

   Fix it — then explain it without jargon

   Make the fix. Then tell them what was wrong in language they understand, without being condescending and without pretending it was harder than it was. Watch their face. This skill is worth more to an early IT career than any certification, and almost nobody practises it deliberately.

6. 6

   Write the runbook

   Five lines: the symptom, how to confirm it is this and not something else, the fix, and how to tell it worked. Written so someone else could follow it at 3am without ringing you. This is the artefact that turns a fix into an asset.

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.

Uses the account settings pages you already have. Nothing to install. You will likely also improve your own security materially, which is a decent side effect.

1. 1

   Find the account that owns all the others

   Start at your main email. Now list every service that would send a password reset there. That is not a list of accounts — it is a list of things someone gets for free the moment they take that one. Security people call this blast radius, and it is the single most useful concept in identity work.

2. 2

   Check what is actually guarding it

   Look at the security settings of that email account. Is there a second factor? Is it SMS — which is interceptable — or an app or hardware key? Now check the recovery options: an old phone number or a disused backup address is a back door that bypasses everything else you just checked.

3. 3

   Review what you have handed out

   Find the third-party access page on your Google, Microsoft or Apple account — the list of apps you signed in to using it. Most people have twenty to eighty entries and recognise perhaps half. Read what each was granted. Some will have read access to your entire mailbox from a service you used once in 2019.

   Any

   Google:    myaccount.google.com/permissions

   Any

   Microsoft: account.microsoft.com/privacy → apps and services

   Any

   Apple:     appleid.apple.com → Sign in with Apple

4. 4

   Revoke, and notice how that feels

   Remove everything you do not currently use. Notice the hesitation — "what if something breaks?" That exact hesitation, multiplied across ten thousand employees and twenty years, is why organisations accumulate permissions nobody dares remove. You are feeling the central problem of identity engineering firsthand.

5. 5

   Check the sessions still open

   Most services list active sessions and signed-in devices. Look for a device you no longer own or a location you do not recognise. Sign them all out. Note how many services do not offer this at all — that absence is itself a finding.

6. 6

   Write the one-page assessment

   What is your most valuable account? What is the weakest path into it — is it the password, the second factor, the recovery method, or an app you granted access to years ago? What would you fix first if you had one hour? That prioritised write-up is exactly the deliverable an identity or GRC role produces, and doing it for yourself is the cheapest possible practice.

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.

A text editor and a browser. No install, no server, no account — the page runs from a file on your desktop.

1. 1

   Build something that works

   Save this as a file called app.html and open it in your browser. It is a greeting page that takes a name. Use it normally first — type your own name, see it work. Everything you build starts here: correct, for the input you imagined.

   Any

   <!doctype html>
   <input id="n" placeholder="your name">
   <button onclick="go()">Greet</button>
   <div id="out"></div>
   <script>
   function go() {
     const name = document.getElementById("n").value;
     document.getElementById("out").innerHTML = "Hello, " + name + "!";
   }
   </script>

2. 2

   Type something that is not a name

   Now put this in the box instead and press the button. Something will happen that the author did not intend and did not anticipate. You have just done the fundamental move of application security: supplying input the designer never pictured.

   Any

   <img src=x onerror="alert('this is now my page')">

3. 3

   Work out precisely why it worked

   The code never asked for code — it asked for a name. But it glued your text into the page as markup rather than as text, so the browser did what browsers do and executed it. Sit with that: the flaw is not the alert box, it is that data and instructions were allowed to occupy the same channel. Nearly every major vulnerability class is a variation of that one sentence.

4. 4

   Escalate it

   An alert box proves nothing to anyone. Change your payload so it reads something real from the page instead — the document title, a cookie you set yourself, the contents of another element. Proving actual impact rather than mere possibility is the difference between a finding a developer fixes and one they close as noise.

   Any

   <img src=x onerror="document.getElementById('out').textContent = document.title">

5. 5

   Fix it — the right way and the wrong way

   First fix it badly: filter out the word "script". Then defeat your own filter — the payload above never used that word. Now fix it properly by changing innerHTML to textContent, so the input is treated as text and can never be instructions. Try every payload again. This contrast, blocklist versus correct handling, is the single most useful lesson in the whole trial.

   Any

   document.getElementById("out").textContent = "Hello, " + name + "!";

6. 6

   Go looking for the same shape elsewhere

   Where else does something you have written take input and put it somewhere with meaning — a filename, a database query, a shell command, a URL? Write down three. You now have the pattern-recognition that application security work actually consists of, and it transfers to every language you will ever use.

Paper and a pen. Deliberately no tools — the constraint is the point, because architecture is thinking, not diagramming software.

1. 1

   Draw what you actually have

   Your home network, on one sheet. Router, every device, how each connects. If you did the exposure trial you already have the inventory; if not, list them from memory and then check — the gap between what you remembered and what is really there is itself the first finding, and it is the same gap every organisation has.

2. 2

   Draw the lines nothing crosses

   Now mark what can reach what. On a normal home network the honest answer is everything reaches everything — your work laptop, your smart bulb, a guest's phone, the doorbell camera all sit in one flat space. Draw that reality, not the reality you would prefer.

3. 3

   Name the thing that actually matters

   Of everything on that page, what would genuinely hurt to lose or have taken? Usually one or two things: the machine with your work on it, the drive with the family photos. Circle them. Everything else on the diagram exists, in security terms, mainly as a route toward those.

4. 4

   Pick the worst device and follow it

   Choose the least trustworthy thing on the network — the cheapest smart device, the one that has not had a firmware update in three years. Trace, on the diagram, exactly what it can reach if someone takes it. That path is your blast radius, and drawing it is more persuasive than any risk score you could write down.

5. 5

   Redesign it, on a second sheet

   Draw the version where that cannot happen. A separate network for untrusted devices. The important machine somewhere the doorbell cannot reach. Guest access that is genuinely separate. You do not have to build it — you have to be able to justify it.

6. 6

   Now write down what your design costs

   This is the step that separates architecture from wishful thinking. What breaks? Casting to the TV probably stops working. Someone has to maintain two networks. A guest cannot print. Write the honest list, then decide which trade-offs you would actually accept and which you would not. If you cannot articulate the cost of your own design, you will lose every real architecture argument you ever have.

Built-in wireless tools plus your own feet. The optional hardware section needs a computer you own and are willing to open — no purchase required.

1. 1

   Measure what you have been assuming

   Find your current signal strength, right now, where you are sitting. Note the number and the units — dBm is a negative figure where closer to zero is better, and −50 is excellent while −80 is barely usable.

   Windows

   netsh wlan show interfaces

   macOS

   Hold Option, click the Wi-Fi menu — or open Wireless Diagnostics from Spotlight

   Linux

   iw dev wlan0 link    # or: nmcli -f IN-USE,SSID,SIGNAL,CHAN dev wifi

2. 2

   Walk the building and write numbers down

   Take a reading in every room, and at the far corner of each. Write them on a rough floor plan. You are producing a coverage survey — the same artefact, at smaller scale, that a wireless engineer produces before a hospital or a warehouse deployment.

3. 3

   Find the wall that eats your signal

   Look for the sharp drop, not the gradual fade. A gentle decline is distance; a cliff between two adjacent readings is something physical — a wall with foil-backed insulation, a mirror, a boiler, a fridge, a chimney. Go and identify the actual object. This is the moment radio stops being theoretical.

4. 4

   Discover you are not alone on the air

   List the networks around you and the channels they occupy. Count how many are on the same channel as yours. Wi-Fi is a shared medium in a public commons — your neighbour's router degrades yours, and no configuration on your side can fully fix it. That constraint is the defining fact of wireless work.

   Windows

   netsh wlan show networks mode=bssid

   Linux

   nmcli -f SSID,CHAN,SIGNAL dev wifi list

   macOS

   Wireless Diagnostics → Window → Scan

5. 5

   Trace one cable end to end

   Pick any cable in your home — the one from the wall to the router. Follow it physically to both ends. Where does it enter the building, and what is on the other side of that wall? Almost nobody knows. Documenting exactly this, across a building, is a real job that real people are paid to do because the records are always wrong.

6. 6

   Optional — open something and name every part

   Power off, unplug, ground yourself, then open a desktop or an old laptop you own. Identify: the processor and its cooler, the memory, the storage, the power supply, the fans. Trace where the air enters and leaves. Ask where the heat goes. Now imagine ten thousand of these in one room — that question of heat, power and airflow is most of what data centre design actually is.