Skip to content

Plugin Catalog

This catalog documents the concrete plugin wrappers in backend/internal/plugins/wrappers/. It is the authoritative reference for how bundled plugins are invoked, what inputs they accept, what normalized output they produce, and how they contribute to the EASM asset graph.

Architecture Overview

Plugins implement the backend plugins.Plugin interface. A scan profile from backend/configs/config.yaml selects a sequence of plugin IDs, the worker builds a PluginInput from the organization scope plus previously discovered assets, and each wrapper returns a PluginResult containing normalized entities, raw command output, raw command error, and optional artifacts.

At scan execution time, the worker expands approved ip_range Scope values in IPv4 START_IP-END_IP form into individual ip scope items before wrappers run. Wrappers that already accept ip automatically receive those targets and do not need to parse ip_range syntax. CIDR scope items are not expanded by this mechanism.

The worker persists normalized assets and vulnerabilities, stores plugin artifacts through the files subsystem, and then creates graph edges from asset type plus metadata. Most wrappers do not create edges directly; they emit normalized entities with metadata that the worker uses later.

Plugin Lifecycle

  1. A scan job selects plugins from its config-defined scan profile.
  2. The worker loads each plugin configuration from the default registry.
  3. The worker normalizes scan targets, including runtime-only ip_range expansion into individual ip scope items.
  4. The wrapper filters scope items to the input types it supports.
  5. If no matching input exists, the plugin returns a skipped or empty successful result.
  6. The wrapper executes its CLI command unless test mode is enabled.
  7. The wrapper parses stdout into normalized assets, vulnerabilities, or artifacts.
  8. The worker persists results and derives graph relationships.

Categories

  • Recon: discovers domains, subdomains, CIDRs, or passive service candidates.
  • Resolution: resolves hostnames to IP assets.
  • Port Discovery: discovers open services and service metadata.
  • Service Discovery: probes reachable HTTP services and URLs.
  • Web Discovery: crawls URLs and discovers paths.
  • TLS Discovery: collects certificate assets and TLS metadata.
  • Content Discovery: collects screenshots or file artifacts.
  • Vulnerability Discovery: records vulnerability findings.
  • Experimental: disabled by default or requiring additional operational configuration.

Execution Order Examples

Common graph-building chain:

domain
  -> subfinder/amass
subdomain
  -> dnsx/resolver
ip
  -> naabu/nmap
service
  -> httpx
webapp
  -> katana/nuclei/httpx_screenshot

Expanded recon chain:

domain -> subfinder -> amass -> dnsx -> httpx -> tlsx

Web discovery chain:

domain -> subfinder -> dnsx -> httpx -> katana -> nuclei

Screenshot chain:

domain -> subfinder -> dnsx -> httpx -> httpx_screenshot

Research Assets

hxresearch/ is the project knowledge repository for proprietary detections, advisories, writeups, proof-of-concepts, datasets, and expert templates. Worker containers mount it read-only at /opt/hxeasm/hxresearch.

Current runtime integration:

  • nuclei_custom_templates uses templates from hxresearch/nuclei only.
  • It is registered but not included in any built-in scan profile.
  • It does not run the default ProjectDiscovery template set.

Future integration points may include:

  • nuclei_hybrid combining ProjectDiscovery templates with hxresearch/nuclei
  • future advisory engines reading hxresearch/advisories
  • future AI agents using hxresearch as curated context
  • plugins using hxresearch/datasets for detection support data

See ../hxresearch.md.

Manual Plugin Execution

Manual execution is backend-driven. The plugin registry is the single source of truth through two metadata fields on PluginConfig:

  • SupportedAssetTypes: asset types the plugin can accept for manual runs.
  • SupportedExecutionModes: execution modes such as profile_scan, manual_scan, and retry.

GET /api/v1/plugins/manual-capabilities returns enabled plugins that support manual_scan. The frontend builds the Run Plugin menu from that response and filters by supported_asset_types; it does not contain a hardcoded plugin list.

Manual-capable bundled plugins:

Plugin Manual asset types Reason
subfinder domain Focused subdomain discovery from one root domain
amass domain Deeper subdomain discovery from one root domain
resolver domain, subdomain Resolve one hostname target
dnsx domain, subdomain, ip Resolve/probe one hostname target or PTR-probe one IP target with dnsx
httpx domain, subdomain, ip, service Probe one web-capable host or service
httpx_screenshot webapp Capture evidence for one WebApp origin
naabu ip, cidr, domain, subdomain Discover ports for one network target
nmap ip, cidr, domain, subdomain Validate services for one network target
nmap_vulns service, ip, domain, subdomain Run NSE vulnerability checks against known services
tlsx service, domain, subdomain, ip, webapp Inspect TLS for one endpoint
katana webapp Crawl one WebApp origin
nuclei webapp, service, domain, subdomain, ip Run standard Nuclei checks against one target
nuclei_custom_templates webapp, service, domain, subdomain, ip Run hxresearch templates against one target
nuclei_test webapp, service, domain, subdomain, ip Test safe plugin options and custom headers

Disabled experimental plugins are not returned by the capabilities API. Manual runs create normal scans with the internal manual_scan profile and one scan job.

Service assets are normalized to host:port before manual execution. For example, stored service value 1.2.3.4:443/tcp is passed to plugins as 1.2.3.4:443.

Bundled Plugins

Template