Skip to main content
The Caesars

Brutus: Modern Credential Attack Testing

Brutus is a credential testing capability in the Praetorian Guard Platform supporting 43+ protocols, a cumulative credential corpus for cross-service reuse testing, account enumeration with named results, and seamless pipeline integration.

Brutus introduction card

Brutus is a credential testing capability within the Praetorian Guard Platform. Written in Go and compiled to a single binary with no external dependencies, it runs on Linux, macOS, Windows, and FreeBSD and emits structured JSON output natively. Brutus is a manually initiated capability. To ensure it is deployed at the right time and against the right systems, coordinate with your Praetorian Guard team to scope and authorize credential testing as part of your engagement workflow.

Seamless Pipeline Integration

Brutus accepts JSON input from upstream tools, making it straightforward to wire into a reconnaissance pipeline:

naabu -host 10.0.0.0/16 -silent | nerva --json | brutus creds --nerva --json

Port scan, service identification, and credential testing flow in a single pipeline. Structured JSON results are emitted at the end, ready for reporting, databases, or further tooling without additional parsing scripts. Brutus also integrates directly with Nerva as a library via --fingerprint, automating service fingerprinting without an external binary.

43 Protocols and Counting

Brutus ships with support for SSH (passwords and private keys), MySQL, PostgreSQL, MSSQL, Redis, MongoDB, SMB, LDAP, WinRM, SNMP, FTP, Telnet, VNC, HTTP/HTTPS Basic Auth, RDP, Oracle Database, TURN, Kafka, AMQP, MQTT, NATS, ZooKeeper, Firebird, XMPP, rsync, SIP, ActiveMQ, DB2, OPC UA, IPMI, Memcached, SOCKS5, and more. Each protocol is implemented as a self-contained plugin, so the architecture is built to grow with the community.

A PostgreSQL password may contain spaces and characters such as @ and '. An IPv6 host is accepted.

Subcommands

Brutus organizes functionality into focused subcommands:

  • brutus creds — Non-HTTP credential auditing (SSH, databases, SMB, and other non-web protocols).
  • brutus web — HTTP and web panel auditing (Basic Auth, form-based login, AI-powered discovery).
  • brutus logon — Windows logon-screen backdoor detection (combined sticky-keys and utilman scan).
  • brutus stickykeys — Sticky-keys–only backdoor detection.
  • brutus utilman — Utilman-only backdoor detection.
  • brutus snmp — SNMP community string testing with tiered wordlists.
  • brutus badkeys — Embedded compromised SSH key testing.
  • brutus enum — Account enumeration and OSINT collection (see below).

Credential Corpus and Cross-Service Reuse Testing

Brutus maintains a cumulative per-tenant credential corpus. When a credential pair is confirmed valid against any service, it is automatically tested against other in-scope services in subsequent runs. This exploits password reuse across a customer's environment without requiring manual intervention.

  • Confirmed credentials from past Brutus engagements are stored and fed back into subsequent brute-force runs as priority candidates.
  • A credential confirmed on one service is automatically tried against all other in-scope services for the same tenant.

As more engagements run, the corpus grows, increasing coverage and the likelihood of surfacing reused credentials across different protocols and hosts.

Unauthenticated Access Detection

Brutus detects services that permit access without any credentials — a distinct finding from weak credentials. For PostgreSQL, Redis, and Elasticsearch, a pre-check unauthenticated probe runs before credential testing begins. Docker and Kubernetes are checked for unauthenticated API exposure as standalone checks. These findings surface as Security Findings in human output and as "finding": "unauthenticated_access" lines in JSONL output.

When Nerva fingerprinting detects anonymous access, Brutus records the finding directly from the fingerprint signal rather than repeating the probe.

In Guard, unauthenticated access produces a dedicated {protocol}-no-auth finding, distinct from weak credentials, so the two conditions are handled separately in triage.

TLS Support

Brutus supports configurable TLS modes across database and directory plugins. The following table shows how Brutus TLS modes map to each plugin's underlying connection parameter.

TLS mode

PostgreSQL

MySQL

MSSQL

LDAP

Neo4j

verify

Full certificate verification with SNI

✓

✓

✓

✓

skip-verify

TLS required, certificate not verified

✓

✓

✓

✓

disable (default)

No TLS

✓

✓

✓

✓

Pass --verify when invoking Brutus to enable full certificate verification:

