Detailed research draft — OSINT tools to track you down. You cannot hide (these tools are wild)

Status: Research summary derived from public video sources
Source supplied: retrieved video captions (1,861 lines) (1,861 caption lines; last caption begins at 01:07:53)
Video ID: zing6e1DtXE
Duration represented by transcript: approximately 67:56 (the request describes it as 67.9 minutes)
Title/channel identification: YouTube’s oEmbed endpoint returned the title above and David Bombal as author/channel. The transcript independently identifies the host as David Bombal at 02:31 and the guest as Michelle Khare/Michelle Khan—her surname is transcribed inconsistently, but the stated site is malhan.com. Treat spelling of the guest’s name as Michelle Khan pending confirmation from the video page.
Method note: The findings, dates, capabilities, and anecdotes below are transcript claims, unless explicitly labeled “independently checked.” Metadata (title/channel) was independently checked through YouTube oEmbed. The named services and URLs were not otherwise independently tested for current availability, legality, accuracy, or terms of use.

Executive summary

David Bombal interviews security consultant and OSINT trainer Michelle Khan about person-focused open-source intelligence (OSINT) and the corresponding privacy/OPSEC risks. Khan frames OSINT as a disciplined process: begin with seed data, prioritize unique identifiers, pivot across independent public sources, record evidence in a mind map, and treat tool results as leads rather than proof. The video progresses from search-engine operators and people-search sites to Wi-Fi mapping, address and imagery research, metadata/API enrichment, username and account enumeration, domain/web-technology pivots, vehicle and public-record lookups, automated web requests, and breach-data searches.

The strongest legitimate operational lessons are methodological, not tool-specific: cross-check across several sources, preserve provenance, use redundant sources, control “rabbit holes,” distinguish corroboration from coincidence, and follow applicable law and authorization. The guest explicitly cautions against jumping to conclusions from shared analytics IDs and acknowledges that these techniques expose serious privacy risks. However, the video also demonstrates or describes high-risk actions: extracting or enumerating PII through APIs, brute-forcing voter-registration form inputs, examining breached data locally, and determining hotel room assignments. Those sections should be treated as awareness material for defensive assessment, incident response, or authorized research—not as a how-to for targeting people.

Privacy advice emphasizes data minimization, data-broker/record awareness, account aliases, non-identifying Wi-Fi names, removal/takedown requests, and teaching children not to overshare. Some recommended “data spoiling” practices (such as furnishing false information to clinics or other services) can have legal, medical, billing, safety, or contractual consequences and are not broadly safe recommendations.

Participants, scope, and framing

• 00:00–00:49 — Opening privacy premise. The guest says learning where data is exposed is the first step toward reducing it. She says OSINT work for law enforcement should rely on information that can be publicly re-created, rather than paid-only results.
• 00:51–02:31 — Sponsor segment. Brilliant is promoted as an interactive learning service; the transcript states the URL brilliant.org/davidbble.
• 02:32–09:22 — Background and OSINT taxonomy. Bombal introduces Michelle. She describes a networking/Cisco background, virtual-CISO work, OSINT, and privacy management. Her three levels are basic search/social-media research, intermediate “hacker-level” research, and advanced work involving code and APIs. She distinguishes people-search, network OSINT, journalistic OSINT, code OSINT, and GEOINT.
• 08:41–09:22 — Use cases stated by speakers. Journalism, private investigation, threat-actor/missing-person work, authorized phishing/pentest reconnaissance, and digital-footprint assessments are named. Authorization, a legitimate purpose, and data-protection obligations should be established before any investigation.

Timestamped chapters

Techniques and ideas described

1. Build an evidence-led pivot graph, not a one-site answer

Transcript locations: 09:25–20:28; especially 12:37–17:30.

1. Begin from seed information (the examples are a name, phone number, address, email, domain, or vehicle plate).
2. Prefer a more unique identifier—the guest calls a phone number more discriminating than an address—while recognizing reassignment, shared numbers, outdated records, and errors.
3. Pivot to related identifiers (relatives, addresses, social accounts, domains, or records).
4. Write findings down and use an Obsidian mind-map/canvas to connect entities, keep hypotheses separate, and avoid rabbit holes.
5. Check several independent sources. The guest calls this redundancy and due diligence, and says a result should not depend on a paid “single pane of glass.”

Practical defensive takeaway: Make a personal or organizational exposure inventory: known aliases, domains, addresses, telephone numbers, people-search records, public images, and stale accounts. Record source, timestamp, confidence, and the removal owner. Do not treat an association as identity confirmation without corroboration.

2. Diversify search engines and use constrained queries

Transcript locations: 09:25–10:40.

The guest demonstrates a quoted Google search combined with filetype:pdf and a year, calling it “Google dorking,” then says the same query returns more material in Yandex. DuckDuckGo and Bing are also named. The point is to change sources and query formulation rather than depend on a single index.

Practical defensive takeaway: Search for one’s own organization and published materials across multiple engines, including document formats, but stay within authorized and lawful reconnaissance. Scrub accidentally published contact information and sensitive document metadata.

3. People-search, contact-sharing, and address intelligence

Transcript locations: 11:20–17:50; 21:44–27:20.

