Labs and discussion

OPSEC — Labs & Discussion

Rules for every lab: passive techniques only unless the lab says otherwise; only approved targets (yourself, consenting classmates, instructor-provided or instructor-owned targets, purpose-built practice sites); don’t share findings about real people outside class.

OPSEC-specific rules: check your campus/network acceptable use policy before using VPNs or Tor on the school network. Don’t create sock puppet accounts on real platforms for these labs. Blur or crop IP addresses before projecting any results.

Lab 1: Build and Leak-Test a Research Environment

Objective: Set up a separated research browser (and optionally a VM), then measure what it still reveals compared with your everyday browser.
Time: 45–60 minutes / Difficulty: Beginner
Setup / what the instructor prepares:
A link to the Trace Labs OSINT VM releases page (github.com/tracelabs/tlosint-vm) or a pre-downloaded image on a USB drive/share (optional part)
Confirmation of whether VPN/Tor use is allowed on the classroom network; if not, skip those steps or provide an approved alternative
A results table template (below)
Steps:
1. Baseline. In your everyday browser, visit:
- ipleak.net: note IP, location, DNS servers, IPv6
- browserleaks.com/webrtc: note any IPs shown
- coveryourtracks.eff.org: run the test and note whether your fingerprint is unique
- amiunique.org: note what makes your browser stand out
  2. Research profile. Create a new Firefox profile (about:profiles) or install Mullvad Browser. In Firefox, add the Multi-Account Containers extension and create two containers: “Logged-out research” and “Research account A.”
  3. Repeat the four tests in the research profile. What changed? What didn’t?
  4. Network (if permitted). Connect an approved VPN or open Tor Browser and repeat the tests. Try Tor Browser at the “Safest” security level and note which test pages break.
  5. Fix one leak. If WebRTC shows your real IP, fix it (VPN setting, or media.peerconnection.enabled = false in the research profile’s about:config) and retest.
  6. Optional VM. Import the Trace Labs OSINT VM (or another distro), change the default osint/osint password, disable shared clipboard and folders, take a snapshot named with today’s date, and repeat step 1 inside it. Note that the VM alone doesn’t change your public IP.
Deliverable: a completed table plus three remaining ways your setup could still be identified, with a proposed fix for each.

Test	Everyday browser	Research profile	+ VPN/Tor	Notes
Public IP
DNS servers
WebRTC IPs
IPv6
Fingerprint unique?
- Debrief questions:
- Why didn’t a new browser profile change your IP address?
- Why might a heavily customized “privacy” browser be more unique than a default one?
- What would change if you ran this lab from the campus network while researching a real target?

Lab 2: Canary Token Demo (Instructor-Run)

Objective: See firsthand how opening a “found” file or link can reveal an investigator, and practice safe handling.
Time: 30 minutes / Difficulty: Beginner
Setup / what the instructor prepares:
1. At canarytokens.org, create (with the instructor’s email for alerts):
- A Web bug / URL token
- A Microsoft Word document token named something tempting, such as CompanyX_VPN_passwords.docx
- Optionally a DNS token
  2. Build a fictional scenario: “During an authorized assessment of Company X (fictional), you found a public file share containing this document and a link in a text file.”
  3. Put the files where students can get them (class LMS or a shared drive), clearly labeled as a lab.
  4. Tell students up front that the lab involves tracking tokens and that alerts will show the classroom network’s IP (consent), without saying which items are tokens.
Steps:
1. Students decide, in writing, what they would do with each item before touching anything: open it on the host, open it in a VM, open it in an offline VM, only record its hash, or leave it alone.
2. Students who choose to open items do so however they decided.
3. The instructor displays the Canarytokens alert history (with IPs blurred): time, IP, user agent, and which token fired.
4. As a class, match alerts to handling choices. Which choices triggered alerts? Did anyone’s “safe” approach still trigger one (for example, a VM that was online)?
5. Demonstrate safer handling: compute a hash (sha256sum CompanyX_VPN_passwords.docx), inspect metadata with exiftool, and discuss opening files only in an offline, disposable VM.
Deliverable: a short written “found file handling procedure” (5–7 steps) for your future investigations.
Debrief questions:
What did the alert reveal about the person who opened the file?
How could a target or threat actor use this against an investigator?
Why is “try the passwords in the file” both a legal problem and an OPSEC problem?
Why is a DNS token harder to avoid than a web bug?

