Defending Against OSINT — 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: OSINT Yourself Audit

• Objective: Find out what a stranger can learn about you online, and rank what you find by risk.
• Time: 45–60 minutes / Difficulty: Beginner
• Setup / what the instructor prepares:
• Share 9.1-auditing-your-personal-footprint.md and a blank tracking sheet template (columns: #, what was found, where, identifier, who can see it, risk, action, status).
• Remind students that the sheet is private and should be stored somewhere secure. Students never share the details, only categories.
• Offer an alternative for anyone uncomfortable auditing themselves: audit a fictional persona the instructor created.
• Steps:
  1. Build your identifier list (names, usernames, emails, phone numbers, previous addresses, profile photos).
  2. Open a private browser window and stay logged out.
  3. Work through the checklist: search engines, usernames (WhatsMyName or Sherlock), emails (Have I Been Pwned), phone numbers, social media from the outside, reverse image search of your profile photos, people-search sites, stealer-log check (Hudson Rock free lookup), public records, old accounts.
  4. Record each finding in your tracking sheet.
  5. Rate each finding High / Medium / Low using the risk table.
  6. Answer the “think like an attacker” questions: Could someone find your home? Your routine? Your security question answers? Impersonate you?
• Deliverable: A short reflection submitted to the instructor that lists categories only (for example, “home address on 2 people-search sites,” “old forum account with real name,” “email in 3 breaches”), your top 3 risks, and one action you’ll take this week. Keep the detailed sheet private.
• Debrief questions:
• What category surprised the class most (by show of hands, not details)?
• Which findings did you post yourself, and which did someone else post?
• Which single piece of information would be most useful to an attacker, and why?
• How long would it take a motivated stranger to find what you found?

Lab 2: Organizational OSINT Self-Assessment

• Objective: Run an authorized OSINT assessment of an organization and turn findings into a fix list with owners.
• Time: 60–90 minutes / Difficulty: Intermediate
• Setup / what the instructor prepares:
• A fictional organization pack or an instructor-owned domain. A good pack includes:
  • A simple website with a “team” page and a contact page showing the email format
  • One or two job postings that overshare the tech stack
  • Two or three PDFs/Office files containing author names, internal file paths, and software versions in the metadata (plus one with a “black box” fake redaction over text)
  • DNS records on the instructor’s domain, including a stale vendor verification TXT record and a CNAME pointing to a deleted resource on a service the instructor controls (do not leave a real takeover opportunity live on the internet; point it somewhere harmless or describe it on paper)
  • A demo code repository with a clearly fake API key in an old commit
• A written “authorization letter” from the fictional company defining scope.
• Steps:
  1. Read the authorization and scope. Note what’s out of scope.
  2. Enumerate subdomains with crt.sh and check DNS records with dig (A, MX, TXT, CNAME).
  3. Identify vendors from TXT records and the tech stack from job postings.
  4. Download the published documents and inspect them with exiftool -a -G1. Try copying text from under the fake redaction.
  5. Scrub one document: use Microsoft Office’s Document Inspector, exiftool -all= (images), or mat2, then re-run exiftool to confirm the metadata is gone.
  6. Scan the demo repo with gitleaks git -v <repo> and find the fake key in history.
  7. Determine the email format from the website.
  8. Fill in an exposure table: exposure → risk → recommended fix → owner.
• Deliverable: A one-page report with a short executive summary and the exposure table (use the report structure from Module 7).
• Debrief questions:
• Which finding would you fix first, and why?
• Which exposures can’t be removed (like SPF records) and just need to be accepted?
• Why is deleting the commit not enough for the leaked key?
• How would you rewrite the job posting so it still attracts qualified candidates?

Lab 3: Lookalike Domain Hunt with dnstwist

• Objective: Find registered lookalike domains and practice deciding which ones are a threat.
• Time: 30–45 minutes / Difficulty: Beginner–Intermediate
• Setup / what the instructor prepares:
• An instructor-owned domain (or a well-known domain the instructor designates for a read-only demo, running only the DNS-lookup features).
• A Linux VM (Kali includes dnstwist via apt) or the dnstwist.it web interface as a fallback.
• Optional: register one or two lookalikes of the instructor’s own domain ahead of time so students have something to find.
• Steps:
  1. Install dnstwist (sudo apt install dnstwist or pip install dnstwist[full]).
  2. Run dnstwist --format list <domain> to see raw permutations (no lookups). How many are there?
  3. Run dnstwist --registered <domain> to see which are registered.
  4. Add -m to check for mail servers on the lookalikes.
  5. Export to CSV (--format csv) and classify each result: parked, legitimate (another real business), defensive registration, or suspicious.
  6. For suspicious ones, look up the registrar and hosting provider via RDAP/WHOIS and note where you’d send an abuse report.
  7. (Optional, VM only) Try --lsh or --phash to compare lookalike pages to the real site. Only do this in an isolated VM, because these options fetch pages from possibly malicious sites.
  8. (Stretch) Write the cron-based monitoring script from 9.5-monitoring-and-early-warning.md and test it by running it twice.
• Deliverable: A table of registered lookalikes with a classification and recommended action for each.
• Debrief questions:
• Which permutation types were most common among registered domains?
• Why does an MX record on a lookalike domain matter?
• Which typos would you defensively register, and which would you just monitor?
• Why is it important to alert on new lookalikes instead of the full list every day?

Lab 4: Personal Privacy Hardening Sprint

• Objective: Apply concrete privacy and security changes to your own accounts.
• Time: 30–45 minutes / Difficulty: Beginner
• Setup / what the instructor prepares:
• Share 9.2-reducing-personal-exposure.md.
• Provide a checklist handout. Students don’t need to reveal account names or show their screens.
• Steps (complete what applies to you; mark the rest “N/A”):
  1. Pick two social platforms you use and run their privacy checkup or apply the settings from the notes (private account, limit past posts, tag review, public profile sections, discoverability by phone/email).
  2. Turn off location tagging in your phone’s camera settings.
  3. If you use a fitness app, set map visibility to hide your start and end points (or hide maps entirely).
  4. Create an email alias with a free alias service and use it for your next sign-up.
  5. Change one account’s security question answers to random values stored in your password manager.
  6. Turn on a passkey or authenticator-app MFA for your primary email account.
  7. Sign up for Have I Been Pwned notifications for your main email address.
  8. (Optional) Set up Google “Results about you” and review any results it finds.
  9. (Optional) Delete one old account you found in Lab 1.
• Deliverable: The completed checklist (done / not done / N/A) with a sentence on which change felt most important.
• Debrief questions:
• Which change took the least effort for the most benefit?
• What made some changes hard to find or complete? (Platforms often bury privacy settings.)
• Which of these changes would have stopped something you found in Lab 1?
• What would you recommend to a family member who isn’t technical?

Discussion Questions

1. Is it realistic to “disappear” from the internet? What’s a more achievable goal?
2. Data brokers argue they only compile public information. Should aggregation of public data be regulated? Why or why not?
3. Consumer Reports found manual opt-outs outperformed most paid removal services. When would a paid service still make sense?
4. California’s DROP lets residents send one deletion request to every registered data broker. What are its limits, and should other states copy it?
5. An employee posts a “first day!” photo with their badge visible. How should the company respond without discouraging employees from celebrating their jobs?
6. How much technical detail should a job posting include? Where’s the line between recruiting and oversharing?
7. A developer pushes an API key to a public repo and deletes it five minutes later. Is the company safe? What should happen next?
8. Should companies pay for data broker removal for executives? What about all employees?
9. Your organization’s dnstwist job finds a newly registered lookalike domain with MX records but no website yet. What do you do?
10. The Judge Esther Salas case led to new laws protecting judges’ home addresses. Should similar protections extend to other groups, such as election workers, healthcare workers, or security researchers?