• The guest describes people-search sites as sources of current/past addresses, ages, telephone numbers, and relatives; these become pivot points.
• Sync.me and Truecaller are described as apps whose users may upload contact lists, creating crowdsourced phone-label data.
• WiGLE is used to look up Wi-Fi SSIDs around an address. The guest says registration is needed for full use.
• Google Maps/Street View, Bing Maps, Apple Maps, Zillow, generic property sites, and U.S. county records are named as ways to examine a property or ownership record.

Practical defensive takeaway: Audit data-broker listings and public property-record exposure; request opt-outs where available; remove personally identifying Wi-Fi SSID names; review street-imagery blur from all accessible angles. Do not use these sources to stalk, harass, dox, or locate a person without a clear lawful mandate.

4. Isolate untrusted applications and organize notes

Transcript locations: 14:03–17:30.

The guest runs a caller-ID app in an Android Studio emulator, specifically saying this lets her install “shady apps” away from a real device and grant permissions without granting them on her primary phone. She then shows an Obsidian canvas/mind map with branches for domains, businesses, breaches, records, numbers, and addresses.

Practical takeaway: Application isolation is sound defensive hygiene. Use a separate test environment with no personal accounts, no real contacts, and minimal permissions; observe platform policies and never upload third-party contact data without permission. Store investigation notes securely and only as long as required.

5. Metadata, account enumeration, and social-account assessment

Transcript locations: 27:39–37:30.

• The speaker claims a GitHub command-line tool, transcribed as “Zula do” / “Zuladoc” (possibly mistranscribed), can query Google Docs APIs to disclose a document creator’s name and email. This name/capability needs confirmation.
• A tool transcribed as “OI” is described as checking where an email account exists.
• Maigret and WhatsMyName.app are described for username enumeration across many services.
• A tool transcribed as “ignorant” / “ignorint” is said to test phone-based account existence on services including Amazon, Instagram, and Snapchat.
• The guest uses enumeration for a client-facing digital-footprint/impersonation assessment, while noting that many account hits can be false matches or impersonations.
• A GitHub tool transcribed as “two tatis” is claimed to query Instagram APIs using an authentication token from an alias account and reveal obfuscated email/phone data. This tool name and capability need confirmation; acquiring or using account tokens can violate platform rules and create privacy/security risk.

Practical defensive takeaway: Inventory old usernames and aliases, search for impersonations, preserve evidence for platform reports, and protect accounts with unique passwords and MFA. Avoid “registration probing,” account enumeration, automated API abuse, or token reuse against accounts/services you do not own or lack written authorization to test.

6. Corporate, domain, analytics, and web-history pivots

Transcript locations: 37:55–41:27.

• OpenCorporates is named for company/LLC research.
• WHOIS and historical WHOIS are used as domain pivots; the transcript names a site transcribed as “hookie.com” or “whoxy.com” for historical records.
• Viewing page source for Google Tag Manager/Google Analytics identifiers is proposed. The transcript names “web techservey.com/tag” as a site to search shared tag IDs—likely mistranscribed and unverified.
• The guest explicitly says a shared tag ID is only a lead: it might reflect shared ownership, a common developer, or an agency, so investigators should not jump to conclusions.
• Archive.org / Wayback Machine is used to look for prior site versions that contained removed contact details.

Practical defensive takeaway: Treat shared infrastructure and tag IDs as weak-to-moderate relationship indicators, not proof. For organizations, rotate/segregate analytics containers where appropriate, audit old web captures, and remove personal contact data from pages and documents. Note that historical copies may persist after a current site is cleaned.

7. Vehicle, public-record, and API exploration

Transcript locations: 42:01–49:30.

The guest claims that O’Reilly Auto Parts (“orauto.com” in the transcript) and Carvana plate-entry flows could return vehicle details; she then illustrates a plate-to-VIN-to-title/leanholder research chain and refers to a U.S. state DMV/BMV. She also discusses a UK gov.uk vehicle API explored via Postman, browser network requests, headers, and POST bodies.

Practical defensive takeaway: Organizations exposing lookup flows should test for excessive data disclosure, authentication, authorization, rate limiting, logging, and abuse detection. Only query vehicle or governmental datasets through authorized channels and in compliance with their rules and jurisdictional privacy law. A plate or VIN does not authorize private investigation.

8. Web-request automation, voter records, and hotel portals — defensive awareness only

Transcript locations: 49:31–57:12.

The most sensitive material is a demonstration of:

• Using Burp Suite or a tool transcribed as “KO” (likely a tool name requiring verification) to iterate dates of birth against a voter lookup, identify response-size anomalies, and then reveal a home address and voter ID.
• Claiming that CAPTCHA would make this attack harder, but not necessarily impossible.
• Describing automation of hotel guest-Wi-Fi room-number verification from surname plus finite room-number ranges; the guest says a saved Hilton portal remained accessible off-premises and its URL might be manipulated to reach another property.

Defensive takeaway: These are examples of enumeration/IDOR/rate-limit failures. Do not reproduce them against public records, hotels, or any third-party service. Operators should require strong authentication, apply server-side authorization, bind guest portals to appropriate networks/sessions, minimize PII in responses, use rate limits and anomaly detection, avoid distinguishable failure responses, and maintain a lawful vulnerability-disclosure process.

9. Breach awareness and local breach searching — high sensitivity

Transcript locations: 57:13–61:26.

