fscan: an intranet scanner that chains discovery, brute force and exploitation in one Go binary

What fscan replaces on an internal engagement

A typical internal assessment starts with several tools: one for live hosts, one for ports, one for service banners, one for weak passwords, and a POC runner for web bugs. fscan folds those stages into one Go binary. The README describes it as an intranet comprehensive scanning tool for one-click automated scanning, and the feature list covers host discovery, TCP connect port scanning, service identification, web probing, brute force across 28 service types, and POC scanning that accepts Xray POC format.

The audience is narrow. This is a tool for people who already have authorization to test an internal network, and the disclaimer in the README states it is only for legally authorized enterprise security work. It is not a monitoring agent, not a continuous scanner you leave running, and not a tool for scanning address space you do not own.

How the scan pipeline is wired

The repository layout separates concerns: core/, plugins/, webscan/, pkg/, common/ and libs/. The release notes for v2.1.0 describe a refactor that removed global variables in favor of Config and State objects, which matters for anyone embedding the scanner because concurrent scans no longer share mutable package state.

Service plugins, web plugins and local plugins are separated, and the build tag system lets you compile them independently. A scan flows from target parsing (IP, CIDR, domain or URL) into host discovery, then port scanning using a sliding-window scheduler with an adaptive thread pool, then service probing with an Nmap-style fallback mechanism, then plugin dispatch. The fingerprint engine uses FingerprintHub with 3139 entries according to the changelog, and the web probe identifies titles, CMS, middleware and WAF/CDN from more than 40 signatures.

The SDK at pkg/fscan exposes task control with Pause and Resume, real-time progress callbacks and TaskID tracing, which is how the project intends fscan to be embedded in an agent or platform rather than only run from a shell.

Building fscan and running a first scan

The README gives two build paths and an Arch Linux package. The standard build produces the CLI binary; the web build adds the visual task manager and is compiled with the web tag. On Arch, the AUR package fscan-git is listed as the install route.

Build from source with Go, as the compile section of the README shows:

go build -ldflags="-s -w" -trimpath -o fscan .

For the web management interface, the README uses the web build tag. Note that the Makefile's build-web target first runs build-ui, which needs Node.js and npm:

go build -tags web -ldflags="-s -w" -trimpath -o fscan-web .

A first scan against a C-class range is the quick-start example:

./fscan -h 192.168.1.1/24

The README also lists a liveness-only run, which is the safest first command because it performs no credential attempts:

./fscan -h 192.168.1.1/24 -ao

If brute force is outside your scope, disable it explicitly:

./fscan -h 192.168.1.1/24 -nobr

Output can be written as TXT, JSON or CSV. The changelog notes that the TXT writer flushes to disk in real time and appends a URL summary at the end for batch web testing.

The default configuration is not a passive scan

The most important limitation is behavioral: fscan attempts weak credential logins by default. The quick-start section includes -nobr precisely because the tool will otherwise try credentials against services it identifies. On a production network, that can lock accounts, trip intrusion detection, or violate the rules of engagement you agreed to. If your engagement is discovery-only, you must pass -nobr, and you should verify the flag is honored before pointing the tool at anything that matters.

The exploitation modules carry the same caveat. Redis exploitation can write an SSH public key, a scheduled task or a webshell, and the README shows -rf id_rsa.pub for the public key path. MS17-010 exploitation injects shellcode. These are not detection checks; they change state on the target. A scanner that can write a key to a production Redis instance is the wrong tool for any engagement where exploitation is out of scope.

A second limitation is documentation depth. The README documents flags by example rather than by reference. The README does not document rollback for the exploitation modules, and it does not describe how to reverse a written key, task or webshell. The roadmap lists fscan-lab as unfinished, so the training environment that would let you rehearse those modules safely is not complete.

fscan compared with Nmap and with POC runners

Nmap is the obvious comparison. Nmap is a mature port scanner with a scripting engine, and fscan borrows from it: the v2.1.0 changelog describes an Nmap-style fallback mechanism for service probing and an Nmap core integration covering probe strategy, a matching engine and version parsing. The difference in approach is what happens after the port opens. Nmap stays a scanner unless you write or select NSE scripts; fscan ships credential brute force and exploitation modules in the same binary and runs them as part of the default flow. That makes fscan faster to a finding on an internal network and riskier to run without reading the flags first.

For web-specific POC work, the alternative is a dedicated POC runner. fscan accepts Xray POC format according to the changelog, and it also supports afrog format, so it can consume rule sets you already have. A dedicated runner usually gives finer control over which templates run and better reporting. fscan's advantage is that the POC stage sits downstream of its own discovery and fingerprinting, so you do not have to export a target list between tools.

Maintenance cadence, licence and upgrade cost

The last push to the default branch was on 2026-09-17, four days before this writing, and the most recent release is v2.2.1 from 2026-08-25. The repository is not archived. The roadmap states a monthly release cycle, with the first two weeks for feature work and the last two for fixes.

The upgrade cost is real because the changelog is large. The v2.1.0 entry alone covers 262 commits, 30 new features, 120 fixes, 54 refactors and 14 performance changes, including a HostInfo field type change from string to int, a unified SMB plugin that merged smb, smb2, smbghost and smbinfo, and an i18n migration to go-i18n. If you embed the SDK from pkg/fscan, the roadmap promises backward compatibility for the plugin API and for existing POCs, but the Config and State migration means code that touched the old global variables will need rework.

The licence is MIT, declared in LICENSE.txt. That permits commercial and closed-source use with the usual attribution requirement. It does not shield you from the legal exposure of scanning without authorization; the README's disclaimer places that responsibility on the user. This is not legal advice, and if you plan to redistribute fscan inside a product, read the licence text rather than this summary.

Editorial conclusion

Adopt fscan when you have written authorization and need a single binary that covers host discovery through weak-credential checks across a /24 or wider. Do not adopt it if you need passive discovery, if you cannot tolerate a tool that attempts logins by default, or if your engagement rules forbid exploitation modules. Before the first real run, verify that -nobr is set where brute force is out of scope, confirm the target list with -ehf exclusions, and decide whether the default 133-port set is enough or whether you need -p to widen it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. shadow1ng/fscan on GitHub