# OWASP Nettacker: a modular Python scanner for recon and vulnerability assessment

> Nettacker is an OWASP-hosted, Apache-2.0 penetration testing framework that runs port scans, service detection, subdomain enumeration and credential brute-force checks through modules, with CLI, REST API and web UI front ends. It fits repeatable reconnaissance and drift detection better than one-off manual probing.

**OWASP/Nettacker** — Automated Penetration Testing Framework - Open-Source Vulnerability Scanner - Vulnerability Management

- Repository: https://github.com/OWASP/Nettacker
- Website: https://owasp.org/nettacker
- Stars: 5,632 · Forks: 1,193
- Language: Python
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/owasp-nettacker

## What Nettacker automates, and who is expected to run it

Nettacker is an automated penetration testing and information gathering framework written in Python and hosted under the OWASP umbrella. The README describes its audience as cyber security professionals and ethical hackers doing reconnaissance, vulnerability assessments and network security audits. It is not a general-purpose scanner you point at anything: the disclaimer at the top of the README states the software was created for automated penetration testing and information gathering and that you must obtain permission from system owners before targeting anything.

The work it covers is breadth-first. Port scanning, service detection, subdomain enumeration, network mapping, vulnerability scanning and credential brute-force testing are all listed as in scope, across HTTP/HTTPS, FTP, SSH, SMB, SMTP, ICMP, TELNET and XML-RPC. That mix tells you what it is for: an engagement where you need to know which hosts are alive, what is listening, and whether default credentials still work, before you spend time on anything deeper. The README also names bug bounty recon, shadow IT discovery and CI/CD compliance monitoring as use cases, which is a wider net than a classic pentest tool aims at.

## Modules, the database, and how a scan actually flows

The architecture is module-per-task. The README states that each task, whether port scanning, directory discovery, subdomain enumeration, vulnerability checks or credential brute-forcing, is implemented as its own module, and that this gives you control over what runs. In practice that means a scan is a selection: you pass a module name such as port_scan or http_status_scan, and only that module's logic executes against the targets. Targets can be single IPv4 addresses, ranges, CIDR blocks, domain names or full HTTP/HTTPS URLs, mixed in one command or read from a file via the -l/--targets-list flag.

The second half of the design is state. The README describes a built-in database that stores past scans for search and comparison with current results, and calls out drift detection as the reason: finding new hosts, open ports or vulnerabilities that appeared since the last run. That is the part that changes how you use the tool. A single scan is a snapshot; the stored history is what makes the output actionable, particularly in a pipeline where you want to know what changed rather than what exists.

Execution is multithreaded and multi-protocol, and the README mentions evasion options: configurable delays, proxy support and randomized user-agents to reduce detection by firewalls or IDS. Those are settings you configure, not defaults you should assume. Reporting goes out in HTML, JSON, CSV and plain text, and the framework is exposed three ways: a CLI, a REST API and a web UI.

## Installing Nettacker with Docker and running a first port scan

The fastest path in the README is the published Docker image, which avoids resolving the Python dependency set yourself. The first command below runs a port scan against a single address; the second scans a /24 and filters for port 22. Expect the tool to print progress and then a summary of results, with the detailed report written under the results path.

```bash
docker run owasp/nettacker -i 192.168.0.1 -m port_scan
docker run owasp/nettacker -i 192.168.0.0/24 -m port_scan -g 22
```

The README also shows a reconnaissance-style invocation that enables subdomain discovery and reports HTTP status codes for a domain:

```bash
docker run owasp/nettacker -i owasp.org -d -s -m http_status_scan
```

If you want the web interface instead of the CLI, the repository ships a docker-compose.yml whose service builds from the local Dockerfile, starts the API with --start-api --api-host 0.0.0.0, and maps port 5000. Bringing it up looks like this:

```bash
docker-compose up
```

The README says to log in to the web GUI with the API key displayed in the CLI, and that the GUI is reachable at https://localhost:5000. The compose file mounts ./nettacker into the container, so the SQLite database at .nettacker/data/nettacker.db and the results directory at .nettacker/data/results survive a docker-compose down. If you miss the key on startup, the README notes you can retrieve it with docker logs nettacker_nettacker. Installation without Docker is documented at the Read the Docs installation page, and pyproject.toml constrains the interpreter to ^3.10, <3.13.

## Where Nettacker is the wrong tool

The module model is also the main limitation. A module performs the check its author wrote; it does not reason about application logic. If you need to find a broken access control flaw or a second-order injection in a web app, a port and status-code scan will not surface it, and the README does not claim otherwise. Read the feature list as recon and service-level assessment, and treat any deeper web testing as out of scope for this repository.

The credential brute-force modules deserve the same caution. They are listed as a feature, and running them against an account you do not own can lock out real users or trigger alerting. The README's disclaimer is explicit that contributors accept no responsibility for illegal usage, which is a statement about liability, not a safety mechanism inside the tool.

