Labs and discussion
Verification & Reporting — 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.
Lab 1: Verification Challenge
- Objective: Decide whether each image matches its claimed caption, using a repeatable verification workflow, and state confidence.
- Time: 45–60 minutes / Difficulty: Beginner–Intermediate
- Setup / what the instructor prepares:
- A set of 6–8 images, each with a written claim (caption, place, date). Use only photos you took yourself, or public-domain / Creative Commons images whose true origin you know. Avoid images showing identifiable private individuals.
- Mix the set:
- 2 authentic images with accurate captions
- 2 misattributed images: real photos with the wrong place or date in the caption (e.g., your own photo from 2023 captioned as “this morning”)
- 1 edited image (object added or removed with an image editor)
- 1 AI-generated image you created yourself, captioned as a real event
- 1 image with EXIF data intact (GPS and date) and 1 with metadata stripped
- Strip metadata where needed:
exiftool -all= image.jpg(exiftool keeps a backup namedimage.jpg_original) - Keep a private answer key with the true origin of every image.
- Steps:
1. For each image, run reverse image searches on at least two engines (Google Lens, Bing Visual Search, Yandex Images, TinEye).
2. Check metadata withexiftoolor the InVID-WeVerify plugin.
3. Check the location using maps and street-level imagery.
4. Check the time using shadows (SunCalc), weather history, and visible clues.
5. Examine the image with the InVID-WeVerify Magnifier and Forensic tabs. Note anything suspicious, but remember forensic filters are easy to misread.
6. Decide: Claim supported, Claim false, or Cannot verify.
7. Grade your confidence (high / moderate / low) and explain why. - Deliverable: A verification worksheet:
| Image | Claim | Verdict | Key evidence | Confidence | Evidence captured (file + SHA-256) |
|---|---|---|---|---|---|
- Debrief questions:
- Which images were hardest? Why?
- Did anyone call an authentic image fake? What misled you?
- For the AI image, what gave it away: the pixels, or the lack of provenance and corroboration?
- How many “Cannot verify” verdicts did you give? Why is that a legitimate answer?
Lab 2: Analysis of Competing Hypotheses
- Objective: Use an ACH matrix to evaluate competing explanations and write a judgment with estimative language.
- Time: 40–50 minutes / Difficulty: Intermediate
- Setup / what the instructor prepares: Hand out the scenario and evidence cards below (print or share digitally). Groups of 3–4.
- Scenario (fictional): A screenshot is spreading on social media that appears to show an internal Company X email from the HR director announcing large layoffs. Company X’s security team (the client) asks: What is this screenshot?
- Hypotheses:
- H1: A genuine, recent internal email that was leaked
- H2: A fabricated (edited) screenshot
- H3: A genuine email from Company X’s 2023 restructuring, reshared as new
- H4: A phishing simulation email from Company X’s own security team
- Evidence cards (E6 and E7 come from the client as part of the authorized engagement):
- E1: The screenshot shows Company X’s current logo, introduced in March 2026.
- E2: The sender’s name matches the real HR director listed on Company X’s public website.
- E3: The email’s date line reads “Sunday, 14 September 2026.” 14 September 2026 was a Monday.
- E4: Company X’s IT team says the font and signature layout don’t match the company’s standard email template.
- E5: The screenshot was first posted by an account created two days earlier with no other posts.
- E6: Company X’s mail logs for the past five years show no email with that subject line.
- E7: The security team confirms no phishing simulation has run this quarter.
- E8: Reverse image searches find no copies of the screenshot before this week.
- E9: The image has no metadata (downloaded from social media).
- Steps:
1. Build the matrix: hypotheses across the top, evidence down the side.
2. Mark each cell C (consistent), I (inconsistent), or N/A.
3. Remove evidence that’s consistent with every hypothesis.
4. Count inconsistencies. Which hypothesis survives best?
5. Sensitivity check: which one or two cards drive your answer? What if one of them is wrong?
6. Write a 3–4 sentence judgment using ICD 203 likelihood terms and a separate confidence statement.
7. List two milestones that would change your assessment. - Deliverable: Completed matrix and written judgment.
- Instructor answer key (one reasonable solution):
| Evidence | H1 Recent leak | H2 Fabricated | H3 Old 2023 email | H4 Phishing sim |
|---|---|---|---|---|
| E1 Current logo (2026) | C | C | I | C |
| E2 Real HR director’s name | C | C | C | C |
| E3 Wrong weekday in date | I | C | I | I |
| E4 Template doesn’t match | I | C | C | C |
| E5 New account posted it | C | C | C | C |
| E6 No such email in logs | I | C | I | N/A |
| E7 No phishing sim running | C | C | C | I |
| E8 No earlier copies online | C | C | I | C |
| E9 No metadata | C | C | C | C |
| Inconsistencies | 3 | 0 | 4 | 2 |
- E4 is marked C for H3 because the email template may have changed since 2023.
- E2, E5, and E9 are non-diagnostic (consistent with everything). E2 is public information anyone could copy.
- E3 is highly diagnostic: real email software generates the correct weekday automatically.
- Sample judgment: “We assess the screenshot is very likely fabricated. It contains an incorrect weekday that email software would not produce, does not match Company X’s email template, and no matching email appears in five years of mail logs. We have moderate-to-high confidence; the assessment relies partly on client-provided mail logs.”
- Accept other reasonable markings if groups justify them; the discussion matters more than the exact grid.
- Debrief questions:
- Which evidence was most diagnostic? Which evidence felt important but wasn’t?
- Did your group start with a favorite hypothesis? Did the matrix change anyone’s mind?
- How would a determined fabricator avoid the mistake in E3?
Lab 3: Write the Report
- Objective: Turn raw findings into a clear, minimized, audience-appropriate report.
- Time: 60–90 minutes (can be homework) / Difficulty: Intermediate
- Setup / what the instructor prepares: Distribute the raw analyst notes below for a fictional organization, Lakeside Logistics (
lakeside-logistics.example). Provide the report and finding templates from 7.4-writing-osint-reports.md. - Raw analyst notes (deliberately messy):
1.EV-01Job posting (careers page) asks for “3+ years administering and .” Captured 2026-09-10T15:02Z.
2.EV-02crt.sh showsvpn.lakeside-logistics.exampleanddev-portal.lakeside-logistics.example. Captured 2026-09-10T15:20Z.
3.EV-03Public repolakeside-dev/portalhas a commit addingDB_PASSWORD=Summer2026!insettings.py. Captured 2026-09-10T16:05Z.
4.EV-04Email format confirmed asf.lastname@lakeside-logistics.examplefrom website contact page and two press releases.
5.EV-059 employees list IT roles on professional networking profiles; one is the sole domain administrator.
6.EV-06The domain administrator’s public personal social media shows their child’s school name and daily drop-off time.
7. Anonymous forum post claims Lakeside Logistics “got ransomwared last month.” No other source found. No capture taken.
8.EV-07Same crt.sh result as note 2, captured again by a second analyst.
9. Analyst note: “Tried logging into dev-portal with admin/admin to see if it works.” - Steps:
1. Sort the notes: which are findings, which are duplicates, which are unverified, and which are problems?
2. Decide what to exclude or handle separately, and why (hint: notes 6, 7, and 9).
3. Write an executive summary of 200 words or fewer for the company’s leadership.
4. Write a Summary of Findings table with risk and confidence ratings.
5. Write two full findings using the finding template, including evidence tables.
6. Write a prioritized recommendations table.
7. Add a Limitations section that honestly states what’s unverified. - Deliverable: A report of 2–4 pages in Markdown or a document format.
- Grading checklist:
- The executive summary is plain language with bottom line up front
- The password in note 3 is masked (e.g.,
Summ****) and never shown in full - Note 6 is excluded: it’s unnecessary, sensitive information about a family member and a minor
- Note 7 is either left out or listed as an unverified claim with low confidence, not as a finding
- Note 9 is flagged as a scope violation (attempting a login is active and unauthorized) and raised with the instructor/team lead rather than reported as a finding
- Notes 2 and 8 are merged into one finding with both evidence IDs
- Every finding has evidence IDs, risk, and confidence
- Names are replaced by roles and counts in the main body
- Recommendations are specific and prioritized
- A handling label (e.g., TLP:AMBER+STRICT) is on the report
- Debrief questions:
- What did you leave out, and how did you decide?
- How did your executive summary differ from your technical findings?
- What should happen when a teammate does something out of scope, like note 9?
Lab 4: Capture, Hash, and Verify (Documentation Drill)
- Objective: Practice capture-as-you-go documentation and prove file integrity with hashes.
- Time: 30–40 minutes / Difficulty: Beginner
- Setup / what the instructor prepares: Choose 3 approved public pages (for example, pages on an instructor-owned site or specific Wikipedia articles). Prepare to secretly change one byte in one student file during the swap (e.g., re-save a screenshot) to demonstrate a hash mismatch.
- Steps:
1. Create the case folder structure from 7.3-documentation-and-evidence.md.
2. Check your clock is synced; record all times in UTC.
3. For each page: take a full-page screenshot, save the page (SingleFile or view-source), and record the URL.
4. Name files using the convention<date>_<time>Z_<site>_<description>.
5. Hash everything:sha256sum * > hashes.sha256(Linux),shasum -a 256(macOS), orGet-FileHash -Algorithm SHA256(Windows).
6. Fill in the investigation log, including one search that returned nothing.
7. Swap folders with a partner. The partner verifies withsha256sum -c hashes.sha256(or compares PowerShell output).
8. The instructor alters one file; the class observes the mismatch. - Deliverable: Case folder with evidence, hash list, and a completed investigation log.
- Debrief questions:
- What does a matching hash prove, and what doesn’t it prove?
- Could your partner reproduce your steps from your log alone?
- What would you need to add for this to hold up as court evidence (think Berkeley Protocol)?
Discussion Questions
- A single dramatic video of an “explosion” is being shared by thousands of accounts, including several with blue checks. What would you need to see before calling it confirmed?
- You find five news articles confirming a claim. How do you check whether they are actually independent?
- Two accounts share a common name and the same city. What additional identifiers would you require before linking them, and why?
- Your AI-detection tool says an image is “92% likely AI-generated.” How should that result appear in your report, if at all?
- Why does ICD 203 say not to put a likelihood term and a confidence level in the same sentence? Rewrite this sentence to fix it: “We are highly confident the breach is likely old.”
- A source with a history of accurate reporting (B) passes on a claim that contradicts three other independent sources. How would you grade the information, and why does the Admiralty Code separate the two ratings?
- Saving a page to the Wayback Machine makes your evidence independently verifiable, but it’s public. When is that trade-off worth it?
- The Boston Marathon and Charlottesville misidentifications were driven by people who wanted to help. What specific verification steps would have prevented each one?
- A client asks you to include employees’ home addresses “for completeness.” How do you respond?
- Your report accidentally went to the wrong recipient. What should your handling practices have done to limit the damage, and what do you do now?
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.