Lab 3: Spot the Mistakes (Scenario Review)

Objective: Apply the five-step OPSEC process to realistic (fictional) scenarios by finding mistakes, ranking risk, and proposing countermeasures.
Time: 30–40 minutes / Difficulty: Beginner–Intermediate
Setup / what the instructor prepares: Print or share the three scenarios below; split the class into small groups.
Steps:
1. Each group reads one scenario and lists every OPSEC mistake it can find.
2. For each mistake, rate likelihood and impact (High/Medium/Low).
3. Propose a countermeasure for each.
4. Groups present their top three mistakes.
Deliverable: a table of mistakes → risk → countermeasure for your scenario.

Scenario A: Jordan’s first assessment

Jordan, a junior analyst at a consulting firm, is doing an authorized OSINT assessment of Company X before a phishing test. Only Company X’s CISO knows. On Monday morning, from the firm’s office network, Jordan:
- Opens Chrome, still signed into a personal Google account with sync on
- Views 40 Company X employee profiles on LinkedIn with a personal profile in public mode, all within 20 minutes
- Submits Company X’s VPN login page to urlscan.io with default settings
- Finds an open cloud storage folder containing passwords.xlsx, downloads it, and opens it in Excel on the laptop
- Posts on LinkedIn at lunch: “Excited for a big recon week with a Fortune 500 client in Denver!”
- Emails the client a report PDF whose properties show “Author: Jordan Smith” and a file path containing the firm’s internal server name

Scenario B: Monitoring a threat actor channel

Sam, a threat intel analyst with approval to monitor a ransomware group’s public Telegram channel:
- Joins the channel with a personal Telegram account registered to a personal phone number
- Uses the display name “k1ngf1sher,” the same handle as a personal gaming account
- Clicks a shortened link posted in the channel, from a work laptop without a VM
- Takes a phone photo of the screen (location services on) and shares it with the team through a public paste site

Instructor answer key (not exhaustive): personal account and phone number link to real identity (use the t.me/s/ web preview or an approved research account); reused handle enables username pivoting back to Sam; the short link may be an IP logger that reveals Sam’s employer and VM/no-VM status (don’t click, or examine via a private scan); the phone photo may contain GPS EXIF data; a public paste exposes the investigation (use private, approved storage).

Scenario C: A careless persona

An analyst creates a persona called “Emily Carter” for passive LinkedIn viewing:
- Uses a profile photo copied from a real Instagram influencer
- Creates the account from home Wi-Fi
- Lists Chicago as her location, but the account is always active 2–5 a.m. Chicago time and uses British spellings
- Follows the analyst’s real account “to make it look active”
- Uses the analyst’s personal phone number for verification “just this once”

Instructor answer key (not exhaustive): a stolen photo harms a real person and is easily found by reverse image search; the home IP links the persona to the analyst; the location, time, and spelling mismatches are indicators; following the real account links the identities directly; the personal phone number links them permanently and may trigger “People You May Know” suggestions. Also discuss whether this persona was needed at all (logged-out view, private mode, client access) and whether the rules of engagement allow it.

Debrief questions:
Which mistake in your scenario was the hardest to spot? Why?
Which mistakes are permanent even after they’re “fixed”?
Which countermeasures cost nothing?

Lab 4 (Optional): Metadata Cleanup Drill

