legion is a Python-based enumeration orchestrator that chains well-known open-source tools to extract maximum information from every open network service during authorized penetration tests.
| Tool | carlospolop/legion — automatic, semi-automatic and manual enumeration tool built on open-source tools |
| Category | Network service enumeration / scanner orchestration (Python) |
| Primary Use | Automating repetitive enumeration of common network services via nmap, hydra, msf and other tools during authorized assessments |
| Safe Use | For penetration testers with written authorization, lab environments, and CTF exercises; also useful to defenders modeling what noisy enumeration looks like |
| Telemetry Note | Legion generates heavy scan and brute-force traffic; defenders will see high-volume nmap probes, repeated hydra authentication failures, and new directories under $HOME/.legion on the operator host |
legion, hosted at carlospolop/legion and written in Python under the MIT license, is an enumeration orchestrator rather than a scanner in its own right. Its author positions it explicitly against the pentesting methodology documented at book.hacktricks.xyz, and the tool's core design goal is stated plainly in the README: extract all the information you can from each open network service so you don't have to retype the same commands every time you encounter that service. With just over a thousand stars, it sits in the sweet spot of a community tool that is widely known among HackTricks readers but not so mainstream that its output signature is universally recognized.
Architecturally, legion is a wrapper and scheduler around established open-source tools — the repository topics name nmap, nmap-scripts, hydra, and msf as its building blocks. The README is candid about redundancy: some actions are deliberately repeated by more than one tool to make sure all possible information is correctly extracted. That design choice tells you the tool optimizes for coverage over stealth or efficiency, which matters both for operators planning engagement windows and for defenders interpreting what this traffic looks like on the wire.
The operational model is a three-tier interaction pattern: automatic, semi-automatic, and manual. The automatic path is a single internal command, startGeneral, which kicks off the General workflow that scans ports and services without further input. Semi-automatic operation uses the run command after the operator sets options appropriately for a specific service, and the manual tier exposes exec <name> to fire a single module — the README gives exec http_slqmap as an example, itself a small typo that hints at the tool's hobbyist provenance. Some services also have on-demand commands that are reachable only through exec, which encourages operators to explore per-protocol module lists.
Option handling is where legion shows its methodology roots. The set interface covers host (IP or domain), proto (e.g., set proto http), port — with 0 meaning the service's default port, discoverable via info — plus domain, path for web server file paths, and extensions, a comma-separated list used to brute force file names on a web server. Credential-oriented options include username, password, ulist, and plist for user and password lists, with legion shipping its own defaults for both. There's also ipv6 for targets where certain commands need the v6 address specifically.
The intensity option is the tool's throttle. Level 1 runs basic checks, level 2 — the default — runs all checks, and level 3 additionally enables brute force, where the tool checks both that a service can be brute forced and which command line will be used. The brute-force backend selection is pragmatic and documented: hydra is preferred, and where hydra is not installed, metasploit or nmap modules are used instead. This fallback chain is worth remembering when you're triaging dependencies in a container build.
Two options shape noise and repeatability. notuse takes a comma-separated list of commands to exclude — the README's example is set notuse msf if you don't want Metasploit modules executed, useful for engagements where framework console telemetry is undesirable. reexec defaults to False but can be set to True to re-run already-executed commands, which matters because legion appears to track command state to avoid duplicate runs. verbose controls whether command output is printed as soon as a command finishes, and it also changes what info displays: with verbose on you see where each parameter is used, and with it off you see parameter values — a genuinely useful debugging distinction.
Output management is simple and predictable: the workdir option points at the directory where victim data is stored, defaulting to $HOME/.legion. That single directory-of-record is convenient for reporting and for cleaning up after an engagement, but it also means every result from every target lands in one tree unless you change it — an operational hygiene detail worth noting for anyone running multiple concurrent clients.
Installation is offered three ways. The classic route is a git clone https://github.com/carlospolop/legion.git /opt/legion followed by ./install.sh inside the git directory and a symlink of legion.py into /usr/bin/legion. The README also provides a docker build -t legion . path with docker run -it legion bash, and a prebuilt docker pull carlospolop/legion:latest image for those who prefer not to assemble dependencies themselves. One caveat is called out explicitly: pentesting Oracle services requires manually installing additional dependencies, with instructions living in the HackTricks book rather than the repo.
The protocol surface is described as covering the most frequently found services you'd encounter on pentest targets, and the internal protos command lists what's supported at runtime. Because the exact protocol matrix lives in the code rather than the README, prospective users should run protos after installation to confirm coverage for their target profile — the help internal command is the entry point for discovering what every internal command does, and the README's internal-commands screenshot suggests a compact command shell rather than a menu-driven GUI.
From a defensive perspective, legion is a useful reference for what automated enumeration looks like. Its philosophy of deliberate tool overlap means defenders observing its use will see the same service probed by multiple engines in sequence — nmap script scans, framework auxiliary modules, and hydra bursts — all within a short window. High rates of authentication failure across a single service, followed by service-specific version probing, are the classic fingerprint of this class of orchestrator, and blue teams can use that overlap pattern as a detection heuristic.
The main limitations are worth stating honestly. The README is feature-descriptive but silent on maintenance cadence, and the tool's value depends heavily on the freshness of the underlying tools it drives — a stale wrapper around current nmap and hydra remains useful, but module names drift over time. There's no mention of threading controls, timing evasion, or output formats beyond the workdir structure, so this is unambiguously an authorized-engagement and lab tool, not a stealth instrument. Within that scope — repetitive enumeration of common services on targets you're contracted to test — it does exactly what it advertises, and it wraps the HackTricks methodology in a form you can actually execute.
carlospolop/legion.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.