Threat Definitions & Detection Levels

AMWScan ships its detection data through the Signatures API and includes a complete embedded bundle in every release. Application integrations should use the documented read-only methods in Signature Lookup, not the mutable definition arrays.

Embedded definitions include:

• Plain text fragments and 10,207 optimized regular expressions, including malware signatures
• Exact SHA-256 malware hashes generated from the repository fixture corpus.
• Fixed-width known-malware MD5-prefix candidates.
• Normalized legacy-core SHA-256 signatures used by the optional WordPress module.
• 54 suspicious domains curated from malware fixtures and excluded when found in clean fixtures or identified as legitimate shared services.
• Scoped JavaScript definitions for decoded dynamic execution, cookie-sourced execution, character-code script injection, XOR/Base64 payload execution, and long encoded document writes. These definitions run only on .js files.
• Context-aware process execution checks for major PHP frameworks and platforms.

Framework process execution

Framework process checks run in Full, Lite, Exploits, and Functions modes. They are excluded from Signatures-only mode. They use PHP tokens rather than broad regular expressions, so a finding requires confirmed platform provenance through an exact import, fully qualified class, platform-specific symbol, or typed receiver, followed by a terminal execution method.

Construction and configuration alone are not findings. Generic Process classes, bare run(), start(), execute(), or run_command() calls, Laravel Artisan calls, and Drush factories without a connected lifecycle method are ignored. WP_CLI::runcommand() is also ignored when literal options set launch to false. Symfony Messenger dispatch is reported only when a resolved message bus receives a resolved RunProcessMessage. Ordinary confirmed process execution is warning-level review evidence, not proof that the containing file is malicious. A connected command literal is promoted to dangerous only when it contains a high-confidence download-to-interpreter pipeline, encoded interpreter execution, reverse-shell construction, or destructive root deletion. Callback text, unrelated strings, non-root cleanup, and shell operators passed as inert arguments to a non-shell executable are not promoted.

Supported execution surfaces include Symfony Process and legacy ProcessBuilder lifecycle methods; Symfony process-message dispatch; the Laravel Process facade and typed pending, pipe, and pool objects; WP-CLI launch and process APIs; typed WordPress SSH filesystem receivers; typed Magento / Adobe Commerce shell receivers; current or legacy Drush process APIs; Joomla daemon lifecycle calls; PrestaShop executable kernel cache clearing; TYPO3 command utilities; and CodeIgniter, Yii, and CakePHP development-server commands.

WooCommerce has no verified product-owned operating-system process abstraction. Its WordPress and WP-CLI execution paths are covered by those providers; Action Scheduler and other in-process or HTTP work are intentionally excluded.

AMWScan definition bundle

Official definition sources live in definitions/src/ and are built into the gzip-compressed TAR resources/definitions/definitions.amwdb fallback shipped with each package release. An AMWDB archive contains manifest.json, signatures.json, exploits.json, hashes.json, and functions.json. The function lists are editable definition data, not PHP source. The manifest records a monotonic sequence, engine compatibility, and the exact size and SHA-256 of every payload. The scanner validates archive contents, schema, regular expressions, sorted hash indexes, record counts, and checksums before using a bundle.

At startup, the scanner uses a valid cached AMWDB archive or the embedded fallback without requiring network access. It discovers official definitions-v* releases through the GitHub Releases API, downloads the release-owned definitions.json metadata asset, validates a changed archive in a private staging directory, and switches the active pointer only after every check passes. AMWSCAN_DEFINITIONS_METADATA_URL or --definitions-update-url=<https-url> can override discovery for a controlled mirror. Interrupted, incomplete, corrupt, or older downloads leave the last verified cache active.

Use --path-definitions=<path> to choose the private cache root. Add --disable-definitions-update to prevent network requests and use only a verified cached bundle or the embedded copy. Reports include the active AMWScan definition version, sequence, and manifest hash.

Use amwscan definitions status, amwscan definitions verify, and amwscan definitions inspect <database> to inspect active or downloaded archives. Maintainers use bin/amwscan-definitions validate and bin/amwscan-definitions build to validate source JSON and build the package fallback. Publisher signing is not enabled until a release signing key and stable official metadata endpoint are provisioned; status reports this explicitly as unsigned.

Local administrator rules

Local rules are separate from the immutable official archive. By default they live under the platform configuration directory in amwscan/rules; use --path-local-rules=<path> to override that directory for a scan. Optional local signatures.json, exploits.json, and hashes.json files must use the same validated format as official rule payloads and are merged after the official database.

Use amwscan rules validate to validate local files. amwscan rules disable exploit:<name> records an administrator override in disabled.json and amwscan rules list shows those overrides. Local rules are never downloaded, modified, or repacked by definition updates.

Integrity manifests

Trusted manifests report missing, modified, and unexpected managed files. WordPress core integrity covers root core files, wp-admin, and wp-includes; it excludes user-managed wp-content, including optional bundled plugins and themes. Manifest paths remain anchored to the detected installation root when directory names recur in managed filenames. Plugin directory matching respects complete path segments, and files with multiple official hashes are accepted when any hash matches. On Windows, manifest paths are compared case-insensitively to match filesystem behavior. Successful WordPress checksum data remains cached; failed requests expire after one hour so transient API failures can recover.

Dedicated verifiers cover WordPress, WooCommerce, Drupal, Joomla, Magento / Adobe Commerce, PrestaShop, TYPO3, Laravel, Symfony, CodeIgniter, Yii, and CakePHP. Repository manifests compare recognized platform distributions with their exact official release trees. Framework verifiers accept only their owned locked Composer packages and compare them with official distribution archives; the generic Composer verifier covers remaining packages. WooCommerce uses official WordPress plugin checksums. Application-owned code and mutable content are not treated as canonical framework files.

The WordPress plugin offers a Restore trusted file action for missing files recorded by a trusted WordPress core manifest when ext-zip is available, including optional bundled files retained in historical reports. It downloads the matching official WordPress release, extracts only the selected file, verifies its trusted manifest checksum, and writes it inside the scanned WordPress root. Exceptions remain available for findings that are expected in the site's configuration.

Maltrail definitions

At scan startup, AMWScan downloads the current Maltrail malware-domain trails into its private operating-system cache and rebuilds the local index. The cache is outside the scanned project and never needs to be committed. Reports expose its record count, source hash, generated index hash, and update time.

Domain matches are warning-level indicators because previously malicious infrastructure can be remediated or reassigned. A truncated hash or historical domain reference is insufficient to confirm malware by itself.