Scan Engines

How to write your reNgine-ng Scan Engine YAML Configuration?

reNgine-ng provides the ability to customize scan engines via YAML based configuration. This configuration can be used to select the tools, choose the options provided by the tools etc.

[!TIP]
New to reconnaissance? Check out our comprehensive Tutorial Reconnaissance Guide that provides step-by-step workflows and best practices for different scanning scenarios.

[!CAUTION] reNgine-ng 2.0 has new scan engine configuration. Configurations from reNgine-ng < 2.0.0 will not work in >= 2.0.0

[!CAUTION] reNgine-ng 2.0 does not provide switches to enable or disable tasks. The YAML configuration decides which tasks to use. Any task: {} that is in YAML config will run, rest will not.

Currently YAML config is supported for

[!NOTE]

• Subdomain Discovery as subdomain_discovery
• HTTP Crawling as http_crawl
• Screenshot Gathering as screenshot
• OSINT as osint
• Port Scan as port_scan
• Directory and File Fuzzing as dir_file_fuzz
• Endpoint Gathering as fetch_url
• Vulnerability Scan as vulnerability_scan

Default YAML Config

[!NOTE]
The following configuration represents the baseline setup used in Initial Scan - reNgine recommended. For specific use cases, refer to our Tutorial Guide for optimized configurations.

# Global vars for all tools
#
# Custom header - FFUF, Nuclei, Dalfox, CRL Fuzz, HTTPx, Fetch URL (Hakrawler, Katana, Gospider)
custom_header: {
  'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0',
}
# 'user_agent': ''                    # Dalfox only
# 'timeout': 10                       # Subdomain discovery, Screenshot, Port scan, FFUF, Nuclei                       
# 'threads': 30                       # All tools
# 'rate_limit': 150                   # Port scan, FFUF, Nuclei
# 'intensity': 'normal'               # Screenshot (grab only the root endpoints of each subdomain), Nuclei (reduce number of endpoints to scan), OSINT (not implemented yet)
# 'retries': 1                        # Nuclei

subdomain_discovery: {
  'uses_tools': ['subfinder', 'ctfr', 'sublist3r', 'tlsx', 'oneforall', 'netlas'],  # amass-passive, amass-active, All
  'threads': 30,
  'timeout': 5,
  # 'use_subfinder_config': false,
  # 'use_amass_config': false,
  # 'amass_wordlist': 'deepmagic.com-prefixes-top50000'
}
http_crawl: {
  # 'custom_header': {
  #   'Cookie':'Test',
  #   'User-Agent': 'Mozilla/5.0'
  # },
  # 'threads': 30,
  # 'follow_redirect': false,
  # Precrawl configuration - controls which ports are tested during initial crawl
  # 'precrawl_ports': [80, 443, 8080, 8081, 8082, 8443, 3000, 3001, 5000, 9000],  # Common ports (always tested)
  # 'precrawl_uncommon_ports': false,  # Set to true to also test uncommon ports (81-55672)
  # 'precrawl_all_ports': false,       # Set to true to test all ports (common + uncommon), overrides precrawl_uncommon_ports
  # 'precrawl_batch_size': 350         # Batch size for processing URLs
}
port_scan: {
  'timeout': 5,
  # 'exclude_ports': [],
  # 'exclude_subdomains': [],
  'ports': ['top-100'],
  'rate_limit': 150,
  'threads': 30,
  'passive': false,
  # 'use_naabu_config': false,
  # 'enable_nmap': true,
  # 'nmap_cmd': '',
  # 'nmap_script': '',
  # 'nmap_script_args': ''
}
osint: {
  'discover': [
      'emails',
      'metainfo',
      'employees'
    ],
  'dorks': [
    'login_pages',
    'admin_panels',
    'dashboard_pages',
    'stackoverflow',
    'social_media',
    'project_management',
    'code_sharing',
    'config_files',
    'jenkins',
    'wordpress_files',
    'php_error',
    'exposed_documents',
    'db_files',
    'git_exposed'
  ],
  # 'custom_dorks': [],
  'intensity': 'normal',
  'documents_limit': 50
}
dir_file_fuzz: {
  # 'custom_header': {
  #   'Cookie':'Test',
  #   'User-Agent': 'Mozilla/5.0',
  #   'Custom-Header': 'My custom header'
  # },
  'auto_calibration': true,
  'rate_limit': 150,
  'extensions': [],
  # 'extensions': ['html', 'php','git','yaml','conf','cnf','config','gz','env','log','db','mysql','bak','asp','aspx','txt','conf','sql','json','yml','pdf'],
  'follow_redirect': false,
  'max_time': 0,
  'match_http_status': [200, 204, 403, 500],
  'recursive_level': 0,
  'stop_on_error': false,
  'timeout': 5,
  'threads': 10,
  'wordlist_name': 'default', # fuzz-Bo0oM
}
fetch_url: {
  # 'custom_header': {
  #   'Cookie':'Test',
  #   'User-Agent': 'Mozilla/5.0',
  #   'Custom-Header': 'My custom header'
  # },
  'uses_tools': ['gospider', 'hakrawler', 'waybackurls', 'katana', 'gau'],
  'remove_duplicate_endpoints': true,
  'duplicate_fields': ['content_length', 'page_title'],
  'gf_patterns': ['debug_logic', 'idor', 'interestingEXT', 'interestingparams', 'interestingsubs', 'lfi', 'rce', 'redirect', 'sqli', 'ssrf', 'ssti', 'xss'],
  'ignore_file_extensions': ['png', 'jpg', 'jpeg', 'gif', 'mp4', 'mpeg', 'mp3'],
  'threads': 30
}
vulnerability_scan: {
  # 'custom_header': {
  #   'Cookie':'Test',
  #   'User-Agent': 'Mozilla/5.0',
  #   'Custom-Header': 'My custom header'
  # },
  'run_nuclei': true,
  'run_dalfox': false,
  'run_crlfuzz': false,
  'run_s3scanner': false,
  'concurrency': 50,
  'intensity': 'normal',
  'rate_limit': 25,
  'retries': 1,
  'timeout': 5,
  'fetch_llm_report': false,
  'nuclei': {
    'use_nuclei_config': false,
    'severities': ['unknown', 'info', 'low', 'medium', 'high', 'critical'],
    # 'tags': [],                 # Nuclei tags (https://github.com/projectdiscovery/nuclei-templates)
    # 'templates': [],            # Nuclei templates (https://github.com/projectdiscovery/nuclei-templates)
    # 'custom_templates': []      # Nuclei custom templates uploaded in reNgine
  }
}
waf_detection: {
}
screenshot: {
  'intensity': 'normal',
  'timeout': 10,
  'threads': 40
}

[!TIP] While the above YAML config is good enough to run the scan against the targets, modifying the configurations may give better scan results.

[!CAUTION] Before you make any modifications to the YAML Configuration, please note that, wrong configuration may crash the scans.

It is advised that you learn about YAML before you make any modifications.

🆕 Default Scan Engines (v2.2.0)

reNgine-ng now includes pre-configured scan engines optimized for different use cases:

🎯 Initial Scan Engines

Engine Name	Use Case	Speed	Resources	Recommended For
Initial Scan - Passive with screenshots	Quick reconnaissance	⚡⚡⚡ Fast	🟢 Low	First-time scans, time-sensitive assessments
Initial Scan - reNgine recommended	Balanced approach	⚡⚡ Medium	🟡 Medium	Most penetration tests and bug bounty
Initial Scan - Passive (import subdomains)	Scoped assessment	⚡⚡⚡ Fastest	🟢 Minimal	When you have predefined subdomain lists
Scan - Active	Comprehensive analysis	🐌 Slow	🔴 High	Deep assessments with ample time

🎯 Subscan Engines

Engine Name	Purpose	When to Use
Subscan - Port scan	Port enumeration	After finding interesting subdomains
Subscan - File fuzzing	Directory/file discovery	On web applications
Subscan - Fetch URLs	Endpoint discovery	For API and hidden functionality
Subscan - Vulnerabilities	Security assessment	After comprehensive reconnaissance
Subscan - Screenshots	Visual confirmation	After port scans
Subscan - WAF Detection	Protection assessment	Before active testing

[!TIP]
These engines are automatically loaded on first startup and provide optimal configurations for different scenarios. You can customize them or create your own based on these templates.

Detailed guide on configuring Scan Engines

This document will discuss about the available options, possibilities and different configurations required for reNgine-ng Scan Engine YAML configuration.

subdomain_discovery

• uses_tools: (list) A list of subdomain discovery tools to use, such as 'subfinder', 'ctfr', 'sublist3r', etc. Available tools for subdomain_discovery are:
  • all (will use all default and custom subdomain enum tools)
  • subfinder
  • ctfr
  • sublist3r
  • tlsx
  • oneforall
  • netlas
  • amass-passive
  • amass-active
  • custom_tool: You can also install custom subdomain enum tool and use it here.

You can use one or more combination of these tools to improve the results.

• threads: (int) The number of threads or concurrent processes to use for subdomain discovery.
• timeout: (int) The maximum time, in seconds, to wait for subdomain discovery to complete.
• use_amass_config: (boolean) If set to true, reNgine-ng will use configuration file for amass. Find more about configuration files here.
• use_subfinder_config: (boolean) If set to true, reNgine-ng will use configuration file for subfinder. Find more about configuration files here.
• amass_wordlist: (str) Optional, Wordlist for amass-active which performs brute-force of subdomains using a the wordlists. Available Options for amass_wordlist are:
  • default
  • short_name_for_wordlist

Please follow the guide on uploading your own wordlist. You need to enter the wordlist short_name here.

[!TIP] "Default Wordlist" If default wordlist is choosed then Deepmagic top 50,000 prefix wordlist will be used.

[!CAUTION] reNgine-ng currently does not support multiple wordlists. This feature maybe available in future updates.

Using Custom Subdomain Enum Tool

[!TIP] reNgine-ng supports custom tools. Instruction on installing custom tool can be found here. You can use the name of the tool that was entered earlier.

If your subdomain gathering tool was names as Turbo, you can use as

`uses_tools: ['subfinder', 'turbo']`

http_crawl

HTTP crawling is now automatically handled by reNgine-ng with advanced port detection capabilities. The http_crawl section allows you to configure both the crawling behavior and which ports are tested during the initial discovery phase.

Basic Configuration

• threads: (int) Number of concurrent threads for HTTP crawling
• follow_redirect: (boolean) Whether to follow HTTP redirects during crawling
• custom_header: (dict) Custom HTTP headers to use during crawling

Advanced Port Detection (New in v2.2.0)

The precrawl functionality allows you to control which ports are tested during the initial HTTP discovery phase:

• precrawl_ports: (list) List of specific ports to always test during initial crawl

  • Default: [80, 443, 8080, 8081, 8082, 8443, 3000, 3001, 5000, 9000]
  • These common web ports are always tested regardless of other settings

• precrawl_uncommon_ports: (boolean) Enable testing of uncommon ports (81-55672)

  • Default: false
  • When enabled, tests a broader range of potentially interesting ports
  • Increases scan time but may discover services on non-standard ports

• precrawl_all_ports: (boolean) Enable testing of all ports (common + uncommon)

  • Default: false
  • When enabled, tests both common and uncommon port ranges
  • Overrides precrawl_uncommon_ports setting
  • Most comprehensive but slowest option

• precrawl_batch_size: (int) Number of URLs to process in each batch

  • Default: 350
  • Smaller batches = better error handling and more granular control
  • Larger batches = potentially faster but higher memory usage

Usage Examples

Conservative approach (common ports only):

http_crawl: {
  'threads': 20,
  'precrawl_ports': [80, 443, 8080, 8443],
  'precrawl_uncommon_ports': false,
  'precrawl_batch_size': 200
}

Balanced approach (common + some uncommon ports):

http_crawl: {
  'threads': 30,
  'precrawl_uncommon_ports': true,
  'precrawl_batch_size': 350
}

Comprehensive approach (all ports):

http_crawl: {
  'threads': 40,
  'precrawl_all_ports': true,
  'precrawl_batch_size': 500
}

[!TIP]
Use precrawl_uncommon_ports: true for bug bounty hunting to discover services on non-standard ports. Use precrawl_all_ports: true only when you have ample time and want maximum coverage.

[!WARNING]
Enabling precrawl_all_ports significantly increases scan time. Reserve this option for thorough assessments where time is not a constraint.

port_scan

Port scan is currently being performed using naabu, please refer naabu documentation as well.

• timeout: (int) The maximum time, in seconds, to wait for port scanning to complete.
• ports: (list) A list of ports to scan, such as 'top-100'. Available options are:
  • top-100
  • top-1000
  • full (will scan all 65k ports)
  • uncommon-web-ports (will scan uncommon web ports like 8080, 8443, 9000, etc.)
  • list of port numbers like [80, 443, 8080]
• rate_limit: (int) The rate limit for port scanning.
• threads: (int) The number of threads or concurrent processes to use for port scanning.
• passive: (boolean) A boolean indicating whether to use passive naabu port scan.
• exclude_ports: (list) Ports which you would like to exclude from the scan for example: [8081, 443]
• exclude_subdomains: (boolean) If set to true, port scanning will not be done on subdomains that are chosen to be ignored while starting scan.
• use_naabu_config: (boolean) If set to true, reNgine-ng will use configuration file for naabu. Find more about configuration files here.
• enable_nmap: (boolean) If set to true, nmap will be used for scanning vulnerabilities on discovered ports.
• nmap_cmd: (str) Custom Nmap Command
• nmap_script: (str) Nmap Script to use: this will be passed in to nmap's --script option.
• nmap_script_args: (str) Nmap Script Args to use: this will be passed in to nmap's --script-args option.

osint

Currently supported options for osint are:

• discover (list): A list of items to discover, for example ['emails', 'metainfo'], available options are:
  • emails
  • metainfo
  • employees
• intensity (int): The intensity of the OSINT scan, e.g., normal or deep.
• documents_limit (int): The maximum number of documents to retrieve.
• dorks (list): A list of dork types to search for. Available options are:
  • login_pages
  • admin_panels
  • dashboard_pages
  • stackoverflow
  • social_media
  • project_management
  • code_sharing
  • config_files
  • jenkins
  • wordpress_files
  • php_error
  • exposed_documents
  • db_files
  • git_exposed
• custom_dorks (list): Custom dorks will be a list of dictionaries, for example:

  • [{'lookup_site': 'google.com', 'lookup_keywords': '/home/'}]

  • [{'lookup_site': '__target__', 'lookup_extensions': 'db, php, jpg'}]

    lookup_site is where the information should be looked for. Example stackoverflow.com, or even the target, so the possible values for lookup_site could be any website or the target itself. Suppose, if you want to look for all db files in the target itself, lookup_site will be __target__. reNgine-ng will automatically replace this with actual target. Do not put the target name here, rather __target__.

    lookup_keywords or lookup_extensions

    lookup_keywords or lookup_extensions can not be used together, you can either search for specific path file in google or certain files that are indexed, so they can not be used together. You will need to use either lookup_keywords or lookup_extensions.

    lookup_keywords could be certain keywords, paths, separated by comma. lookup_extensions could be file extensions separated by comma.

dir_file_fuzz

This configuration will be used in Directory and file fuzzing. Currently supported options for dir_file_fuzz are:

• auto_calibration: (boolean) Automatically calibrate filtering options (ffuf specific)
• rate_limit: (int) The rate limit for fuzzing.
• extensions: (list) This option will allow you to define the extensions for the file fuzzing. You can define as many file extensions as you wish. Please note that, more file extensions will take longer to complete fuzzing. For example: ['php', 'git', 'xml']
• follow_redirect: (boolean) Follow redirects (ffuf specific)
• max_time: (int) If you don't want ffuf to run indefinitely, you can use the max_time. This stops the entire process after a given time (in seconds).
• match_http_status: (list) List of HTTP status codes to consider as a match.
• recursive_level: (int) Enabling recursive_level option will bruteforce recursively inside all the directories. Turning on this option will increase scan time exponentially but will gather more information. Use it wisely.
• stop_on_error: (boolean) Stop on spurious errors (ffuf specific)
• timeout: (int) The maximum time, in seconds, to wait for fuzzing to complete.
• threads: (int) The number of threads or concurrent processes to use for fuzzing.
• match_http_status: (list) Match HTTP status codes, or "all" for everything. For example: [200, 204]
• wordlist_name: (str) This option is used to supply wordlist for files and directory fuzzing. Available Options for wordlist_name are:

  • default

  • short_name_for_wordlist

    Please follow the guide on uploading your own wordlist. You need to enter the wordlist short_name here.

[!TIP] "Default Wordlist" If default wordlist is choosed then default dicc.txt will be used. [!CAUTION] reNgine-ng currently does not support multiple wordlists. This feature maybe available in future updates.

fetch_url

fetch_url uses tools like gau and hakrawler to gather the endpoints. Currently supported options for fetch_url are:

• uses_tools: (list) A list of tools to use for URL fetching. Available tools are:

  • gospider

  • hakrawler

  • waybackurls

  • gospider

  • katana

    It can be used as 'uses_tools': ['gospider', 'hakrawler', 'waybackurls']

• remove_duplicate_endpoints: (boolean) A boolean indicating whether to remove duplicate endpoints.

• duplicate_fields: (list) Fields used to identify duplicate endpoints. Available options are: - content_length - page_title - http_status - content_type - webserver

  Use these available options as combination to identify duplicate endpoints, for example ['content_length', 'page_title']

• gf_patterns: (list) List of patterns to search for using Gf. Available patterns are: - debug_logic - idor - interestingEXT - interestingparams - interestingsubs - lfi - rce - redirect - sqli - ssrf - ssti - xss

  Use the combination of GF patterns as: ['xss', 'lfi', 'rce']

[!TIP] You can also upload custom gf patterns, and use filename here, without extension.

• ignore_file_extensions: (list) This option will allow you to ignore certain file extensions while gathering URLs. You can use one or more combination of extensions to exclude. For example ['png', 'jpg', 'jpeg', 'gif', 'mp4', 'mpeg', 'mp3']
• exclude_subdomains: (boolean) If set to true, URLs will not be fetched for subdomains that are chosen to be ignored while initiating scan.

vulnerability_scan

• run_nuclei: (boolean) If set to true, nuclei will be used for vulnerability scan.

• run_dalfox: (boolean) If set to true, dalfox will be used for XSS scans.

• run_crlfuzz: (boolean) If set to true, CRLFuzz will be used for CRLF vulnerability detection.

• run_s3scanner: (boolean) If set to true, misconfigured s3 buckets will be used during vulnerability scan.

• concurrency: (int) This option will specify the number of threads/go routines to perform vulnerability scan.

• rate_limit: (int) Maximum number of requests to send per second

• retries: (int) Number of times to retry a failed request

• timeout: (int) Time to wait in seconds before timeout

• fetch_llm_report: (boolean) If set to true, LLM (Large Language Model) will be used to fetch vulnerability details such as impact and remediation. LLM configuration is required (OpenAI API key or local Ollama model).

  • nuclei: Nuclei specific configurations
    • use_conf: (boolean) If set to true, reNgine-ng will use configuration file for nuclei. Find more about configuration files here.
    • severities: (list) You can run the templates based on the specific severity of the template, single or multiple severity can be used for scan. Available options are:
      • all
      • critical
      • high
      • medium
      • low
      • info
      • unknown
    • tags: (list) List of nuclei tags, refer to Nuclei's documentation.
    • templates: (list) Please refer to nuclei's documentation to check which templates are supported. Nuclei may release any new templates which may not be possible to update here in the documentation, so it is adviced that you refer to Nuclei's documentation. For example ['files', 'cve']
    • custom_templates: (list) > [!TIP] > >

"Custom Nuclei Templates" You can also upload custom Nuclei Templates from Tool Settings, and use filename here, without extension.

- `s3scanner`: s3scanner specific configurations
    - `threads`: *(int)* s3scanner number of threads
    - `providers`: *(list)* List of providers to look for misconfigured s3 buckets. Availble options are:
        - `aws`
        - `gcp`
        - `digitalocean`
        - `dreamhost`
        - `linode`

        For example: `['aws', 'gcp']`

waf_detection

Use this to detect the WAF in subdomains, wafw00f will be used to identify WAF.

screenshot

Screenshot gathering

• timeout: (int) Timeout in seconds for screenshot gathering
• threads: (int) Numbers of threads to use for EyeWitness

Shared Scan Configuration

Some of the scan configurations such as threads or custom_header could be used across all the tasks. Instead of using them in individual task, you can also use them as shared configuration, outside the task object configuration.

• timeout - Global timeout for all tools
• rate_limit - Global rate limiting for all tools
• retries - Global retry attempts for all tools
• intensity - Global intensity level ('normal', 'deep')
• threads - Global number of concurrent threads
• custom_header - Global custom HTTP headers (authentication, user-agent, etc.)
• user_agent - Global user agent string (Dalfox specific)

[!NOTE]
Global configurations can be overridden by tool-specific settings within individual task configurations.

Example:

# Global vars for all tools
#
# Custom header - FFUF, Nuclei, Dalfox, CRL Fuzz, HTTPx, Fetch URL (Hakrawler, Katana, Gospider)
custom_header: {
  'Cookie': 'session_id=abc123',
  'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0',
  'Authorization': 'Bearer token123'
}
user_agent: 'Custom-Agent/1.0'      # Dalfox only                   
timeout: 10                         # Subdomain discovery, Screenshot, Port scan, FFUF, Nuclei                       
threads: 30                         # All tools
rate_limit: 150                     # Port scan, FFUF, Nuclei
intensity: 'normal'                 # Screenshot, Nuclei, OSINT intensity
retries: 1                          # Nuclei retry attempts

These shared scan configurations will be used across all the tasks unless overridden by tool-specific settings.

[!TIP]
For authentication-based scans, use the custom_header to include cookies or authorization tokens. This allows you to scan authenticated areas of web applications.