The guest uses Have I Been Pwned to determine that a sample email appears in breaches, then claims to search local copies of ParkMobile and AT&T breach data with a command-line tool transcribed as “rip grap” (likely ripgrep). Examples involve telephone numbers, passwords/hashes, license plates, email addresses, addresses, and Social Security numbers.

Practical defensive takeaway: Use a reputable exposure-notification service to check your own email/domain; rotate passwords, enable MFA, monitor fraud/credit as appropriate, and contact affected services. Possessing, downloading, searching, sharing, or exploiting breach data may be illegal, unethical, contractually prohibited, or harmful—especially where Social Security numbers, passwords, financial information, or other regulated data are involved. Do not collect or retain breach datasets absent explicit legal authority, counsel, data-handling controls, and a compelling authorized purpose.

Named tools, sites, and services

Important: Entries below reproduce names as heard/transcribed. An explicit URL is supplied only when the transcript itself states a URL/domain. For all other named services, URL not stated. Several names are visibly mistranscribed or ambiguous and are marked accordingly.

Explicit URLs/domains stated in the transcript

Named but URL not stated in transcript

Privacy, legal, and ethics caveats

1. Use only with authorization and a legitimate purpose. Public accessibility does not make collection, correlation, automated enumeration, or retention lawful or ethical. Laws differ by location and data type; contractual terms and computer-misuse, anti-harassment, privacy, consumer-reporting, and data-protection rules can apply.
2. Do not dox, stalk, harass, swat, impersonate, or enable physical harm. The transcript itself identifies doxxing, swatting, mailed harassment, and “crime as a service” as real harms (24:50–26:02). The report intentionally omits step-by-step operational detail that could facilitate those harms.
3. Do not access or search breach data without authority. Breach records can include passwords, SSNs, address data, and more. Accessing, retaining, or using them can create serious legal and victim-safety consequences.
4. Avoid account enumeration and unauthorized API/token use. Registration probes, API calls intended to reveal account presence/PII, automated request iteration, and reuse of browser/authentication tokens may violate law, platform terms, and privacy expectations.
5. Treat API/network demonstrations as vulnerability awareness. Test only systems you own or have written permission to test, under agreed scope, rate limits, and reporting procedures. For a suspected flaw, use responsible disclosure—not public probing.
6. Corroborate and minimize. Data brokers, caller-ID sources, public records, search indices, and historical snapshots can be stale, wrong, incomplete, blended across people, or maliciously seeded. Mark confidence and source; do not act on an unverified match.
7. Protect investigation data. Use access controls, encryption, need-to-know handling, retention limits, audit logs, and secure deletion. Do not paste third-party PII into SaaS tools without approval and an appropriate data-processing basis.
8. “Data spoiling” is not universally appropriate. The guest advocates aliases and giving nonessential/fictitious information. That can be reasonable in low-stakes contexts where permitted (for example, a restaurant order name), but false information to a health provider, school, financial institution, government entity, insurer, emergency service, or contract counterparty can disrupt care, billing, records, legal rights, fraud controls, and emergency response. Provide accurate information whenever it is legally or operationally required; ask whether a field is optional and request data-minimization instead.
9. Protect children with age-appropriate, platform-compliant practices. Teach limited sharing, privacy settings, and when to seek help; do not encourage children to evade age controls or deceive platforms where that would violate rules or compromise safety.

Practical takeaways and defensive action list

For individuals

• Inventory your public footprint: names/aliases, telephone numbers, addresses, emails, old profiles, business registrations, images, and Wi-Fi SSID.
• Search across multiple engines and review data-broker listings. Request opt-outs/removals, correct inaccuracies, and record confirmation dates.
• Use a generic, non-identifying Wi-Fi SSID; avoid family names, children’s names, address clues, employer names, or hobbies. Periodically review/update it, balancing this with device-management needs.
• Separate high-value logins from public-facing contact details. Use unique passwords, a password manager, MFA, recovery protections, and an email/phone strategy that does not needlessly expose a primary identifier.
• Review old accounts and usernames; report impersonations through the relevant platform and preserve screenshots/URLs/timestamps for evidence.
• Check your own email/domain with a reputable breach-notification service; immediately change exposed passwords and assess MFA/recovery data. Do not hunt through raw stolen datasets.
• Review mapping/street imagery, property listings, and public records for unwanted exposure. Use official request/opt-out channels and retain receipt numbers.
• Teach household members, especially children, not to disclose names, school, address, phone, routine, or location to strangers; use privacy settings and supervised age-appropriate accounts.

For organizations and service operators

• Perform authorized external attack-surface reviews using a documented scope, a test account, rate limits, and legal approval.
• Remove PII from PDFs, historical pages, contact pages, public cloud documents, and metadata; assume caches and archives may persist.
• Audit account-recovery, registration, lookup, and API endpoints for user enumeration, inconsistent response sizes, excessive fields, insecure direct object references, leaked tokens, and weak authorization.
• Add rate limiting, bot mitigation, uniform failure messages, monitoring, alerting, server-side authorization, and abuse-response runbooks. CAPTCHA is one layer—not a complete control.
• Keep hotel/guest access portals bound to the intended property/network/session; do not disclose room information through predictable lookup flows.
• Review analytics/tag-container governance. Shared IDs may create unintended cross-site association and privacy exposure; use ownership controls and least privilege.
• Establish a vulnerability-disclosure channel and safely triage reports. Avoid retaliating against good-faith reporters who follow a published policy.
• Maintain a privacy program for data minimization, vendor assessment, breach response, deletion/retention, and individual-rights requests.

