[New Rule] Initial Access via File Upload Followed by GET Request

[Aegrah]

Summary

This rule detects potential initial access activity where an adversary uploads a web shell or malicious script to a web server via a file upload mechanism (e.g., through a web form using multipart/form-data), followed by a GET or POST request to access the uploaded file. By checking the body content of HTTP requests for file upload indicators such as "Content-Disposition: form-data" and "filename=", the rule identifies suspicious upload activities. This sequence of actions is commonly used by attackers to gain and maintain access to compromised web servers.

Telemetry

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Initial Access via File Upload Followed by GET Request (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[terrancedejesus]

We shouldn't restrict to 200 because some file upload vulns don't respond with 200's such as CVE-2025-24813; it really depends on the logic of the application itself even if it adheres to a specific RFC.

[terrancedejesus]

Suggested change

	http.response.status_code in (200, 201, 204, 301, 302, 303) and
	http.response.status_code in (200, 201, 204, 301, 302, 303, 409) and

[terrancedejesus]

Wonder if we would have better luck doing file creation (webshell) to webshell requests and sequence on file name? Could also add arbitrary parameters like cmd= (hard to guess here as they could be anything), etc. wdyt?