Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
cve-2021-35394-ecosystem — Tracking the family of unrelated IoT botnets sharing CVE-2021-35394 as a delivery vector — findings, relationships, methodology. | Kitploit
Tools/GitHubGitHub/graphworlok/cve-2021-35394-ecosystem
Indicator of Compromise (IOC) ManagementIoT SecurityVulnerability AnalysisReverse EngineeringMalware AnalysisDigital ForensicsThreat IntelligencePapers & Research

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share
GitHub
graphworlok/cve-2021-35394-ecosystem

cve-2021-35394-ecosystem

Tracking the family of unrelated IoT botnets sharing CVE-2021-35394 as a delivery vector — findings, relationships, methodology.

View Repository
6h 52m agoNot yet reviewed

CVE-2021-35394 Ecosystem

This repo exists because one exploit happens to make these botnets visible to a passive sensor — not because they're related to each other. CVE-2021-35394 (Realtek SDK command injection, UDP/9034) is the entry criterion: a family is in scope because it was observed attempting this exploit against a monitored network. Once a family is in scope, tracking follows that family's own infrastructure and behaviour as far as it can be reached — staging servers, dropper scripts, other samples — even where none of that activity is itself this CVE. The vulnerability is the door being watched, not a claim about what's behind it.

Findings so far cover six code-independent families sharing this one exploit: Condi, cling, goonbakk (aka lucy_meow), RondoDox, and two as yet unnamed (tracked as "family D" and "family E" pending a naming decision — see NAMING.md).

Layout

root@kitploit:~
METHODOLOGY.md          observation bias — read before drawing conclusions
HANDOFF.md              session-continuity state
analysis/<family>/      RE reference record, one doc per family
analysis/comparison.md  cross-family diagram, three-tier confidence
samples/manifest.csv    generated index of the local collection (hashes only)
samples/README.md       manifest conventions + what it shows on its own
tools/inventory.py      regenerates the manifest from a collection directory

Two layers, deliberately separate. analysis/ is what the binaries do, written by hand from Ghidra. samples/ is what the collection holds, generated by scanning it — headers, hashes, build IDs, provenance. The second is cheap to keep current (python tools/inventory.py) and catches things the first can't: which served names are the same build, which "samples" aren't binaries at all, which Ghidra program corresponds to which served file. Findings that fall out of the inventory get promoted into the relevant analysis/ doc rather than living in the CSV.

Adding a family is a directory under analysis/ and, once its staging host is attributed on evidence, a line in tools/inventory.py's FAMILY_BY_HOST plus a row in the attribution table in samples/README.md.

Read this first

METHODOLOGY.md — this dataset has a real observation bias baked into it (the exploit vector we can see is UDP-only and needs no listener; every other vector these families use needs a completed TCP handshake, which nothing on the collection side provided until now). Read it before drawing conclusions from anything else in this repo.

Open questions

  • Family naming: goonbakk is primary, lucy_meow an alias (same family — identical ChaCha20 key/nonce/counter-quirk and config table). Real names still needed for "family D" and "family E" (the latter richly characterised already: Go, Botnet/ module tree, C2 on :9111, on-disk sysd) — check whether Akamai's report names E before inventing one.
  • Public or private? This repo tracks live, currently active C2 infrastructure and gets updated as campaigns evolve, so the default is private unless there's a reason to publish (e.g. after infrastructure is confirmed dead, or for community benefit as an IOC feed). Flip it deliberately, not by default.
  • Layers not yet built, in rough value order:
    • docs/families/<family>.md — prose overview per family (capabilities, IOCs, aliases), the layer analysis/ links up into
    • hunts/ — Security Onion / NSM queries, kept runnable rather than quoted in prose
    • iocs/ — machine-readable network/host indicators per family. Partly subsumed by samples/manifest.csv for file indicators; the gap is C2 endpoints and the delivery-kit fingerprint
    • yara/ — detection rules

Settled, don't re-litigate (see HANDOFF.md for the full list): samples are hashes only — no functional malware enters git history, enforced by .gitignore; no "Mirai lineage" as an organizing principle; CVE-2021-35394 is the entry criterion, not the scope.

Download Tool
  • relationship/timeline doc — infrastructure rotation and port-set profiling that doesn't belong to any single family's file. analysis/comparison.md covers the code/capability half of this