Claims that require independent verification

The following are reported as claims made in the transcript, not conclusions of this report:

Final assessment

This is a useful, high-level awareness interview about how seemingly ordinary identifiers can be chained into a detailed digital profile. Its most reusable value is the method: search broadly, use more than one source, document provenance, model relationships, verify assumptions, and design systems so identifiers cannot be cheaply enumerated. Its riskiest sections demonstrate how readily that methodology can cross into privacy invasion or unauthorized testing. Any internal follow-up should prioritize a privacy exposure audit, data-minimization controls, secure API/portal design, and lawful responsible disclosure—not replication of the offensive demonstrations.

Detailed Research Report — How to Detect Fake Cell Towers Near You

Status: Reference for client-authorized OSINT / mobile-security assessment work. Not an operational field guide.
Prepared: 2026-08-15
Primary video: YouTube — How to Detect Fake Cell Towers Near You

1. Video identification and provenance

Method note

This report separates (1) what the presenters say or demonstrate from (2) independently supportable conclusions. Timestamps refer to the retrieved auto-caption timeline and may vary slightly from YouTube’s displayed player time. The caption file had repeated ASR fragments; the outline below was normalized against the video’s own chapter markers.

2. Executive summary

David Bombal and guest Occupy The Web (OTW) discuss risks associated with cellular-network surveillance, including rogue base stations commonly described as IMSI catchers or “Stingrays.” Their defensive theme is sensible at a high level: establish an authorized, passive RF baseline of expected cellular broadcasts in a defined location; investigate material deviations; and use end-to-end encryption and endpoint hardening to reduce the impact of network-layer observation.

The video demonstrates a receive-side SDR workflow in DragonOS, naming CellSearch for discovery of nearby broadcast signals and Falcon for observing LTE-related activity. It also names HackRF, RTL-SDR, and LimeSDR hardware. It proposes that a newly observed, unusually strong, or poorly identified signal can be a reason to investigate further.

That proposal must not be treated as attribution or proof of a fake tower. RF propagation, network optimization, maintenance, temporary cells, roaming/partner networks, carrier spectrum changes, small cells, device reception differences, and tool/caption interpretation can all create apparent anomalies. A missing or unexpected identifier is an investigation lead—not a conclusive indicator of criminal activity, surveillance, or a particular actor.

Several broad claims in the discussion require qualification. Modern cellular systems use layered protections, vary by generation, operator, radio access technology, configuration, and jurisdiction, and still expose some necessary operational metadata. However, it is inaccurate to generalize that any nearby rogue tower can simply read all calls, texts, web activity, or that a handset necessarily provides a permanent identifier in a clear initial frame. Those outcomes depend on the radio technology, handset and network configuration, downgrade behavior, authentication state, encryption, application protocol, and attacker capability. The video itself mixes legacy and current-generation concepts and should be used as awareness material, not as a technical authority or evidentiary basis.

For a client-authorized assessment, the appropriate deliverable is a passive, time-and-location-bounded inventory of observed broadcast characteristics, comparison against approved carrier/asset information where available, an anomaly register with confidence ratings, and an escalation path to the client’s carrier, regulator, or counsel. Do not transmit, impersonate a network, induce handsets to attach, attempt decryption, collect subscriber/device identifiers, or conduct interception.

3. Timestamped outline and observations

4. Named tools, platforms, and hardware

The following list records names used in the video. A direct link is supplied only where this research verified that the linked official/project page returned a successful HTTP response on 2026-08-15. A successful page response verifies the link’s reachability—not the video’s claim about suitability, integration, current support, or capability.

Tooling safety boundary

For a client assessment, the preferred evidence sources are carrier-provided engineering records, regulator/asset records where available, passive spectrum/broadcast inventory, and normalized temporal comparison. Tools that can transmit, attach to, emulate, decode, or identify user equipment are outside the default scope and require a separately approved method, legal review, equipment controls, and data-protection plan.

5. Technical explanation — safe defensive level

5.1 What a legitimate cellular site broadcasts

A cellular network must advertise enough information for compatible handsets to discover, select, and attach to service. Depending on the radio technology and configuration, those broadcasts can expose operational properties such as radio technology, channel/band, cell identity values, network identity values, timing/synchronization behavior, and signal strength. These are not by themselves evidence of malicious activity; they are necessary features of a functioning access network.

Cellular deployments are dynamic. Operators may alter capacity, spectrum allocations, neighbor relationships, software, backhaul, and power settings. They may deploy small cells, temporary event/maintenance capacity, in-building systems, or roaming-related infrastructure. A baseline should therefore be a living dataset rather than a one-time “known good” list.

5.2 Rogue base stations / IMSI catcher terminology

A “rogue base station” is a broad description for radio infrastructure that presents itself as, or affects access to, a cellular network without being an expected authorized site in the relevant context. “IMSI catcher” and “Stingray” are often used colloquially, but they should not be used as technical conclusions without evidence. Products, capabilities, and legal authorities vary.

