nox-framework is an async, plugin-driven OSINT and threat intelligence engine that automates breach lookup, hash cracking telemetry, and recursive identity pivoting for authorized exposure assessments.
| Tool | nox-project/nox-framework — fully async CTI/OSINT framework with 124 JSON plugin sources and recursive identity pivoting |
| Category | OSINT / cyber threat intelligence automation |
| Primary Use | Automated breach-exposure and identity-correlation analysis via --autoscan, covering breach scans, dorking, paste scraping, and hash pivoting |
| Safe Use | Documented analysis for authorized penetration tests, bug bounty research, internal corporate exposure reviews, and defensive credential-audit programs with written permission |
| Telemetry Note | Leaves detailed local logs in ~/.nox/logs/nox.log and stores API keys in ~/.config/nox-cli/apikeys.json; from the defender's side, its traffic patterns — parallel queries from rotating public proxies, Tor exits, or JA3-fingerprinted aiohttp clients — are observable at egress |
nox-framework positions itself not as another wrapper around theHarvester-style tooling but as a purpose-built cyber threat intelligence engine, and the README's architecture section backs that claim up with unusual specificity. The core split is a strict separation between nox.py — a pure, agnostic async execution engine handling I/O, JA3 fingerprinting, SSL session management, and correlation — and sources/*.json, the plugin files that define every intelligence query, authentication header, and extraction regex. There is zero hardcoded source logic in the engine, which means the framework's entire intelligence surface is data, not code. At the time of writing the project reports 325 stars, a Python 3.8+ requirement, and version v1.0.5, with Apache 2.0 claimed in the badge although the repo metadata shows NOASSERTION, so licensing should be verified before enterprise adoption.
The headline capability is what the author calls the Recursive Avalanche Engine. Every identifier discovered during a scan — a username pulled from a breach record, an email found in a dork hit, a plaintext recovered from a hash — is automatically re-injected as a new scan seed. The per-asset pipeline runs four phases sequentially: breach scan, hash crack, dorking, then paste/Telegram scraping, while child assets fan out concurrently via asyncio.gather. Two guardrails keep this from exploding combinatorially: a global seen_assets set that deduplicates across the whole discovery tree, and a configurable --depth cap with a default of 2 that acts as a hard backstop against runaway recursion. --no-pivot disables enrichment entirely for a fast breach-only pass.
The --autoscan flag is the one-command entry point that chains everything together, and it is worth understanding what it actually orchestrates because that defines the tool's blast radius. Phase 1 fans all 124 breach sources out in parallel; Phase 2 identifies any hashes found in breach data (MD5/NTLM, SHA1, SHA256, bcrypt) and queries multiple rainbow-table APIs concurrently in a background task; Phase 3 runs Google/Bing/SearXNG dorks for leaked documents, .env files, and SQL dumps with PDF/Office metadata extraction; Phase 4 scrapes paste sites, IntelX, and Telegram CTI channels. Identifiers from all four phases feed the pivot queue. Notably, the authors included --no-online-crack, which restricts cracking to a local wordlist so no hash data is sent to third-party APIs — a genuinely thoughtful control for engagements with data-handling restrictions.
The Guardian Proxy Engine is the OPSEC layer, and the README is refreshingly honest about its limits. With no flags supplied, Guardian activates automatically: it first looks for a proxies.txt file in the working directory, and failing that dynamically fetches and validates a pool of high-anonymity public proxies held in memory, never written to disk. A fail-safe kill-switch halts all traffic if the transport circuit drops, preventing accidental direct-connection leaks mid-scan. But the README carries an explicit warning that public proxy pools are inherently untrusted infrastructure, and recommends --proxy with a controlled HTTP/S or SOCKS5 endpoint, or --tor routing via stem with the tor service on port 9050, for sensitive engagements. That warning deserves to be taken seriously — routing breach-data lookups through anonymous third parties is an operational risk in both directions.
Plugin authoring follows a build-artifact pattern that will feel familiar to anyone who has maintained generated-code pipelines. The JSON plugins in sources/ are auto-generated; the only sanctioned way to create or modify them is build_sources.py, and the README states plainly that manual edits to the JSON will be overwritten on the next build. The schema itself is compact and well-documented: endpoint, method, headers, either a regex_pattern or a json_root plus normalization_map for structured APIs, required_api_key_name, input_type, output_type, pivot_types, and a confidence score. The api_key_slots field enables round-robin key rotation across multiple keys to sidestep per-key rate limits, which is a pragmatic touch for operators juggling free-tier API quotas.
Risk scoring is where nox-framework tries to move from raw enumeration to decision support. The engine computes a dynamic 0–100 score incorporating time-decay on stale findings, per-source confidence weighting drawn from each plugin's confidence field, password complexity analysis on recovered plaintexts, persistence multipliers, and HVT detection that auto-flags C-level, Admin, DevOps, and government-domain accounts as high-value targets. For blue-team and audit use, this scoring model is arguably the most defensible part of the tool: it converts a wall of breach records into a prioritized list of which identities actually matter, which is exactly the output a CISO needs when triaging a credential-exposure report.
Identity correlation across the 124 sources is handled by a Union-Find clustering engine that unifies breach records into identity clusters, with type-aware pivot classification deciding how a discovered identifier can be reused as a seed. Combined with the reporting layer — PDF, HTML, JSON, CSV, and Markdown outputs featuring an Executive Summary dashboard with metrics like Total Time, Nodes Discovered, Cleartext Passwords, and Pivot Depth, plus an interactive Pivot Chain Visualization — the framework is clearly aimed at producing deliverables an authorized assessor can hand to a client rather than terminal spew. JSON exports are self-describing with a full metadata block, and the README emphasizes strict data sanitization so technical noise stays out of the report.
Operational ergonomics are consistently considered. --list-sources prints a debug table showing each plugin's name, input type, confidence score, and key status — configured, not configured, or public — plus any JSON parse errors, which turns source triage into a single command. API keys live in ~/.config/nox-cli/apikeys.json with chmod 0600 permissions, unconfigured keys are silently skipped rather than crashing the scan, and keys set via environment variable are picked up without a restart. All scan events, pivot discoveries, rate-limits, and crack attempts are logged to ~/.nox/logs/nox.log while only actionable intelligence reaches the terminal. For defenders, that log path and the key-store path are useful artifacts when inventorying what ran on a workstation.
From a defensive telemetry perspective, nox-framework is quite visible to anyone watching egress. Its core is a full asyncio event loop built on aiohttp with JA3 fingerprinting and per-request jitter, querying up to 124 external endpoints in parallel, frequently through rotating public proxies, Tor exit nodes, or SOCKS5 chains validated via aiohttp-socks. A security team monitoring outbound traffic will see bursts of breach-lookup API calls and search-engine dorking from infrastructure that does not match the user's normal footprint. That observability cuts both ways: it makes unauthorized use detectable, and it reminds authorized operators that OPSEC plumbing alone does not make an assessment invisible to the target's own intelligence feeds.
The appropriate home for nox-framework is the authorized side of the house: external attack-surface reviews, bug bounty reconnaissance within program scope, internal credential-exposure audits, and red-team footprinting under a signed rules-of-engagement document. The combination of recursive pivoting, password-recycling analysis, and HVT flagging is powerful, which is precisely why scope discipline matters — pointed at third parties without authorization, the same engine becomes a harassment and privacy-violation instrument. Used inside a defined engagement, with --no-online-crack where data-sharing rules demand it and controlled proxies instead of public pools, it is one of the more architecturally coherent Python OSINT frameworks currently published, and the plugin-sources-as-data design makes it unusually extensible for teams that want to bolt on private intelligence feeds.
nox-project/nox-framework.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.