`social-analyzer` for Local OSINT Profile Correlation

social-analyzer provides API, CLI, and web interfaces for finding and analyzing public profiles across more than 1000 social media and website targets.

Tool	social-analyzer
Category	OSINT profile discovery and social-media analysis tooling
Primary Use	Authorized correlation of public profile signals across more than 1000 social media and website targets
Safe Use	Run locally for controlled investigations, lab validation, and authorized OSINT workflows; it is not intended to be exposed as a service.
Telemetry Note	Outputs can include module ratings from 0 to 100, correlation results, public extracted information, and screenshots of detected profiles when Chrome is available.

Execution Model

social-analyzer is presented as an API, CLI, and web app for analyzing and finding a person's profile across more than 1000 social media and website targets. That split gives operators three integration points: direct command-line use, programmatic OSINT pipeline integration, and a browser-based local interface.

The tool uses selectable analysis and detection modules during an investigation. Detection modules produce a rate value from 0 to 100 mapped to No-Maybe-Yes, with the stated goal of reducing false positives rather than treating a username or profile hit as proof of identity.

Recon Workflow Fit

The natural workflow placement is early OSINT enrichment: username expansion, profile discovery, and correlation of public social-media footprints before deeper manual review. It is not an attribution engine by itself; a rating score is an investigative signal that still needs corroboration from profile content, timing, platform metadata, and analyst notes.

Multi-profile search is supported for correlation using comma-separated combinations. That makes the tool more useful when an operator already has several candidate handles, aliases, or identity fragments and wants to test how those fragments appear across public services.

Input Artefatos and Outputs

The expected inputs are person-profile search terms, usernames, or combinations of candidate identifiers used for correlation. The available material does not justify claims about exact input schema, configuration syntax, authentication handling, rate limits, or supported export formats.

Outputs can include detected-profile ratings, public extracted information, and screenshots of detected profiles. Screenshot capture depends on the latest version of Chrome being installed, which implies a browser automation path rather than a purely HTTP-only lookup path.

• Treat 0-100 ratings as triage scores, not identity proof.
• Record the exact module set used during a run so later analysts can reproduce the same search boundary.
• Validate screenshot capture in a lab before depending on it for reportable evidence.

Runtime Components

The named ecosystem includes DuckDuckGo API, Google API, NodeJS, bootstrap, selectize, jQuery, Wikipedia, font-awesome, selenium-webdriver, and tesseract.js. That mix points to web UI components, search-provider integration, browser automation, and OCR-style processing as part of the broader toolchain.

Those dependencies also define practical preconditions. Browser-driven features can fail for reasons unrelated to target existence: missing Chrome, changed site layouts, automation breakage, search-provider behavior, or OCR noise. A clean operator runbook should separate lookup failures from negative OSINT findings.

Operator Checkpoints

The tool is explicitly meant to be used locally and not as a service because it does not have access control. Exposing the web app to shared networks would change the risk model: untrusted users could interact with OSINT workflows through an interface that was not described as access-controlled.

The available evidence supports discussion of local API, CLI, web use, modular detection, rating-based triage, multi-profile correlation, screenshot capture, and OSINT integration. It does not support claims about installation commands, licensing, platform coverage beyond the named components, private-module behavior, release cadence, or database completeness.

• Run it on a controlled workstation or isolated lab host.
• Do not publish the web interface as a shared service.
• Keep investigation notes separate from raw automated hits.

Failure Modes and Lab Boundaries

False positives remain a central risk even with a rating mechanism intended to reduce them. Common failure paths include reused usernames, parody accounts, stale profiles, search-index artefatos, platform pages that changed after indexing, and screenshots that capture the wrong visual state.

Safe use means authorized OSINT, controlled research, anti-abuse investigation, or lab validation against known test identities. The tool can help collect public signals related to suspicious or malicious activity such as cyberbullying, grooming, stalking, or misinformation, but it should not be used to harass, expose, or target individuals.

Telemetry and Validation Surface

A useful evaluation run should preserve inputs, selected modules, rating outputs, screenshots, timestamps, and analyst conclusions. That creates a reproducible chain from query to candidate profile without overstating what automated detection can prove.

Blue-team and response groups can also use the same artefatos to test OSINT handling procedures: how analysts separate public-profile correlation from attribution, how screenshot evidence is reviewed, and how low-confidence matches are filtered before escalation.

• Module score distribution across No-Maybe-Yes decisions.
• Screenshot availability and browser automation failures.
• Public extracted fields that can be manually confirmed or rejected.

Official qeeqbox/social-analyzer repository.

Download Tool