There is also an operational constraint in the packaging. Nettacker depends on apsw, impacket, paramiko and uvloop, among others, and uvloop is marked in pyproject.toml as not applying on Windows. The Dockerfile builds against python:3.11.16-slim and installs gcc and libssl-dev in a builder stage, so a bare-metal install on a minimal host will need a compiler and OpenSSL headers before Poetry can resolve the dependency tree. The README documents the Docker route in detail and points elsewhere for native installation; if you are not on Docker, budget time for that.

## How Nettacker differs from a general-purpose vulnerability scanner

The obvious comparison is a scanner built around a vulnerability signature feed, where you point it at a target and it reports findings mapped to CVEs. Nettacker is organised differently: the unit of work is a module you choose, and the persistent artifact is a scan history you compare over time. That makes it closer to a scheduled reconnaissance harness than to a report generator.

A second comparison is to single-purpose tools. An async port scanner will enumerate ports faster and with fewer moving parts, and a subdomain enumeration tool will do its one job with a narrower dependency surface. Nettacker's argument is consolidation: one target syntax, one output format set, one database, one API, across port scans, subdomain enumeration, service checks and brute-force modules. If your workflow is already a pipeline of small tools glued together by scripts, Nettacker replaces the glue, not necessarily the individual tools.

The third difference is distribution. It ships as a Python package with a Poetry lockfile and as a Docker image, and it exposes a REST API plus a web UI. A CLI-only scanner gives you a binary and a config file. Nettacker gives you an HTTP surface, which is convenient for CI integration and also something you now have to secure: the compose file binds the API to 0.0.0.0 on port 5000, so the network placement of that container is your decision, not the project's.

## Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-22. Release history is uneven rather than continuous: 0.4.0 landed on 2024-09-27, 0.4.1 on 2026-08-24, and pyproject.toml already declares version 0.4.2 with the release name QUIN, so a further release is in preparation. If you pin to 0.4.1, expect a gap of roughly two years between the two most recent published versions, and plan upgrades around releases rather than around the master branch.

The licence is Apache-2.0, declared in both the LICENSE file and pyproject.toml. That is a permissive licence with an explicit patent grant and a requirement to preserve notices; it is not copyleft, so it does not force you to publish modifications. The repository also carries EXTERNAL_LIBRARIES_LICENSES.md, which matters because the dependency list includes impacket, paramiko, pymysql and apsw, each with its own terms. If you redistribute Nettacker inside a product, that file is where you check what you are actually shipping. This is a description of the project's licensing, not legal advice.

Upgrade cost is dominated by the interpreter constraint and the dependency pins. pyproject.toml allows Python ^3.10, <3.13, so a Python 3.13 environment will not resolve. The Dockerfile pins python:3.11.16-slim as the base image, which gives you a reproducible runtime but also means the image trails whatever the current 3.11 patch release is until the build argument is changed. The Makefile defines the maintenance path the project itself uses: make test runs the unit suite and then builds a package and runs the package tests, with make pre-commit running pre-commit across all files.

## Conclusion

Adopt Nettacker if you already have written authorisation for the target range and you want repeatable, database-backed scans that you can diff between runs. Do not adopt it as a first-line web application scanner: its modules are recon and service-level checks, not deep request-level fuzzing, and the README's own disclaimer puts responsibility for lawful targeting on you. Before rolling it out, verify the module list for your protocols, confirm the SQLite path .nettacker/data/nettacker.db is writable and backed up, and check that your Python version satisfies the pyproject constraint of ^3.10, <3.13.

## FAQ

### How do I use Nettacker?

Run a module against a target. The README shows docker run owasp/nettacker -i 192.168.0.1 -m port_scan for a basic port scan, and docker run owasp/nettacker -i owasp.org -d -s -m http_status_scan to scan subdomains for HTTP services and report status codes.

### Is there a free OWASP scanner available?

OWASP Nettacker is an open-source project hosted by OWASP and licensed under Apache-2.0, so there is no licence fee to use it. It covers reconnaissance and service-level checks such as port scanning, subdomain enumeration and credential brute-forcing rather than deep application testing.

### What is Nettacker used for?

The README lists penetration testing, reconnaissance and vulnerability assessment, attack surface mapping, bug bounty recon, network vulnerability scanning, shadow IT discovery, and CI/CD compliance monitoring. Each task runs as a separate module, and past scans are stored so you can compare results over time.

### Does Nettacker need Docker?

No, but Docker is the path the README documents in most detail, both as the owasp/nettacker image and through the repository's docker-compose.yml. The README points to the Read the Docs installation page for installing without Docker, and pyproject.toml requires Python ^3.10, <3.13.

### Where does Nettacker store its scan results?

The README states the local database is .nettacker/data/nettacker.db, which is SQLite, and the default results path is .nettacker/data/results. With docker-compose the ./nettacker folder is mounted into the container, so that data persists after docker-compose down.

## Sources

- [License: Apache-2.0](https://github.com/OWASP/Nettacker/blob/master/LICENSE)
- [OWASP/Nettacker on GitHub](https://github.com/OWASP/Nettacker)
- [Project website](https://owasp.org/nettacker)
- [README](https://github.com/OWASP/Nettacker/blob/master/README.md)
- [Releases](https://github.com/OWASP/Nettacker/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owasp-nettacker