SilentSniffer is a client-side JavaScript sandbox that visually demonstrates how much device, network, and behavioral data modern Web APIs expose silently, strictly for authorized awareness and security education.
| Tool | AhmadHassan-BTed/SilentSniffer — a local-only browser privacy diagnostic sandbox with 54 educational modules across six threat levels |
| Category | Browser security awareness / client-side JavaScript diagnostics |
| Primary Use | Visually auditing which silent Web API probes a browser permits (WebGL, WebBluetooth, IndexedDB, Permissions API) inside a zero-exfiltration local sandbox |
| Safe Use | Intended for authorized security training, browser capability auditing, and privacy awareness research; every module runs locally in the user's own browser with no data transmission |
| Telemetry Note | By design, the tool generates no network traffic; all execution logs stay in a local IndexedDB database named SilentSnifferAuditLogDB, so defenders inspecting it should focus on the browser APIs it queries rather than any outbound signals |
SilentSniffer positions itself against a specific and widely held assumption: that a browsing session stays private unless the user clicks "Allow" on a permission prompt. The project, authored by Ahmad Hassan (B-Ted) and written almost entirely in JavaScript, argues that standard Web APIs already hand websites extensive access to hardware characteristics, timing vectors, network topology, and sensor behavior without any prompt at all. Its stated purpose is educational: a live, visual demonstration of that ambient exposure surface. Crucially, the README is emphatic that this is a self-contained sandbox — zero data is exported or transmitted anywhere, and all captured metrics stay inside the local browser context.
The repository has accumulated roughly 1,850 stars, which is notable for what is essentially an awareness project rather than an operational toolkit. Its topic tags — browser-security, fingerprinting, forensics, osint, red-team among them — reflect how it straddles education and offensive conceptual understanding. But reading the actual module inventory shows the maintainers made a deliberate engineering decision: remote exfiltration servers and genuinely malicious payloads were excluded and replaced with safe diagnostic equivalents, documented in a separate EXCLUDED_VECTORS_SPECIFICATION.md file. That document is worth a look for anyone assessing whether the tool crosses from demonstration into weaponization, because it enumerates precisely which offensive function signatures were stripped out.
Architecturally, SilentSniffer is a decent case study in decoupled front-end design. The core engine (src/core/engine.js) knows nothing about individual module logic; it discovers tools at runtime by fetching a centralized manifest at src/config/modules.json and dynamically importing each payload from src/modules/level_X/*.js. Modules then self-register back with the engine, which renders them into a dynamic command-center grid. The README describes this as a "Zero-Coupling Dynamic Plugin Architecture" with 0% coupling between core and payloads and 100% cohesion within each module. For practitioners, that means extending the toolkit is straightforward: drop a script into the appropriate level folder, add its path to the manifest, and open debug.html to verify it renders.
The module catalog is organized into a six-level "threat escalation hierarchy" that mirrors how a real attacker's reconnaissance would progress. L1 covers standard recon — OS, browser, and performance telemetry. L2 moves into network topology and hardware fingerprinting. L3 targets PII, storage metadata, and broader Web APIs. L4 addresses high-fidelity hardware vectors like silicon and audio fingerprinting. L5 and L6, labeled "weaponized vectors" and "social engineering" respectively, are where the naming gets provocative — but the implementation scope column tells the real story. Even keylogger.js is described as merely a Keyboard Layout API query, and formjack.js is an HTMLFormElement requestSubmit availability check. These are capability probes, not attack implementations.
That distinction is the most important thing for a professional to understand about this tool. A file named cache_exfil.js sounds alarming until you read that it performs a Cache Storage bucket inventory — listing what cache buckets exist for the origin, not shipping them anywhere. Similarly, indexeddb_raid.js enumerates the origin's IndexedDB database list locally, session_hijack.js checks storage state and whether cookies are enabled, and history_sniff.js inspects the History API stack and scroll state. Each module is answering the question "what does the browser expose here?" rather than "how do I steal this?" The naming is theatrical, but the code behavior, as documented, is diagnostic.
The L4 tier is arguably the most technically interesting from a defensive research perspective. spectre_probe.js checks for COOP/COEP headers and SharedArrayBuffer availability — effectively testing whether a site has deployed the cross-origin isolation mitigations that followed the speculative-execution disclosures. timing_oracle.js audits precision timers and isolation state, and webgl_shader_exploit.js queries GLSL shader precision bits, a classic fingerprinting surface. service_worker_mitm.js audits ServiceWorker registration state, which matters because a malicious service worker is a genuine persistence and interception vector in real-world web compromises. These modules give a trainer concrete, observable browser behaviors to demonstrate why headers like Cross-Origin-Opener-Policy matter.
The L5 and L6 tiers work the same way. clickjack_engine.js evaluates window framing state via the classic top !== self check; pastejack.js queries Clipboard API permission state; tab_napping.js reads Page Visibility API status; dns_rebinding.js inspects origin and document.domain boundaries. On the social engineering side, notification_phish.js checks Notification API permission state, oauth_hijack.js checks for popup window interfaces, and camera_capture.js and screen_capture.js probe UserMedia and Display Media API constraints. In an authorized awareness training session, each of these maps neatly onto a real-world attack class the trainee can then be taught to recognize and defend against.
Every module follows a uniform interface — an id, title, level, info string, steps array, and an async run() function returning a structured payload — which keeps behavior predictable and auditable. Execution follows a strict lifecycle: the UI triggers the engine, the engine calls the module's run(), the module performs a native Web API probe, and the result renders into a local terminal-style UI. The README includes both a Mermaid flowchart of the discovery pipeline and a sequence diagram of this runtime flow, which is more architectural documentation than most hobby security repos provide.
From a data-handling standpoint, the tool's telemetry posture is unusual and worth emphasizing: there is none, externally. The core transmitter.js is described as a "Local Auditor" performing IndexedDB audit dispatch into an isolated database named SilentSnifferAuditLogDB. persistence.js checks the Storage Persistence API, and evasion.js detects automation indicators — presumably to flag when the sandbox itself is running under headless automation rather than a real user profile. A defender who encounters this database on a corporate machine should read it as evidence someone ran a privacy self-audit, not as an indicator of compromise.
The obvious deployment contexts are awareness training, browser-hardening workshops, and web developer education. A team building a new web application could run relevant modules against their own origin to sanity-check which Web APIs their site's JavaScript environment exposes, and use the L4 probes to verify that cross-origin isolation headers are actually taking effect. The live demo hosted on the project's GitHub Pages makes it trivially accessible for a classroom. The standard installation path is simply git clone https://github.com/AhmadHassan-BTed/SilentSniffer and opening index.html or debug.html locally — no build step, no server, no dependencies to worry about.
Caveats worth noting: the license field is marked NOASSERTION in the repository metadata despite an MIT badge in the README, so commercial reuse requires clarification. The dramatic naming of L5/L6 modules may trip security tooling or content filters in enterprise environments, even though the behavior is benign. And because everything is client-side JavaScript, the tool's guarantees about locality rest on trusting the hosted demo versus a self-cloned copy — for any serious use, clone and read the code first. Within those bounds, SilentSniffer is a well-documented, genuinely educational piece of browser privacy research that trades operational capability for demonstrable safety, and that trade is exactly what makes it useful in the hands of defenders and trainers.
AhmadHassan-BTed/SilentSniffer.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.