brutus creds --verify --json

SMTP applies TLS opportunistically: when the server advertises STARTTLS, Brutus negotiates it automatically. Under --verify, if STARTTLS is not available, the plugin returns a connection error rather than authenticating over cleartext.

Account Enumeration

Brutus includes an enum subcommand tree for account enumeration and OSINT collection:

Active enumeration

  • brutus enum active github — Checks whether email addresses are registered GitHub accounts using GitHub's signup flow. Supports username reveal via authenticated PAT (creates a temporary private repo, resolves email → login, then deletes it). The --rotating-proxy flag shortens retry backoff when proxies rotate exit IPs per request.
  • brutus enum active google — Identifies Google Workspace and Gmail accounts via AccountChooser and GXLU signals; no token required.
  • brutus enum active teams — Enumerates Microsoft Teams corporate accounts and surfaces tenant posture (cross-tenant chat policy, presence leakage, out-of-office exposure). Requires a device-code OAuth token obtained via brutus enum active teams auth.
  • brutus enum active microsoft365 — Checks account existence via the Microsoft 365 GetCredentialType endpoint; detects federated tenants to avoid false positives.
  • brutus enum active gravatar — Checks email registration against Gravatar's avatar hash endpoint; no token required.
  • brutus enum active oracles — Validates which oracles (Google, Microsoft 365, Teams, GitHub) confirm a known-valid address, then enumerates via every working oracle.
  • brutus enum active kerberos — Active Directory user enumeration via Kerberos AS-REQ.
  • brutus enum active custom — Declarative oracle enumeration driven by a YAML spec describing request shape and response matching rules.

Passive enumeration

API-key OSINT sources grouped under brutus enum passive:

  • brutus enum passive hunter — Hunter.io domain email search.
  • brutus enum passive apollo — Apollo.io people discovery and selective email enrichment.
  • brutus enum passive lusha — Lusha v3 single-contact enrichment and domain roster enumeration.
  • brutus enum passive dehashed — DeHashed v2 breach-data collection including plaintext passwords (where present), corporate-only filtering, and source-database selection.

Named enumeration results

When Brutus generates usernames from a frequency-ranked wordlist, it retains the first and last name that produced each candidate and carries it through the enumeration pipeline. Every result carries First and Last fields populated at generation time. The name reported reflects only what the username format proves: first.last formats carry both names exactly; initial-based formats (flast, f.last) carry the first initial and full last name. This avoids asserting a given name that the local part does not establish.

Username generation

brutus enum generate produces frequency-ranked username and email candidates from a prebuilt list of statistically likely name pairs. Formats include first.last, flast, f.last, lastfirst, firstl, first_last, and others. Use --limit to cap output; since the list is ranked, --limit N yields the N most-likely names.

Embedded Bad Keys

Brutus compiles known-compromised SSH key collections directly into the binary — keys from Rapid7's ssh-badkeys repository, HashiCorp Vagrant, F5 BIG-IP, ExaGrid, Ceragon FibeAir, Monroe DASDEC (CVE-2013-0137), and others. When brutus badkeys runs against an SSH service, it tests every embedded bad key. Each key carries its CVE metadata through to the output for compliance reporting.

Spraying a Recovered Key Across a Network

A private key recovered from a compromised host can be tested across a network range in a single invocation. Brutus produces a complete map of every host where that key grants access, across network segments, with clean JSON output.

Options

  • --threads — Controls worker concurrency. Values of zero or negative are clamped to the configured default.
  • --verify — Enables full TLS certificate verification. Defaults to disabled.
  • --mode — Sets the aggressiveness tier: cautious, default, or aggressive. Controls thread count, timeout, rate limiting, jitter, and wordlist depth. Defaults to default.
  • --proxy — Routes all TCP and HTTP connections through a SOCKS5, HTTP, or HTTPS proxy. Accepts socks5://, socks5h://, http://, and https:// schemes; a bare host:port defaults to HTTP. Use --proxy-user user:pass to supply credentials.
  • --retries — Number of retry attempts per credential on connection error, with exponential backoff.
  • --rate-limit — Maximum attempts per second. Accepts fractional values (e.g., 0.5 for one request every two seconds).
  • --targets-file — File of host:port targets, one per line; requires --protocol. Mutually exclusive with --target.
  • --nmap-file — Nmap XML output file (-oX) for target import.
  • --masscan-file — Masscan JSON output file (-oJ) for target import.
  • --fingerprint — File of host:port targets; Brutus fingerprints each with Nerva before credential testing.
  • -c / --credentials — Pre-paired user:pass credential(s) to test as-is, without Cartesian expansion.
  • -C / --credentials-file — File of user:pass credential pairs.

