NextronSystems/iocs is a GitHub repository of indicators of compromise distilled from malware and APT research, built for defenders and authorized analysts doing detection engineering.

NextronSystems/iocs is not a tool in the traditional sense of a binary you run — it is a living repository of indicators of compromise (IOCs) published by the Nextron Threat Research team, the research arm behind the THOR scanner vendor Nextron Systems. Where most IOC dumps arrive as unstructured CSV spam in a vendor blog post, this repo organizes its intelligence into per-campaign directories under reports/, each pairing raw indicators with the analysis that produced them. For detection engineers and incident responders, that structure matters: an indicator divorced from its analytical context is nearly useless when you need to explain to a client or a SOC lead why a particular mutex or SHA256 hash warrants escalation.

The repository's README is deliberately spare — a title, a two-line mission statement, and an index of nine report directories. But that index reads like a cross-section of 2024–2025 threat activity. The campaigns covered include Peach-Sandstorm and its False Font malware, DarkPink with the KamiKakaBot family, an in-depth analysis of Lynx ransomware, the Katz Stealer threat, a Linux PAM backdoor the researchers call Plague, an APT36 dropper referred to as Sindoor, a set of WHQL-signed Windows kernel drivers, bootkits, and an SSH hijacking toolkit. Each entry links to a dedicated readme.md inside reports/, so the repo behaves like a miniature threat-intel portal with per-actor chapters rather than a flat indicator feed.

The coverage pattern itself is analytically interesting. You have nation-state-adjacent intrusion sets (Peach-Sandstorm is publicly attributed to Iranian-aligned activity, APT36 to Pakistan-aligned operators) sitting alongside commodity criminal ecosystems (Lynx ransomware, Katz Stealer). The Plague Linux PAM backdoor entry signals attention to persistence mechanisms on Linux hosts, an area many IOC feeds neglect entirely, while the SSH hijack directory suggests indicators around credential and session theft on exposed servers. The inclusion of WHQL-signed kernel drivers and bootkits indicates the team also tracks bootloader-level and driver-abuse tradecraft — the kind of deep-dive forensic material that transcends simple hash matching.

Operationally, the natural workflow is to clone the repository and mine the per-report directories for machine-consumable observables. A simple git clone https://github.com/NextronSystems/iocs gets you the full corpus locally, and from there the per-campaign readme.md files serve as the extraction point for C2 domains, IP addresses, file hashes, mutex names, and registry or filesystem artifacts, depending on what each report documents. Because the repo is written primarily in Python per its GitHub language metadata, some report directories may ship helper scripts or parsing logic alongside the indicators — worth inspecting before bulk-ingesting anything into a production detection pipeline, which is standard hygiene for any third-party intelligence source.

Where this collection fits best in an authorized workflow is retro-hunting and detection validation. Pull the indicators from, say, the Lynx ransomware report into your SIEM and sweep 90 days of DNS, proxy, and EDR telemetry for the documented C2 infrastructure. Do the same with KamiKakaBot artifacts against endpoint telemetry. The YARA-adjacent nature of Nextron's core business means these indicators pair naturally with their scanner and with generic YARA rule sets, but nothing in the repo ties you to their commercial stack — the value is the research-grade context, and a defender can operationalize it in any tool that accepts plain observables.

A subtle but important point for consumers: indicators age. C2 domains get burned and re-registered, IP addresses rotate, and a stale indicator can become a false positive factory — or worse, a sinkholed domain owned by a researcher, so that an internal system resolving it looks like compromise when it is nothing of the kind. The repo mitigates this somewhat by binding indicators to dated research writeups, which lets you weight freshness per campaign. Treat the ransomware and stealer entries as shorter-lived and the bootkit and PAM backdoor artifacts, which hinge on file paths and driver signatures, as more durable detection material.

The Plague Linux PAM backdoor entry deserves specific attention from defenders running mixed fleets. PAM-based persistence survives reboots and password changes because it hooks the authentication stack itself, and the observable surface — a modified .so library, unusual entries in pam.d configuration — is exactly the kind of host-artifact intelligence that log-centric detections miss. Similarly, the SSH hijack material likely covers tampering with authorized_keys, sshd binaries, or agent sockets, which pairs well with integrity monitoring on internet-facing jump hosts.

The WHQL-signed drivers and bootkit reports touch the more forensic end of the spectrum. Signed-driver abuse is a persistent problem because the artifacts often look legitimate to allowlist-based controls, so indicators there tend toward certificate serials, driver filenames, and service registration patterns rather than simple hashes. Bootkit detection similarly leans on bootloader integrity and unusual volume-boot-record modifications. These are harder hunts, but the research context in the linked writeups is what makes them tractable for a responder who has not previously worked that layer of the stack.

From a telemetry and blue-team perspective, this repository is entirely benign — it is the output of defensive research, describing attacker artifacts rather than performing anything. The defensive observation angle is inverted here: you are the defender consuming the corpus, and the relevant question is how well your existing logging surfaces the artifacts it describes. If your EDR cannot see PAM library loads or bootloader modifications, the gap those reports expose is itself actionable findings for your detection program.

Caveats worth stating plainly: the repo carries no license declared in its metadata, so before redistributing indicators internally or embedding them in a commercial product, check the terms — most vendors tolerate internal detection use but restrict republication. At roughly 22 stars it is a low-visibility resource, which reflects its specialist audience rather than its quality; Nextron's research writeups are widely cited in the DFIR community, and this repo is the machine-readable companion to that body of work. The master branch is the publication target, so track commits if you integrate it into a repeating intelligence cycle.

For anyone building a threat-intelligence program on a budget, NextronSystems/iocs is a good example of context-rich open indicator sharing: fewer campaigns than a commercial feed, but each backed by real analysis, structured for retrieval, and oriented toward the artifacts defenders can actually act on. Clone it, mine it per campaign, weight it by freshness, and let the PAM, bootkit, and signed-driver material push your detection coverage into corners that commodity feeds ignore.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• broadcom-wps for detecting vulnerable Broadcom SDK access points in firmware and over the air


• dissect for unified forensic artifact analysis across containers, filesystems, and operating systems


• dethrace for rebuilding the 1997 Carmageddon engine through reverse engineering