scilla bundles DNS, subdomain, port and directory enumeration into one recon CLI

Four enumeration modes behind one command name

scilla describes itself as an information gathering tool covering DNS, subdomains, ports and directories enumeration, and the README's example list confirms the structure. There are four subcommands, each taking a target:

- dns, for DNS records - subdomain, for subdomains - dir, for directories - port, for open ports

And a fifth, report, which combines them. That is the design decision worth naming. Most reconnaissance workflows run several specialised tools in sequence and then reconcile their output by hand. scilla's premise is that the same target, the same output flags and the same wordlist options should work across all four task types, so the report command is not a report generator bolted on afterwards but the natural end of the workflow.

The subcommands share a common vocabulary of flags, and the README's examples show how consistent that is. Output is selected with -oj for json, -oh for html and -ot for txt, and -plain prints only the results. Wordlists are attached with -w, as in scilla subdomain -w wordlist.txt -target example.com, and the same flag appears for the dir subcommand. Ignored status codes use -id for directories and -is for subdomains, with a comma list for specific codes and a class pattern for groups.

The tool is written in Go, and the module path is github.com/edoardottt/scilla. The go.mod requires Go 1.26.0, while the README's source build instructions ask for Go 1.23 or newer, a small inconsistency worth knowing about if your toolchain is pinned.

Subdomain enumeration draws on wordlists, crawlers and public databases

The subdomain subcommand is the widest of the four, and the flag list shows the range of sources it can combine.

A wordlist can be supplied with -w. The tool can also crawl, with -c, and it can consult a public database with -db, where -no-check skips the liveness verification step and -bw selects a specific source that the README does not name. VirusTotal is one of the named public sources, with -db -vt, and -alive filters the results to those that respond.

The remaining flags control the network and the identity of the requester. A custom User Agent is set with -ua "CustomUA" and -rua generates a random user agent for each request. The resolver can be pointed elsewhere with -dns 8.8.8.8. The dir subcommand carries the same -i, -c, -plain, -ua, -rua and -nr flags, so the two task types really are two views of the same engine.

The reason a single tool can offer both a wordlist and a public database is that the sources need credentials, and that is what the keys file is for. The README says to edit the ~/.config/scilla/keys.yaml file if you want to use API keys, and on Windows to create a keys.yaml file. The dependency on gopkg.in/yaml.v3 is there for that file.

The crawl side comes from gocolly, with goquery for HTML selection and the antchfx xpath and htmlquery packages beneath it, along with robotstxt handling.

Port enumeration takes ranges, classes and a common list

The port subcommand is the simplest of the four, and its flag handling is where the range syntax lives.

By default it scans all ports, described in the README as 1-65635. A range is given with -p 20-90. An open ended range is -p 20- for everything from 20 to the last one, and -p -90 for everything from the first to 90. Several specific ports are comma separated, as in -p 21,25,80, and a single port is -p 80. There is also a -common switch for a list of common ports, which is the flag most people reach for first when they want a quick answer rather than a full sweep.

The output flags are the same three as everywhere else, -oj, -oh and -ot, plus -plain. The report subcommand takes the same port options, which is what allows the combined report to scan the range you care about rather than always doing the full sweep.

The scanning itself is not built on an external port scanner. The direct dependency list is short: goquery for HTML parsing, go-domain-util for domain handling, fatih/color for terminal output, yaml.v3 for configuration and testify for tests, with the gocolly crawler and the bit set library as the more substantial indirect pieces. There is no nmap binding and no separate scanner binary to install, which keeps the tool self contained.

One dependency deserves a note. The bit set package, bits-and-blooms/bitset, is exactly what a tool that tracks which ports it has already tried needs, and it is a hint about how the scan bookkeeping is done internally.

The report command is where the four outputs meet

The report subcommand is the one that justifies the name of the tool, and its options show what it is merging.

It runs the port scan with the same -p, -common and output flags, then adds wordlists for the two web-facing tasks: -wd for a directories wordlist and -ws for a subdomains wordlist. Status codes to ignore are given separately for the two halves, -id for directories and -is for subdomains, and both accept specific codes like 500,501,502 and class patterns that match the 5xx and 4xx groups.

The crawling and database sources are switched on per task as well, with -cd to add a web crawler for directories enumeration and -cs to add one for subdomains, and -db to add a public database for subdomains. The VirusTotal source is available in report mode too, as -db -vt. The remaining options are the common ones: -nr for no follow redirects, -ua for a custom user agent and -rua for a random one per request.

The distinction between -id and -is is the interesting design point. In a combined run, the two halves are different kinds of surface. A directory scan hits the web server and gets a status code, so a 500 on one path does not mean the subdomains are broken, and a 502 on one host does not mean the directories are missing. Treating them as one ignore list would quietly hide real findings, so the tool keeps them apart.

