Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Submit
ToolsExploitsBlog
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.

FeedsContactPrivacy© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
scan — 0-day malware detection for binaries, source & scripts (that doesn't suck) | Kitploit
Tools/GitHubGitHub/atomdrift-project/scan
Defensive ToolsStatic AnalysisVulnerability ScannersCode AnalysisDynamic Code Analysis (DAST)Reverse EngineeringMalware AnalysisBinary AnalysisThreat IntelligenceSupply Chain SecurityMachine LearningIncident Response
GitHubatomdrift-project/scan

scan

0-day malware detection for binaries, source & scripts (that doesn't suck)

View RepositoryWebsite
225923010h 59m agoReviewed by Kitploit

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

Atomdrift Scan

Latest release License

Atomdrift Scan is a modern ML-based malware scanner designed to detect 0-day attacks against the software supply-chain.

It's designed to be deterministic, fast, and flexible, and embeddable in any workflow or security tool you have in mind, and can operate against files, archives, URLs, PURLs, or processes.

As of October 2026, Atomdrift Scan has a 82%+ 0-day detection rate, +23% ahead of any other scanner: commercial or open.

Atomdrift Scan terminal output

How does Atomdrift get such great results? First, it covers more ground than any other scanner:

  • 100+ supported file formats: from C source to ELF to PDF
  • 125,000+ detection rules covering malware on every platform from AIX to iOS to Windows
  • 15,000,000+ hashes for known good/badware
  • Integrated AST analysis using tree-sitter
  • Automated binary reverse engineering via binform

Most importantly, rules are constantly refreshed using reinforcement learning against new samples, blogs, and technical articles, resulting in ~1000 updated rules daily.

Install

If you are an a UNIX-flavored host (macOS, Linux, BSD, Solaris, illumos, Android):

curl -fsSL https://install.atomdrift.org/scan.sh | sh

If you are on Windows:

irm https://install.atomdrift.org/scan.ps1 | iex

Or, if you have Rust installed and just want to build it from source:

make install

If deeper binary analysis is required, you should also install 7-Zip, upx, and innoextract.

On Windows, using winget:

winget install --exact --id 7zip.7zip
winget install --exact --id UPX.UPX
winget install --exact --id dscharrer.innoextract

On Unix-like systems, install upstream 7-Zip (brew install sevenzip, apt install 7zip) rather than p7zip — its 7z cannot read APFS, so .dmg contents go unscanned.

Usage

# Scan a file, directory, or archive recusively:
atomscan ./project
atomscan release.tgz

# Fetch a package from its registry and scan it.
atomscan purl npm/[email protected]

# Fetch and scan a URL.
atomscan url https://example.com/download

# EXPERIMENTAL: Scan running process executables, or triage the wider host
atomscan ps
atomscan sys

# JSON output for programmatic access
atomscan -f json ./project

Exit codes make CI integration trivial:

  • 0: all samples are benign
  • 1: hostile sample detected
  • 2: suspicious sample detected
  • 3: analysis error
  • 4: the rule set was incomplete — the scan ran with fewer rules than the trait set defines, so anything short of hostile proves nothing. Re-run it.
  • 130: interrupted (Ctrl-C) before every file was analyzed

How it works

Diagram

  1. stng extracts content, even if obfuscated
  2. cleave unpacks containers and extracts capabilities
  3. The report is converted into a standardized feature vector, standardized across file types.
  4. azoth LightGBM model ensembles score the sample.

Networking and privacy

atomscan will never send telemetry data. It will however reach out to the Internet for 3 reasons:

  • rule updates: every 24h; disable with --no-update
  • release check: once a day, to say a newer atomscan exists; disable with SCAN_NO_UPDATE_CHECK=1
  • following discovered references: to detect if a benign package depends on or downloads a compromised payload. Set --follow=none to analyze only the requested artifact.

Downloaded dependencies are analyzed under the current rules unless a local analysis report or a matching-analyzer corpus verdict can be reused. A recent clean verdict from another analyzer does not replace analysis of downloaded bytes. Package-coordinate lookups may still use that recent clean verdict to avoid downloading an already-known dependency.

Tune the false-positive level

Use -l to choose a pool-adjusted false-positive level:

  • -l0: zero observed calibration FPs; the strictest setting.
  • -l1: one FP in the benign calibration pool.
  • -l25: the default; one FP plus an estimated additional 24 per 100 million benign files (approximately “one plus 25 per 100 million”).
  • -l1000: one FP plus an estimated additional 999 per 100 million benign files.

For a pool of N benign files, L0 allows zero observed false positives. Every positive level L has a continuous allowance of 1 + (L - 1) * N / 100_000_000; an integer FP-count budget rounds this down. L1 allows one FP. L25 means one FP plus an estimated additional 24 per 100 million benign files (approximately “one plus 25 per 100 million”). The initial FP belongs to the decision pool, not to each component model or each scan invocation.

These are calibration targets, not guaranteed future rates. Small pools need interpolation or extrapolation to estimate finer rate differences; observed counts, estimated rates, and uncertainty must remain separate. L0 means zero observed calibration FPs, not zero future risk.

Only detection regressions at L0 through L25 (inclusive) can block model acceptance. Changes above L25 remain reportable but do not block installation. Calibration FP allowances still apply at every level; empirical test FP overruns are reported and do not block installation by default.

The shared definition is in Collimator’s level contract. Existing model thresholds and reported measurements are unchanged by this documentation correction.

Optional local LLM (interpretation)

For additional interpretation, users can provide access to an LLM via the --llm flag. This flag serves two purposes:

  • Provides a large-language model text interpretation of the results
  • Steer edge cases based on agreement/disagreement with the ML model ( p to 33%)

By default, atomscan sends the interpreted evidence (not the original file) to http://localhost:8000/v1 - to be used with a local service like Ollama or vLLM; but it can also be setup to use a remote service like Claude, ChatGPT, or DeepSeek.

No model is hardcoded: unless you pass --llm-model, atomscan asks the endpoint which models it serves and uses the largest one it lists. We recommend serving Qwen/Qwen3.8-27B.

If the endpoint requires a bearer token, put it in ~/.tok/llm (mode 0600) and atomscan sends it automatically; SCAN_LLM_KEY overrides that file.

--llm also takes a comma-separated failover chain, tried in order — --llm 'https://llm.isotope13.ai/v1,openrouter' grades on your own endpoint and reaches for the billed one only when it cannot answer.

atomscan --llm ./project
atomscan --llm http://model-host:8000/v1 --llm-model my-model ./project
atomscan --llm openrouter --llm-model qwen/qwen3.8-27b ./project
Download Tool