[New Rule] Simple HTTP Web Server Creation

[Aegrah]

Summary

This rule detects the creation of a simple HTTP web server using PHP or Python built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost.

##Telemetry
0 hits in telemetry last 90d, only TPs in testing stack:

[protectionsmachine]

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.

[terrancedejesus]

Thoughts on adding http.server (known as SimpleHTTPServer) as well? --> python -m http.server. You can setup CGI with the --cgi argument as well and bind to a specific port or listen on any address. I'd be interested in alerts where 0.0.0.0 is the specified address as it is a "accept any" on cloud instances.

Another option would be Flask setup via inline code execution as shown below. I thing from command line args you could check for import flask and app.run and flag it as you will always need to import and initialize call app.run.

python3 -c "from flask import Flask; app = Flask(__name__); @app.route('/') def hello(): return 'Hello, World!'; app.run(host='0.0.0.0', port=8000)"

[Aegrah]

The python web server spawn is already in

detection-rules/rules/linux/execution_python_webserver_spawned.toml

Line 57 in 2ff2965

(process.name like "python*" and process.args in ("http.server", "SimpleHTTPServer")) or

. I put this one with cgi and -S for PHP as these command flags allow you to dynamically execute code that is hosted on the server. So it can serve as a cmd/reverse shell backdoor if you spawn them like this. Just the web server is only for downloading.

I did not add flask in there because it requires an additional module, which attackers would prefer not to install. And I think starting flask applications will be very noisy. I can check telemetry though!

[terrancedejesus]

Added some thoughts on additional logic, but LTGM.