dddd is a Go-based batch asset collection and vulnerability detection tool that chains fingerprinting, subdomain enumeration, and Nuclei v3 checks for authorized red team workflows.
| Tool | SleepingBag945/dddd — batch information gathering and supply chain vulnerability detection tool for red team workflows |
| Category | Asset discovery and vulnerability scanner (Go, MIT license, ~1.9k stars) |
| Primary Use | Pulling batch targets from Hunter, Fofa, and Quake, then fingerprinting and running Nuclei v3 PoC checks during authorized external or internal assessments |
| Safe Use | Designed for legally authorized enterprise security assessments; the README's disclaimer explicitly restricts use to authorized targets and self-built lab environments |
| Telemetry Note | Leaves an audit.log of all scanning behavior when -a is enabled; HTML reports embed full vulnerability request/response pairs; third-party API queries to Hunter/Fofa/Quake are observable by those providers |
dddd is an open-source reconnaissance and vulnerability detection framework written in Go by SleepingBag945, distributed under an MIT license with roughly 1,900 stars on GitHub. Its stated purpose is to compress the mechanical, repetitive portion of a red team engagement — enumerating assets, fingerprinting services, and triaging which known vulnerabilities actually apply — into a single batch pipeline. The name is deliberately unassuming, but the toolchain it wraps is not: the README credits fscan, kscan, gonmap, nuclei, subfinder, httpx, naabu, gogo, and afrog as references, which tells you immediately where it sits in the ecosystem. It is essentially an orchestration layer over the projectdiscovery stack plus Chinese cyberspace-search APIs, tuned for operators who need breadth before depth.
The first design decision worth noting is automatic input-type recognition. You hand dddd a target with -t and it figures out whether you mean a single IP, a CIDR range like 192.168.0.1/24, an IP span such as 192.168.0.0-192.168.0.12, a host with a port, or a URL. There is no mode flag separating "network scan" from "web scan" from "domain pivot" — the target syntax itself drives the pipeline. For an analyst moving between internal segments and external perimeters, this removes a whole class of invocation errors and makes the tool scriptable in ways that mode-heavy scanners are not.
The second pillar is fingerprinting, and this is where the README spends most of its architectural effort. dddd supports both active and passive fingerprint identification, with an extension system for adding new signatures. More interesting is the fingerprint expression language: signatures support complex AND/OR/NOT logic with parentheses, which the author describes as human-friendly. That matters because real-world service identification is rarely a single-banner match — a Jenkins instance behind a reverse proxy with a customized error page may only be identifiable by a compound condition. A boolean grammar for fingerprints is a genuine quality-of-life feature compared to the flat keyword lists many scanners use.
Hand in hand with fingerprinting comes the fingerprint-to-vulnerability mapping database. The README emphasizes that this mapping exists to avoid useless packet sending: rather than blasting every known Nuclei template at every discovered service, dddd maps each identified fingerprint to the specific PoCs that plausibly apply. This is the same triage philosophy behind tools like gogo and afrog, and it is the feature that most directly reduces network noise. For defenders reading this analytically, it also means the tool's traffic pattern is fingerprint-driven and selective rather than exhaustive, which affects how its scans appear in IDS telemetry.
Version three Nuclei template support is baked in, so the PoC engine inherits the entire public template ecosystem. Combined with the mapping database, the workflow is: discover assets, identify what they are via fingerprints, then run only the relevant nuclei templates against the matches. The -npoc flag lets you stop after fingerprinting entirely, which is a sensible mode for pure asset inventory work during scoping or for environments where active exploitation-adjacent checks are out of scope. That granularity is the difference between a scanner you can point at a production segment during a maintenance window and one you cannot.
Subdomain enumeration and brute-forcing are also first-class, with what the README calls precise wildcard-resolution filtering. Wildcard DNS is the classic false-positive generator in subdomain bruteforcing — every guessed hostname resolves, and naive tools report thousands of phantom subdomains. dddd's claim of precise filtering suggests it probes for wildcard behavior before trusting resolution results, which aligns with how subfinder and similar tools handle the problem. The -sd flag runs local subdomain enumeration against a given domain, complementing the external-API-driven collection paths.
That external collection path is the supply-chain angle: dddd integrates with Hunter, Fofa, and Quake, the three dominant cyberspace search engines in the Chinese market. You can pass a search query directly as the target, for example pulling all assets associated with a company's ICP registration record via Hunter, optionally supplementing port data from Fofa with -fofa, and writing discovered IPs with -oip. The README also documents a Hunter low-perception mode, which reduces query footprint against that provider — a consumption-optimization feature rather than anything stealth-related to the target. Operationally, this is the external-attack-surface mapping phase: enumerate what the organization actually exposes before touching it.
Output is handled in three parallel channels. Plain text results go to result.txt by default, overridable with -o, with -ot switching to JSON. Vulnerability findings render into an HTML report — named by timestamp by default, redirectable with -ho — that includes full request and response pairs for each finding, which is exactly what a client-facing deliverable needs for reproducibility. Critically, all outputs are written incrementally as results arrive, so an interrupted scan still preserves everything discovered up to that point. Anyone who has lost a four-hour scan to a network blip will appreciate that.
The audit log deserves separate treatment because it is unusual in this tool class. Passing -a records detailed scanning behavior to audit.log, and the README positions it as essential for sensitive environments — with a parenthetical joke about assigning blame after the fact. In practice this is an accountability feature: when a scan runs against a scoped environment, the log documents what was sent when, which is valuable both for post-engagement review and for demonstrating that an operator stayed inside the authorized perimeter. Few offensive-reconnaissance tools ship this, and its presence signals the author's awareness that dddd gets used in regulated contexts.
Installation is deliberately low-friction. The project ships prebuilt binaries in its Release section alongside a config.zip, and since v2.0 the binary can run independently of the config folder. With Go as the language and no heavyweight runtime dependencies, it works out of the box across operating systems, which fits the "bring your own laptop to the client site" reality of consulting work. A minimal invocation is simply dddd -t 192.168.0.1 for a host or dddd -t http://test.com for a web target — beyond that, no operational recipes are needed to evaluate the tool, and none are appropriate here.
The disclaimer section is explicit and worth quoting in substance: the tool is intended solely for legally authorized enterprise security construction, testers should build their own lab environments to validate it, and scanning non-authorized targets is prohibited outright. That framing matches how this tool should be read — as engagement tooling for contracted assessments, internal attack-surface management, and lab research, not as something to point at infrastructure you do not own. The scenario cheat-sheet in the README reflects the same legitimate workflow: external surface mapping from ICP records, internal segment scanning, and fingerprint-only inventory passes.
From a defensive perspective, dddd is worth studying even if you never run it, because it represents the current baseline of what an automated adversary's initial reconnaissance looks like. Its traffic is fingerprint-selective rather than exhaustive, it leverages third-party cyberspace indexes instead of direct probing wherever possible, and its findings are packaged into immediately actionable reports. Defenders can use that knowledge to prioritize: accurate service fingerprinting defeats generic banner obfuscation, wildcard DNS hygiene degrades subdomain enumeration, and monitoring for known-vulnerable service exposure closes the gap the fingerprint-to-PoC mapping exploits. As an educational artifact and an authorized-assessment workhorse, dddd earns its stars.
SleepingBag945/dddd.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.