Potential impacts can include location inference, signaling or metadata exposure, denial/degradation, forced fallback to less protected service in some conditions, and—under specific conditions—interception or manipulation. Modern cellular generations introduce authentication and confidentiality improvements, but they do not make every attack path impossible, and legacy coverage/compatibility can matter. Conversely, the mere observation of a new or strong broadcast does not establish any of these impacts occurred.

5.3 Metadata versus content

Application-layer end-to-end encryption can protect message and call content between authenticated endpoints even when it traverses an untrusted network. It does not eliminate every observable operational fact: a network must still manage radio access, routing, service, and availability. The precise metadata visible to a party depends on the layer, technology, configuration, and collection point.

A defensible report must say exactly what was observed—not infer content collection from a signal anomaly. For example:

• “A previously unseen broadcast characteristic was observed at location X during window Y” is an observation.
• “The signal was a Stingray collecting all nearby traffic” is an unproven attribution and impact claim unless corroborated by authoritative evidence.

5.4 Why baseline comparison is useful but limited

The video’s practical concept—compare repeated local observations—is useful when performed passively and with a rigorous evidence model. A high-quality baseline records: location boundaries, time window, receiver/antenna configuration, calibration/state, observed network characteristics, confidence, and environmental changes. Compare only like-for-like samples where possible.

A candidate anomaly should be triaged against benign explanations before escalation:

1. scheduled/unscheduled carrier engineering work;
2. temporary or event infrastructure;
3. permitted small-cell, enterprise, or in-building systems;
4. roaming/partner coverage;
5. propagation changes caused by terrain, weather, reflections, or receiver placement;
6. changed handset/software/SDR configuration or software decoding behavior; and
7. data-quality, timestamp, or identifier parsing errors.

5.5 Endpoints remain security-critical

The video correctly emphasizes a core security principle: encryption in transit cannot fully protect communications if an endpoint is compromised. A mature response therefore combines communications security with supported OS updates, device-management controls, strong authentication, phishing resistance, app allowlisting or review, physical-device safeguards, incident response, and appropriate logging.

6. Client-authorized assessment takeaways

Appropriate objective

Determine whether there are material, repeatable, and corroborated deviations from expected cellular broadcast characteristics within a client-approved physical area and time window. The outcome should be risk-ranked evidence and remediation decisions—not attribution or surveillance.

Recommended scope language

Include all of the following in the statement of work / rules of engagement:

• Exact physical boundary, dates, hours, and client-controlled sites.
• Named client sponsor, asset owner, and escalation contacts.
• Explicit receive-only/passive RF collection requirement unless a separately authorized exception is approved.
• Prohibition on transmitting, jamming, replaying, impersonating a carrier, inducing handset attachment, testing handsets not owned/controlled by the client, decrypting, or intercepting communications.
• Data-minimization rule: do not intentionally collect subscriber identifiers, device identifiers, content, or third-party traffic. If incidental personal data is captured, stop relevant collection, preserve only what counsel authorizes, restrict access, and follow the agreed retention/destruction process.
• Required coordination with carrier(s), venue owner, regulator, counsel, security operations, and privacy officer as appropriate.
• A predefined severity and evidence threshold for notifying law enforcement or regulators.

Evidence model for a passive assessment

For every observation, record:

• collector, authorization reference, location, and start/end timestamps with time source;
• receiver, antenna, cable, software/version, configuration baseline, and any changes;
• observation type and only the minimum technical characteristics necessary to compare it;
• raw evidence integrity information (hash, storage location, access control) where retention is authorized;
• contextual evidence: known carrier work, building systems, events, or environmental factors;
• confidence level and alternative benign explanations;
• whether carrier/operator validation has been requested and its result.

Triage categories

7. Remediation and risk-reduction recommendations

Priority 1 — governance and response readiness

1. Establish an RF/cellular anomaly response playbook with legal, privacy, facilities, physical security, IT, and communications roles.
2. Maintain current contacts for carrier enterprise/security teams, building/venue management, and relevant national regulator/law-enforcement liaison channels.
3. Document normal on-site cellular infrastructure, approved signal boosters, distributed antenna systems, small cells, and temporary-event equipment.
4. Train responders to preserve observations and avoid attribution, public allegations, equipment seizure, or confrontation.

Priority 2 — communications and endpoint resilience

1. Use vetted end-to-end encrypted messaging/calling for sensitive communications, with verified contact identity where the product supports it.
2. Reduce reliance on SMS for high-value authentication; prefer phishing-resistant authentication such as security keys/passkeys where feasible.
3. Keep mobile OS, baseband/carrier settings, and applications current on vendor-supported devices.
4. Apply enterprise mobile-device-management, screen-lock, encryption, application, and incident-reporting controls appropriate to the client’s risk profile.
5. Protect endpoints against compromise; content encryption in transit is not a substitute for endpoint security.
6. Define safe fallback communications for suspected service disruption (e.g., known-good wired, managed Wi-Fi, out-of-band, or physical escalation methods). Select and test these before an incident.

Priority 3 — detection quality and false-positive reduction

1. Build a passive baseline through repeated observations across normal operating conditions, rather than relying on a single scan.
2. Normalize collection configuration and retain calibration/configuration records so changes can be distinguished from RF/environment changes.
3. Compare observations with approved carrier/venue data before treating them as suspicious.
4. Use an independent second receiver/collector for a material anomaly, subject to the same passive and legal controls.
5. Escalate for carrier/regulator validation rather than expanding into active testing.

