Hydra Integration with DefectDojo

Hydra Integration with DefectDojo

THC Hydra is an open source network login testing tool maintained on GitHub by van Hauser of The Hacker's Choice (THC). Security teams use it during authorized assessments to check whether services such as SSH, RDP, FTP, databases, and web login forms accept weak or default credentials. Hydra can write its results as text or JSON, and DefectDojo imports the JSON format, recording each confirmed credential pair as a finding against the host and port where it worked.

Hydra Integration with DefectDojo

We run Hydra in scoped internal assessments because default and guessable passwords are still one of the most common ways into a network, and the only reliable way to know is to test. The hard part comes after the test. A weak credential on a forgotten management interface has to reach the team that owns it, get rotated, and be verified. Importing Hydra's JSON output into DefectDojo turns each hit into a High severity Finding on the right Asset, with an owner, an SLA clock, and a record that it was closed.

Why Hydra Matters

Credential weaknesses don't show up in code scanning or dependency analysis. They live in deployed configuration, often on infrastructure nobody has looked at in years.

• Hydra supports a long list of protocols, so one tool covers SSH, remote desktop, mail, database, and HTTP form logins.
• Each result is a confirmed, working login, not a theoretical exposure, which makes it high signal.
• Default vendor credentials on appliances, printers, and admin consoles are a recurring finding in assessments, and Hydra is a direct way to check for them.
• A result in a terminal or a text file is easy to lose. Tracking rotation across dozens of hosts needs a system that remembers what was found and what was fixed.

Advantages of This Integration

What we got from routing Hydra results through DefectDojo:

• Endpoint-level findings. Each result is attached to the host and port that accepted the login, so findings can be grouped and reported by system.
• Consistent severity. Hydra has no severity concept, so the parser rates every finding High. Weak credentials then fall under the same High SLA as every other High finding on the Asset.
• Service-aware deduplication. DefectDojo hashes Hydra findings on title and description, and the hash always includes the service field, which the parser sets from the Hydra service under test.
• Retest closure. Reimporting a retest into the same Test mitigates credentials that no longer work and reactivates any that come back.
• Ownership and ticketing. Findings can be assigned to the system owner, pushed to Jira, and closed with a note recording the rotation.

How This Integration Works

DefectDojo imports Hydra output with the Hydra Scan scan type. Only run Hydra against systems you are authorized to test.

1. Write results as JSON. When running an authorized Hydra test, add the output options to your existing invocation so results are written to a JSON file:

-o hydra-results.json -b json

In current Hydra source, json and jsonv1 select the same format. The file contains a generator block (Hydra version, run timestamp, server, and service) and a results array, and DefectDojo rejects files that lack either key.

2. Import it. In the UI, open the Engagement for the assessment, choose Import Scan Results, select Hydra Scan, and upload the file. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Hydra Scan" \
  -F "file=@hydra-results.json" \
  -F "product_name=internal-network" \
  -F "engagement_name=Q4 Credential Review" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Hydra Scan" \
  --report-path "./hydra-results.json" \
  --product-name "internal-network" \
  --engagement-name "Q4 Credential Review" \
  --auto-create-context

3. Reimport after remediation. Once owners rotate credentials, rerun the same scoped test and reimport into the same Test so fixed hosts are mitigated.

Data Granularity: What Gets Imported

Results missing a host, port, login, or password are skipped with a warning rather than imported as partial findings. Hydra's errormessages and commandline values are not imported.

Use Cases

During an internal assessment: The assessment team imports Hydra results into an Engagement scoped to the test window, assigns each finding to the owner of the affected system, and tracks rotation through to closure instead of handing over a spreadsheet.

When auditing default credentials: A platform team checking network appliances and admin consoles after a hardware refresh imports the results so each device with a vendor default password becomes an assigned, SLA-tracked finding.

For retest evidence: After owners report that credentials were changed, a rerun and reimport into the same Test mitigates the fixed findings and leaves a dated record, which is the evidence auditors usually ask for.

Alongside network scanning: With Hydra findings and network scanner findings on the same Asset, reporting shows which exposed services also accepted weak logins.

Operational Tips

• Treat the imported data as sensitive. The finding description contains the working password in plain text, so limit who can view the Asset, and make credential rotation the first remediation step.
• Because the password is part of the description, and the description is part of the hash, the same host with a different weak password will create a separate finding. Review these together when closing out a host.
• Adjust severity per finding when context warrants it. The parser cannot tell an internet-facing admin login from a lab system, so everything arrives as High.
• Use one Engagement per assessment and record the authorized scope in its description.
• Tag findings with the protocol or environment (for example tags=ssh,datacenter-a) so results can be filtered by service type in metrics.
• Check the errormessages array in the file before you reimport. A run that could not reach its targets still produces a valid file with an empty results array, and reimporting it would mitigate every open finding in that Test.