Experimental: AI-Powered Credential Discovery

Brutus ships with experimental AI features for unknown HTTP admin panels. The first feature sends HTTP response data to an LLM that identifies the application (Grafana, Jenkins, Tomcat, Cisco management interfaces, and others) and suggests vendor-specific default credentials. The second feature uses headless Chrome combined with Claude's vision API to navigate JavaScript-rendered login pages, identify the appliance from a screenshot, research default credentials, and fill in the form automatically.

Enable these features with --experimental-ai. They require an ANTHROPIC_API_KEY environment variable and depend on external API services.

RDP Logon-Screen Backdoor Detection

Credential testing does not catch accessibility-tool backdoors at the Windows RDP logon screen. A sticky-keys (sethc.exe) or Utilman replacement persists after password rotation and is reachable by any unauthenticated user with network access to the RDP port.

Guard's logon-backdoor check runs pre-authentication against in-scope RDP ports (default TCP 3389). The Brutus agent dispatches it independently of credential testing.

How detection works

Brutus connects to the RDP port without credentials and establishes a pre-auth graphical session. It performs an NLA negotiation probe first; hosts that require NLA are classified nla_required immediately, without running the full session. For reachable non-NLA hosts, it captures a baseline frame of the logon screen, sends the trigger keystroke sequence, and captures the response frame. A dark-pixel delta analysis — comparing dark pixel count and region geometry between frames — determines whether a console-sized window appeared.

A process-wide admission control semaphore limits the number of concurrent WASM decode sessions to approximately 1.5× the host's CPU core count, so scan threads scale independently of per-host memory cost.

Verdicts and severity

Verdict

Meaning

Guard severity

backdoor_confirmed

Behavioral or Vision API evidence of a shell

Critical

backdoor_likely

Dark-pixel heuristic indicates a console-shaped region

High

no_backdoor / clean

No evidence of a backdoor

Not filed

indeterminate

Frame did not stabilize; retry recommended

Not filed

nla_required

Pre-auth screen unreachable without credentials

Not filed

unreachable

TCP connect failed

Not filed

A finding is filed only when backdoor_confirmed or backdoor_likely is reached for at least one check. The CVSS 4.0 score is 9.3 (CWE-912, ATT&CK T1546.008) in both cases; the severity label reflects the evidence basis.

The detection proof includes baseline and response frame screenshots, per-check verdicts, confidence scores, and diagnostics. These appear in the Guard evidence tab alongside the structured finding.

Indeterminate results

A scan is retried once automatically with a more patient settle profile when the response frame did not stabilize within the deadline. Use --scan-timeout (the logon-family timeout, distinct from --connect-timeout for the TCP dial) to control the per-host budget. The --fast flag enables a shorter settle profile for internet-scale surveys; fast mode reports only positives and indeterminate results, never clean.

Interactive modes

When running Brutus directly, brutus logon --exec "whoami" triggers the backdoor and captures command output. brutus logon --web starts a browser-based RDP viewer with live screen streaming and keyboard forwarding. These modes are not used by the automated Guard capability.

When a finding is raised

Verify the substitution, restore known-good binaries, treat the host as previously compromised, and audit other RDP-exposed hosts.

Why "Brutus"?

If you know Praetorian's tooling, you'll notice we tend to name projects after Roman emperors — Trajan, Augustus, and the like. Brutus breaks that tradition because Marcus Junius Brutus was never an emperor. He's remembered for walking into the Roman Senate on the Ides of March and putting a dagger in the back of the most powerful man in the world. That felt more appropriate for a credential testing tool than any emperor's name ever could. Brutus doesn't build empires — it tests whether the ones you've built will let a stranger walk right through the front door.

Get Started

Brutus is open source. The full source is available on GitHub — inspect it, extend it, contribute to it. To get Brutus running as part of your Praetorian Guard deployment, reach out to your Praetorian Guard team to coordinate activation and scoping.

go install github.com/praetorian-inc/brutus/cmd/brutus@latest