What not to rely on

• A consumer scan alone as proof that an IMSI catcher or rogue tower exists.
• A VPN as a remedy for cellular attachment, RF tracking, availability attacks, or endpoint compromise.
• A privacy-oriented operating system as a complete solution to network-layer metadata or radio-network risks.
• A one-time cell-site list as a stable baseline.
• General online claims about identifiers, encryption, or specific carrier/network behavior without current, local verification.

8. Legal, regulatory, safety, and scope caveats

1. Radio regulation: Receive-only monitoring may still be regulated or restricted depending on country, frequency, equipment, and the nature of information collected. Any transmission, emulation, jamming, or interference can be unlawful and dangerous. Obtain jurisdiction-specific advice before fieldwork.
2. Communications interception and privacy: Capturing, decoding, correlating, retaining, or disclosing third-party communications or identifiers can trigger wiretap/interception, privacy, data-protection, telecom, employment, and contractual obligations. Written client authorization alone may not override statutory restrictions.
3. Carrier/network authorization: Client ownership of premises does not equal authority to test a public mobile network. Coordinate with the operator and appropriate authorities when required.
4. Attribution: Do not identify a signal as law enforcement, intelligence, a particular vendor, a criminal actor, or a “Stingray” without credible corroboration and review by counsel. False claims can create legal and safety exposure.
5. Operational safety: Do not confront suspected operators or deploy transmit-capable hardware in an unapproved mode. Preserve evidence, protect personnel, and use the client’s incident/escalation process.
6. Data handling: Treat RF captures and derived identifiers as potentially sensitive. Use minimization, encryption at rest, role-based access, approved retention, and documented destruction.
7. Vendor claims: Sponsor statements and presenter anecdotes are not independent validation. Procurement or policy decisions require separate evaluation.

9. Claims needing verification or qualification

This register does not label the presenters dishonest. It identifies claims that are broad, environment-dependent, ambiguous, or insufficiently corroborated in the video and therefore should not be repeated as client findings without further evidence.

10. Bottom line for client use

Use this video as a well-structured awareness prompt for three issues: cellular metadata and signaling risks exist; passive, authorized baselining can help identify items that deserve validation; and end-to-end encryption plus endpoint hardening are important compensating controls.

Do not use it as a field procedure for identifying “fake towers,” as proof that a particular site is an IMSI catcher, or as authorization to collect user/device data. The responsible next step is an authorized, passive, evidence-led baseline with carrier/regulatory coordination and a conservative anomaly-escalation process.

11. Report sources

Primary source

1. David Bombal, “How to Detect Fake Cell Towers Near You,” YouTube, channel: David Bombal. Metadata and English auto-captions retrieved 2026-08-15 using yt-dlp 2026.07.04. Retrieved metadata: title, channel, publication date 2026-08-14, duration 1:02:13, chapters, description, and caption timeline.
2. YouTube oEmbed response for the same video, retrieved 2026-08-15: title and channel URL confirmation.

Verified direct project/vendor pages (link reachability checked 2026-08-15)

3. Great Scott Gadgets — HackRF.
4. DragonOS Focal — SourceForge.
5. RTL-SDR Blog.
6. GrapheneOS Features.

Source limitations

• The video is a secondary/commentary source and includes sponsor material and anecdotal claims.
• The captions are automatically generated and can contain transcription errors.
• The direct links above were validated for reachability, not exhaustively audited for software safety or technical claims.
• The exact authoritative upstream repositories/pages for the video’s specific CellSearch and Falcon tools were not verified during this research; intentionally no link is supplied for them.

Detailed Report: Go St*lk Yourself: Privacy Through OSINT

Purpose and handling. This is a defensive research brief derived from the linked public presentation and its retrieved captions. It is intended for personal privacy improvement and authorized client assessments only. It intentionally does not reproduce a procedural playbook for locating, correlating, or exploiting another person’s data.

Video record

Executive summary

Mishaal Khan frames privacy as a proactive exposure-management problem rather than an absolute “delete yourself from the internet” problem. The presentation’s central message is that public information often becomes harmful when separate fragments—name, contact details, address, relatives, social accounts, public records, breach artifacts, and technical metadata—are combined. The recommended defensive response is a recurring, self-directed inventory: find one’s own exposure, document it, pursue source-appropriate corrections or opt-outs, reduce future data collection, and monitor for reappearance.

The talk is particularly useful for translating OSINT into personal-safety outcomes: targeted harassment, doxxing, account takeover, and swatting risk. It emphasizes that cleanup is incomplete and that some official or historical records cannot be readily removed. Accordingly, remediation must combine: (1) removal/correction where possible, (2) reduction of new data leakage, (3) account and identity safeguards, and (4) routine monitoring.

For organizations, the valuable takeaway is not to imitate a “stalker workflow,” but to perform an authorized, minimally invasive exposure review of an agreed set of organizational identities, web properties, published materials, and executives or staff who have opted in. The deliverable should be a verified evidence register and remediation backlog—not a dossier of employees or a collection of breach data.

Several speaker statements are experience-based, time-bound, or technically imprecise. They are preserved as presentation takeaways but are flagged below for validation before policy or client recommendations are made.