The output formats carry over unchanged, so a report can be written as json for machine consumption, html for reading or txt for piping into something else. The html option across every subcommand suggests a shared rendering path rather than a separate report writer.

Four install routes and a config file you may never need to touch

Installation covers the usual platforms, and one of the routes is a single command with no system changes.

Homebrew:

brew install scilla

Snap, which the README shows with sudo:

sudo snap install scilla

Go, for anyone who already has the toolchain:

go install -v github.com/edoardottt/scilla/cmd/scilla@latest

And Docker, which is the cleanest option if you do not want to install anything on the host:

docker build -t scilla .
docker run scilla help

The Dockerfile is short. It starts from golang:1.25, sets the working directory to the GOPATH path for the project, copies the source, downloads the golang.org/x/sys module and installs the packages, with the entrypoint set to scilla. Because the working directory is a GOPATH layout rather than a module path, the image is built by copying the tree into that location, which is a slightly older idiom than a plain module build.

Building from source is documented separately for Linux and Windows. On Linux it is a clone, go get ./... and make linux, with make unlinux to uninstall, and the README also gives the one-liner version of the same thing. On Windows it is a clone followed by .\make.bat windows, with the caveat that the executable works only in the cariddi folder, which is a known issue the README links.

The Makefile installs the binary to /usr/local/bin/scilla and then runs scripts/config.sh, which is what creates the config directory. The uninstall target removes the binary and the whole ~/.config/scilla directory, so any API keys you have put there go with it.

Where scilla does not reach

The scope boundary is easy to state. scilla enumerates: it resolves names, finds subdomains, finds open ports and finds directories. It does not scan for vulnerabilities, it does not exploit, and it does not tell you whether the services it finds are misconfigured. If your goal is to know what a target exposes, it is on target. If your goal is to know what is wrong with it, you need a different tool.

The second limit is source dependency. Several of the subdomain sources are third party services, reached with credentials you supply in keys.yaml, and those services have their own rate limits, their own coverage and their own terms. The public database and VirusTotal paths will find different things from your wordlist, and neither is exhaustive. The tool gives you the sources, not the coverage, and the README does not describe which source is authoritative for what.

The third limit is the Windows path. The README states plainly that the executable works only in the cariddi folder and links the issue explaining it, so a Windows user is relying on a documented workaround rather than a supported build. The Linux, Homebrew, Snap and Docker paths are the ones to rely on.

The fourth is that enumeration is a noisy activity. The port subcommand defaults to a full sweep of the range the README calls 1-65635, and the subdomain subcommand can hit both a wordlist and a database at once. Pointed at a host you are not authorised to test, that traffic is a problem for you and for the operator of the target, and the tool is not going to ask whether you have permission.

Licence, releases and the project layout

scilla is licensed under GPL-3.0, with the licence file at the top of the repository and the LICENSE reference in the README navigation. The project is released on a regular cadence: v1.3.2 on 2025-11-19, v1.3.3 on 2026-03-22 and v1.3.4 on 2026-09-09, with the last push on 2026-10-02 and the repository not archived.

The repository layout is conventional Go: cmd/ holds the command entry point, pkg/ holds the reusable packages, internal/ holds the private ones, and scripts/ holds the shell helpers the Makefile calls, including the config.sh that sets up the configuration directory. There is a Dockerfile, a Makefile, a make.bat for Windows, a snapcraft.yaml for the Snap build, and a .golangci.yml for the linter configuration, with a GitHub Actions workflow for Go.

The Makefile also carries a few targets worth knowing about. The update target runs the uninstall and reinstall path in one go, which is the supported way to move between versions when you installed from source. There is a dedicated linux-arm64 target that cross compiles with CGO_ENABLED=0 and produces scilla-arm64, and a windows target that produces scilla.exe the same way, so you can produce a binary for either platform without changing the host.

Tests run with the race detector, go test -race ./..., and the lint target calls golangci-lint run. The project lists itself among the security and information gathering tools and takes part in Hacktoberfest, according to the repository topics.

Editorial conclusion

scilla suits a security engineer who wants one binary for the reconnaissance stage, with the four common enumeration tasks sharing a single set of output flags and a single report command instead of four separate tools to wire together. It is the wrong tool if you need exploitation, vulnerability scanning or anything beyond enumeration, and the wrong tool if you are not authorised to probe the target. Before running it, decide which of the four subcommands you actually need and supply API keys in ~/.config/scilla/keys.yaml only for the sources you intend to use, since several sources are third party services with rate limits and terms of their own.

Frequently asked questions

Official sources

1. edoardottt/scilla on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases