Scan Modules
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Scan modules are the core functional units of the OWASP Nettacker framework, designed to automate information gathering, vulnerability assessment, and reconnaissance. Each module is a self-contained entity responsible for a specific security task, such as identifying open ports, discovering administrative directories, or fingerprinting Content Management System (CMS) components like WordPress plugins and Drupal modules.
These modules utilize various protocols—primarily HTTP/HTTPS for web-based scanning—and support multi-threaded execution to perform large-scale network audits efficiently. The modular architecture allows the engine to load and execute modules based on user-defined profiles or specific scan methods, providing a flexible and scalable approach to security testing.
Sources: README.md:21-25, nettacker/locale/en.yaml:70-73
Module Structure and Configuration
Scan modules in OWASP Nettacker are defined using YAML configuration files. These files contain metadata about the module and the technical payloads required to perform the scan.
Metadata (info section)
Every module includes an info block that defines its identity and classification. Key fields include:
- name: The unique identifier for the module (e.g.,
admin_scan). - severity: A numerical rating of the potential impact (e.g., 3 for moderate severity).
- description: A brief explanation of the module's purpose.
- profiles: A list of tags used to group modules for bulk execution (e.g.,
scan,http,wordpress).
Sources: nettacker/modules/scan/admin.yaml:1-12, nettacker/modules/scan/wp_plugin.yaml:1-11
Execution Logic (payloads section)
The payloads section defines how the module interacts with the target. Most scan modules leverage the http library to perform web requests.
Workflow Diagram
This diagram illustrates the logical flow of a scan module execution:
The fuzzer component is responsible for generating request URLs by combining schemas, targets, ports, and paths.
Sources: nettacker/modules/scan/admin.yaml:14-38, nettacker/modules/scan/wp_plugin.yaml:13-41
Key Scan Module Categories
Directory and File Discovery
Modules like admin_scan use wordlists to identify sensitive directories or files on a web server. These modules typically look for status codes that indicate existence or restricted access.
| Component | Description |
|---|---|
| Input Format | {{schema}}://{target}:{{ports}}/{url_base_path}{{urls}} |
| Wordlist Source | wordlists/admin_wordlist.txt |
| Success Criteria | Status codes 200, 403, or 401 |
Sources: nettacker/modules/scan/admin.yaml:14-49
CMS Fingerprinting and Vulnerability Scanning
Nettacker contains specialized modules for popular CMS platforms like WordPress and Drupal. These modules often extract version information or identify installed extensions.
WordPress Modules
WordPress scanning involves multiple specialized sub-modules:
- wp_plugin: Detects plugins by accessing
readme.txtfiles and uses regex to extract version numbers (e.g.,Stable\stag:\s(\d+\.\d+\.\d+)). - wp_theme: Scans for known theme paths to identify the visual framework.
- wp_timethumbs: Specifically targets the TimThumb script, often a source of vulnerabilities.
Sources: nettacker/modules/scan/wp_plugin.yaml:1-50, nettacker/modules/scan/wp_theme.yaml:1-40, nettacker/modules/scan/wp_timethumbs.yaml:1-45
Drupal Modules
The drupal_module_scan fingerprints Drupal installations by searching for specific patterns in the content, such as references to the /modules/ directory path.
Sources: nettacker/modules/scan/drupal_modules.yaml:1-42
Data Interaction and Output
When a scan module completes its request, it evaluates the response against predefined conditions (using and or or logic).
Response Evaluation Logic
Modules use regular expressions (regex) to validate content, status codes, or URLs.
response:
condition_type: and
log: "response_dependent['url']"
conditions:
content:
regex: Stable\stag:\s(\d+\.\d+\.\d+)
reverse: false
status_code:
regex: "200"
reverse: false
Sources: nettacker/modules/scan/wp_plugin.yaml:42-51
Localization and Engine Feedback
The engine provides feedback during module execution based on localized strings. These include notifications for module start, completion, and failure conditions.
| Key | Description (English) |
|---|---|
loading_modules | Indicates the engine is loading all available modules. |
finished_module | Triggered when a module finishes against a specific target. |
scan_module_not_found | Error returned if a specified module is missing. |
no_live_service_found | Returned if service discovery fails before the module scan. |
Sources: nettacker/locale/en.yaml:26-30, nettacker/locale/en.yaml:70-75, nettacker/locale/en.yaml:113-115
Summary
Scan modules provide the granular functionality that makes OWASP Nettacker a versatile reconnaissance tool. By utilizing YAML-based configurations, the project separates the engine logic from the specific payloads, allowing for easy updates to fingerprints and wordlists. Whether performing a simple port scan or deep CMS fingerprinting, these modules follow a standardized request-response-condition flow that integrates directly with the project's reporting and database systems.