Objective: Find and remove identifying metadata in your own files before sharing.
Time: 20 minutes / Difficulty: Beginner
Setup / what the instructor prepares: A sample Word document and PDF created with a fake author name and comments, plus a photo taken by the instructor with location services on at a non-sensitive public location (e.g., campus quad).
Steps:
1. Run exiftool on each file and list every identifying field.
2. Remove metadata (exiftool -all= photo.jpg; use the Office “Inspect Document” feature for the Word file; re-export the PDF).
3. Re-run exiftool and confirm what’s left.
4. Bonus: create a PDF with a black box drawn over text, then try to copy the “hidden” text.
Deliverable: before/after metadata listings and a pre-sharing checklist.
Debrief questions:
What would the McAfee or w0rmer cases have looked like if the photos had been cleaned?
Where else in your workflow might metadata slip out (screenshots, exports, chat uploads)?

Lab 5 (Optional): Route a Tool Through Gluetun

Objective: Put a research tool (not your whole machine) behind a VPN with a kill switch, then prove it can’t leak your real IP.
Time: 30–45 minutes / Difficulty: Intermediate (needs Docker)
Setup / what the instructor prepares:
A machine or VM with Docker and Docker Compose
VPN credentials from an approved provider (or an instructor-run WireGuard endpoint), shared securely rather than in a slide or chat
Confirmation that VPN use is allowed on the classroom network
The docker-compose.yml from 8.2-building-a-research-environment.md, with a small tool container (e.g., alpine) as research-tool
Steps:
1. Verify the source. Open github.com/qdm12/gluetun and note that it redirects to github.com/passteque/gluetun. Record three signals that this is the official project and not a lookalike (redirect, repo history/stars, maintainer’s README notice, image names).
2. Baseline. Without Gluetun, run docker run --rm alpine:3.22 sh -c "apk add wget && wget -qO- https://ipinfo.io" and note the IP and location (blur it before sharing).
3. Start Gluetun. Put the VPN credentials in gluetun.env, run docker compose up -d, and check docker logs gluetun until the VPN is connected.
4. Check the exit IP. Run docker run --rm --network=container:gluetun alpine:3.22 sh -c "apk add wget && wget -qO- https://ipinfo.io" and compare it with step 2.
5. Test the kill switch. Start a long-running container attached to Gluetun (e.g., docker run -d --name leaktest --network=container:gluetun alpine:3.22 sleep 3600). Stop the gluetun container, then try docker exec leaktest wget -qO- https://ipinfo.io. It should fail instead of showing your real IP. Clean up with docker rm -f leaktest.
6. Secrets check. Confirm gluetun.env is listed in .gitignore and was never pasted anywhere shared.
Deliverable: a before/after table (IP, location, DNS provider) and a short answer: what does this setup still not protect?
Debrief questions:
What can the VPN provider still see?
Why doesn’t Gluetun fix browser fingerprinting or a logged-in account?
How would you use two Gluetun containers to keep two personas from sharing an exit IP?
How would an attacker abuse a lookalike “Gluetun” repo or image, and what would they gain?

Discussion Questions

A classmate says, “I only look at public profiles, so OPSEC doesn’t matter.” How would you respond?
Walk through the five OPSEC steps for researching a local business’s email format for an authorized phishing test. How much effort is appropriate?
When is Tor a worse choice than a VPN for OSINT? When is it better?
LinkedIn private mode hides your name but still shows that someone viewed a profile. When is that still a problem?
Is using an AI-generated face for a sock puppet ethical? What are the arguments on both sides, and how does your answer change if the persona is only used passively?
Ross Ulbricht’s “altoid” posts were made before Silk Road even launched. What does that teach about when OPSEC needs to start?
The popular story of how Sabu was caught is disputed. Why does it matter for investigators to verify even “well-known” facts?
Your team finds a file that looks like a canary token in a client’s exposed storage. What do you do, and what do you put in the report?
What’s the difference between OPSEC for an investigator and privacy for an ordinary person (Module 9)? Where do they overlap?
You realize mid-investigation that you’ve been logged into your personal account the whole time. What steps do you take next?

References

Free to use, copy, change and teach. Security For the Folks dedicates this course to the public domain under CC0 1.0 Universal: no permission or credit needed. Quoted material and the sources it links to belong to their own authors.