Timestamped outline and analysis

Timestamps are approximate caption start times; phrasing is summarized unless quoted. The final ~17 minutes include Q&A and Antisyphon training promotion.

Named tools, services, and resources

Only direct links independently confirmed reachable during research are linked. A mention in the video is not an endorsement. Services and policies change; confirm jurisdiction, terms, and privacy implications before use.

Directly verified links

Mentioned but not linked here (not independently verified)

The captions mention names that were ambiguous, transcribed imperfectly, inaccessible, unstable, or not necessary for a defensive recommendation. To avoid providing an incorrect direct link, validate manually before citing or using: search.zs (caption transcription uncertain), “Breach Directory,” “OSINT Combine” (name/domain uncertain from captions), TruePeopleSearch, FastPeopleSearch, voterrecords.com, Whois.com, Exifer/“exif-er.net,” and a possibly transcribed dorking/tool name. These are not required to carry out the remediation program below.

Practical personal privacy remediation

1. Establish a private exposure register (week 1)

Create an encrypted/local or approved secure record with the minimum necessary detail:

• Identity variants: legal name, common misspellings, former names, usernames, work aliases, and controlled email aliases.
• High-risk identifiers: current/previous phone numbers, current/previous addresses, domains, and public-facing handles. Do not paste passwords, government IDs, or breach contents into the register.
• Each exposure: URL/source, exact data shown, screenshot or evidence reference, date found, impact, remediation owner, request method, request date, outcome, and recheck date.
• A risk label: Critical (home address, government identifier, active account/recovery data), High (phone/email paired with identity, family relationship, current employer/location), Medium, or Low.

2. Search and validate defensively (week 1–2)

• Search only your own identity, an informed consenting adult’s identity, or an authorized client scope.
• Review ordinary web, image, social, domain, and public-facing company presence. Record results; do not assume a matching name is the same person.
• Check known-breach notification through a legitimate service such as Have I Been Pwned; do not purchase, trade, download, or query illicit breach data.
• Review domains you own: current registrant contact, historic exposure, DNS, public source repositories, and account recovery contacts.
• Identify duplicate/forgotten accounts. Secure or close them through the actual provider, not merely a third-party index.

3. Remove, correct, suppress, or mitigate (prioritized)

1. Immediate physical/identity risk: exposed home address, current phone, government identifier, account-recovery information, credible harassment, or impersonation. Preserve evidence; request removal/correction from the source; notify relevant platforms; freeze credit where appropriate; seek victim-assistance, legal, or law-enforcement help based on the threat.
2. Data-broker and people-search records: use the service’s official opt-out workflow where available. Verify after the stated processing interval and recheck periodically. Use an email alias dedicated to privacy requests if permitted.
3. Employer, association, and professional pages: ask the publisher to remove home contact information, personal phone numbers, birth dates, family references, or unnecessary bios. Substitute a role mailbox/office address where feasible.
4. Maps, real-estate, and imagery: request blur/removal through each provider’s official policy when eligible. Do not rely on removal from one map provider to remove the image everywhere.
5. Public records: ask the originating court/agency whether correction, sealing, redaction, address-confidentiality programs, or protected-person procedures apply. Do not misrepresent facts or attempt to alter lawful records.
6. Search snippets/cache: request removal at the source first. Then use the search engine’s current official removal/outdated-content process if applicable.

4. Reduce future exposure

• Use a password manager and unique credentials; enable phishing-resistant MFA (security keys/passkeys) where available. Review recovery email, phone, and backup codes.
• Use purpose-specific email aliases; avoid using a personal phone number or residential address when a role mailbox, business number, PO box, or approved virtual address is appropriate and lawful.
• Turn off unnecessary profile discoverability, contact syncing, precise location sharing, public friend/follower lists, and public date-of-birth fields.
• Strip location and unnecessary camera metadata from images before publishing. Use your platform’s privacy controls, but do not assume they always remove metadata.
• Keep domains in an approved registrar account with current contacts, privacy/proxy where lawful, renewal controls, MFA, and a documented ownership model.
• Limit what is posted about routines, travel, children, schools, vehicles, home exterior/interior, and real-time location.
• Recheck every quarter (or monthly for a high-risk individual); alerts and change monitors are supplementary signals, not guarantees.

5. When active harassment/doxxing is occurring

• Prioritize immediate safety. If there is imminent danger, contact emergency services. In the U.S., proactively consider local law-enforcement non-emergency guidance on swatting response; availability and process vary by jurisdiction.
• Preserve original URLs, timestamps, headers, screenshots, and platform report numbers; do not engage the harasser or amplify the content.
• Notify the platform and host, employer/security team, legal counsel, and affected family members on a need-to-know basis.
• Change account-recovery paths, revoke unfamiliar sessions, rotate exposed passwords, and monitor financial/identity activity.
• Avoid publishing fabricated data as a countermeasure. It can mislead emergency responders, create legal/reputational problems, and contaminate records.

Authorized-client OSINT exposure assessment: safe takeaways

Engagement prerequisites

Obtain a written authorization that names:

• Client legal entity, sponsor, points of contact, and assessment purpose.
• In-scope domains, brands, executives/staff who have individually consented or are otherwise lawfully included, social accounts, office locations, and date range.
• Permitted sources and techniques: public web review, authenticated client-owned systems, public registries, breach-notification checks, screenshots, and monitoring. Explicitly prohibit credential stuffing, access circumvention, deception, social engineering, covert recording, paid illicit data, or breach-data acquisition unless separately and lawfully approved.
• Data handling: collection minimization, storage location, encryption, retention/deletion date, report audience, and incident/escalation process for discovering serious personal risk or illegal material.
• Stop conditions, especially discovery of threats, protected-person data, or accidental access to non-public information.

Recommended assessment method

1. Scope and risk model. Define the business question: executive protection, brand impersonation, exposed contact details, domain/metadata exposure, or employee awareness. Establish severity criteria before collection.
2. Passive, minimum-necessary collection. Start with client-owned web properties and official/public materials. Capture only evidence needed to substantiate a finding. Avoid compiling personal dossiers or family information.
3. Validate identity and materiality. Treat search results, people-search entries, historical records, and automated correlations as unverified leads. Confirm through client-provided records or an independent authoritative source before reporting.
4. Map exposure to harm. Report the specific relationship: e.g., published office/staff contact list plus visible account-recovery phone creates impersonation risk; public document metadata reveals personal author path; historical WHOIS exposes a personal address.
5. Remediate at the source. Make precise recommendations: correct a page, remove a document, replace a personal contact with a role contact, blur an image, change a domain registration model, implement MFA, or establish a broker-opt-out cadence.
6. Retest and document residual risk. Verify removals after provider processing time. State what could not be removed, why, and compensating controls. Destroy sensitive working data at the agreed retention point.

High-value organizational controls

• Publish role-based contact information rather than individual personal phone/email/address data.
• Institute a secure document-publication process: metadata review, PDF sanitization, approval of public bios, and periodic website/asset inventory.
• Centralize domain ownership and renewal; enforce MFA and registrar-change controls.
• Maintain executive/at-risk employee privacy support: opt-out assistance, account-hardening guidance, incident triage, and a clear escalation channel.
• Train staff against impersonation and account-recovery fraud. Ensure helpdesk, HR, payroll, and vendors verify requests through approved channels.
• Incorporate public-exposure scenarios into incident-response and executive-protection/tabletop exercises without using employee data outside authorized scope.

Legal, ethical, and scope caveats

• Authorization is mandatory. Searching, correlating, monitoring, or reporting on another person should be limited to oneself, an informed consenting subject, or a client scope documented in writing.
• Public availability is not unlimited permission. Terms of service, anti-scraping rules, privacy law, data-protection law, employment law, consumer-reporting rules, and jurisdiction-specific public-record restrictions may apply.
• Do not acquire or use illicit breach data. Legitimate breach-notification/identity-protection services are materially different from downloading, trading, or searching leaked databases.
• Do not use OSINT to facilitate harassment, stalking, doxxing, swatting, fraud, account takeover, physical surveillance, or evasion. This report deliberately omits such operational guidance.
• Do not assume removal. Government records, archives, caches, republished copies, and historical registration records may persist. Never claim “complete deletion”; document residual risk and compensating controls.
• Avoid deception and false data. The talk demonstrates disinformation and false EXIF as examples. For personal and business remediation, use accurate corrections, lawful privacy controls, and clear documentation. Publishing false data can harm others and may violate policies or law.
• Avoid handling sensitive data unnecessarily. Collect only evidence required for the finding, redact reports, restrict access, encrypt storage, and apply a deletion schedule.
• Special populations require extra care. Minors, domestic-violence survivors, public officials, activists, and protected persons may have specific safety programs and statutory protections. Escalate to qualified counsel/advocates rather than improvising.

Claims and details requiring verification before reliance

Sources and research notes

1. Primary video: Antisyphon Training, Go St*lk Yourself: Privacy Through OSINT w/ Mishaal Khan | 1-Hour. https://www.youtube.com/watch?v=tJEGBmQjh-8
2. YouTube oEmbed metadata: retrieved from YouTube’s oEmbed endpoint for the primary video; verified title and channel.
3. YouTube watch-page metadata and description: retrieved from the primary video page; verified title, channel, publishDate/uploadDate, lengthSeconds, and stated event context.
4. Closed-caption transcript: 1,836 English caption segments retrieved from the primary video on 15 August 2026; caption duration 1:15:39. Timestamps in this report are derived from those segments. Captions are machine/creator-provided transcript material and may contain transcription errors.
5. Direct link verification: the “Directly verified links” table records URLs that returned a reachable HTTP response during research on 15 August 2026. Reachability does not validate a provider’s effectiveness, accuracy, lawfulness for a particular use, or suitability for a client.

Method limitations

• This is a transcript-led analysis, not an independent technical audit of every tool or claim in the presentation.
• The report intentionally avoids restating operational search strings, data-correlation steps, or techniques that could be repurposed to target a third party.
• The primary event landing-page URL included in the YouTube description returned an HTTP 404 at research time; it is therefore not used as a report source link.

Bottom line

The durable message is to treat privacy as a recurring operational practice: inventory what is exposed, remediate it at the source, harden accounts and publishing habits, monitor for reappearance, and plan for escalation. For authorized organizations, turn that into a narrowly scoped, evidence-minimized exposure assessment with clear consent, remediation ownership, and retesting—not a broad collection exercise.