You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pyproject.toml
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
[project]
2
2
name = "detection_rules"
3
-
version = "1.5.20"
3
+
version = "1.5.21"
4
4
description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine."
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
30
+
31
+
### Investigating Potential HTTP Downgrade Attack
32
+
33
+
This detection surfaces HTTP traffic negotiating a protocol version that deviates from your baseline, a sign of downgrade attempts that strip protections and enable evasion or exploit paths in older behaviors. An attacker deliberately breaks HTTP/2 negotiation so the server falls back to HTTP/1.1, then probes with crafted headers and chunked bodies to attempt request smuggling or cache bypass against web services.
34
+
35
+
### Possible investigation steps
36
+
37
+
- Correlate with TLS termination or load balancer logs to verify ALPN or Upgrade negotiation (server advertising h2) and whether the same client/IP previously used h2 with the same SNI/Host, distinguishing forced downgrade from capability mismatch.
38
+
- Review the downgraded requests for exploitation indicators such as simultaneous Content-Length and Transfer-Encoding headers, duplicated or mixed-case headers, unusual methods (TRACE or PRI), or inconsistent chunked encoding suggesting smuggling attempts.
39
+
- Examine surrounding response patterns for increased 400/421/426/431/505, backend 5xx, connection resets, or latency spikes that coincide with these requests and indicate error-driven fallback or probing.
40
+
- Check for recent config changes or incidents on CDNs/WAFs/load balancers and web servers (e.g., http2 enablement, ALPN lists, h2/h2c settings) that could have disabled HTTP/2 and caused benign fallbacks.
41
+
- Cluster events by source IP/User-Agent/ASN and targeted host to identify campaign activity across services and pivot the sources through threat intelligence or reputation feeds.
42
+
43
+
### False positive analysis
44
+
45
+
- Recent Nginx/Apache/Tomcat configuration changes that disable HTTP/2/h2c or alter TLS/ALPN on specific virtual hosts can legitimately force clients to fall back to HTTP/1.1, surfacing as a downgrade event in access logs.
46
+
- Newly onboarded internal services or scripts that only support HTTP/1.0/1.1 and begin hitting an endpoint for the first time can introduce a first-seen older http.version relative to an HTTP/2 baseline without malicious intent.
47
+
48
+
### Response and remediation
49
+
50
+
- Immediately block or challenge source IPs/ASNs repeatedly forcing HTTP/1.1 to hosts that previously negotiated HTTP/2 via ALPN, and enable WAF rules to drop “Upgrade: h2c” attempts, requests with both Content-Length and Transfer-Encoding, or duplicated/mixed-case headers.
51
+
- Remove downgrade paths by requiring TLS+ALPN “h2” on 443 (e.g., Nginx listen 443 ssl http2; Apache Protocols h2 http/1.1), disabling cleartext h2c and HTTP/1.0 on public endpoints, and ensuring intermediaries do not strip ALPN or rewrite headers.
52
+
- Redeploy corrected configs and validate end-to-end HTTP/2 with curl --http2 and browser devtools, then confirm normal 2xx/3xx rates and elimination of 421/426/431/505 responses and backend 5xx spikes around previously downgraded traffic.
53
+
- Escalate to Incident Response if downgraded requests show smuggling patterns (simultaneous Content-Length and Transfer-Encoding, mixed-case duplicates, TRACE/PRI methods), hit sensitive paths (/admin, /login, /actuator), or trigger cache anomalies like cross-user content.
54
+
- Harden parsing and caching by normalizing headers at the edge, enforcing a single Content-Length, disabling TRACE, setting strict client_header_buffer_size and large_client_header_buffers, and configuring proxies/backends to reject conflicting CL/TE or ambiguous chunked bodies.
min_stack_comments = "The esql url_decode() operator was introduced in version 9.2.0"
7
-
updated_date = "2025/12/02"
7
+
updated_date = "2025/12/08"
8
8
9
9
[rule]
10
10
author = ["Elastic"]
@@ -18,6 +18,37 @@ interval = "10m"
18
18
language = "esql"
19
19
license = "Elastic License v2"
20
20
name = "Web Server Local File Inclusion Activity"
21
+
note = """## Triage and analysis
22
+
23
+
> **Disclaimer**:
24
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
25
+
26
+
### Investigating Web Server Local File Inclusion Activity
27
+
28
+
This rule surfaces successful GET requests containing directory traversal or direct access to sensitive paths, signaling Local File Inclusion exploitation that can expose credentials, configuration, and process context and enable further compromise. A common attacker pattern is abusing a vulnerable parameter to fetch ../../../../etc/passwd, then pivoting to /proc/self/environ to harvest secrets and identify execution context for subsequent steps.
29
+
30
+
### Possible investigation steps
31
+
32
+
- Retrieve contiguous access logs around the alert to rebuild each request/response pair (URI, parameters, user agent, referer, cookies, X-Forwarded-For) and identify which parameter reflected traversal or wrapper usage and whether the response likely contained file contents.
33
+
- Compare response sizes and content-types for the suspicious requests to normal pages and look for signatures such as "root:x:" lines, INI/XML keys, or base64 blobs that indicate disclosure of /etc/passwd, web.config/applicationhost.config, or other sensitive files.
34
+
- Review web server and application error logs at the same timestamps for include/open stream warnings, open_basedir or allow_url_fopen messages, and stack traces to confirm the code path handling the input and any mitigations in place.
35
+
- Pivot on the same source and timeframe to find adjacent probes (php://filter, data://, expect://, zip://, phar://, /proc/self/environ, traversal into webroots/configs) and any follow-on POSTs to upload endpoints or new script paths, signaling progression toward RCE or webshell placement.
36
+
- Determine whether the traffic was authenticated and whether it traversed a WAF or reverse proxy by correlating cookies or session IDs and client IPs with proxy/WAF logs, noting any blocks, rule matches, or bypasses to bound scope and urgency.
37
+
38
+
### False positive analysis
39
+
40
+
- A site search or documentation endpoint echoing user-supplied text can include strings like ../../../../etc/passwd, windows/win.ini, or php://filter in the query string and return a normal 200 OK results page rather than performing a file include.
41
+
- An authenticated admin feature (such as a log viewer or file browser) may legitimately accept path= or file= parameters referencing local paths like /var/log/nginx or /inetpub/logs/logfiles and return 200 when serving allowed files, producing URLs that match the rule without exploitation.
42
+
43
+
### Response and remediation
44
+
45
+
- Immediately block the source IP at the reverse proxy/WAF and deploy deny rules for GET requests using ../../ or ..\..\ traversal or wrappers (php://, expect://, data://) that fetch /etc/passwd, /proc/self/environ, wp-config.php, web.config, or applicationhost.config.
46
+
- Configure the web server to return 403 for paths resolving to /proc, /etc, /var/log, /inetpub, applicationhost.config, and web.config and to reject wrapper schemes like php:// and expect://, then reload Nginx/Apache/IIS to apply.
47
+
- Fix the vulnerable include logic by canonicalizing input with realpath, rejecting any .. segments or absolute paths, enforcing a whitelist of allowed files, and in PHP disabling allow_url_include/allow_url_fopen and setting open_basedir to a safe directory.
48
+
- Rotate exposed secrets by changing database and API credentials from wp-config.php, connection strings and machine keys from web.config/applicationhost.config, and any tokens in /proc/self/environ, then invalidate active sessions and cache.
49
+
- Escalate to incident leadership and quarantine the host if response bodies contain credential patterns (e.g., "root:x:" from /etc/passwd or XML keys from web.config), if /etc/shadow or windows/system32/config/SAM was requested, or if follow-on POSTs or new .php/.aspx files appear in the webroot.
50
+
- Recover by verifying integrity of /var/www and /inetpub/wwwroot, scanning for webshells and unexpected includes, redeploying a known-good build or container image if tampering is found, and adding WAF normalization to double-decode URLs and 403 traversal attempts.
min_stack_comments = "The esql url_decode() operator was introduced in version 9.2.0"
7
-
updated_date = "2025/12/02"
7
+
updated_date = "2025/12/08"
8
8
9
9
[rule]
10
10
author = ["Elastic"]
@@ -18,6 +18,38 @@ interval = "10m"
18
18
language = "esql"
19
19
license = "Elastic License v2"
20
20
name = "Web Server Potential Remote File Inclusion Activity"
21
+
note = """## Triage and analysis
22
+
23
+
> **Disclaimer**:
24
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
25
+
26
+
### Investigating Web Server Potential Remote File Inclusion Activity
27
+
28
+
This rule identifies successful GET requests that pass a remote URL or raw IP in a parameter, signaling Remote File Inclusion attempts that coerce the app to fetch external content or reveal local files. RFI matters because it enables discovery, leaks sensitive data, and can bootstrap code retrieval for persistence or command-and-control. Example behavior: probing an include endpoint with /index.php?page=http://203.0.113.10/drop.txt to verify remote fetch and execution via a vulnerable loader.
29
+
30
+
### Possible investigation steps
31
+
32
+
- Decode the full request URL and parameters, identify the endpoint and parameter names, and confirm with application owners whether passing remote URLs is expected behavior for that route.
33
+
- Correlate the event time with outbound connections from the web server to the referenced domain or IP using egress firewall, proxy, DNS, or NetFlow logs to verify whether a fetch occurred.
34
+
- Review adjacent web access entries from the same source IP and user agent to detect scanning behavior, varied include parameters, wrapper strings (php://, data://, file://), or local file probes that indicate exploitation attempts.
35
+
- Check the referenced remote domain or IP with threat intelligence, and if needed, safely retrieve it in an isolated environment to examine content, redirects, and headers for droppers or callbacks.
36
+
- Look for post-inclusion artifacts by checking webroot and temp directories for newly created or modified files, suspicious script writes, and unusual access patterns, and inspect server or application configuration for risky URL include settings.
37
+
38
+
### False positive analysis
39
+
40
+
- Applications that legitimately accept full URLs in query parameters for link previews, content proxies, image fetching, or feed importers (e.g., url= or src=) will return 200 and match *=http(s)://*, appearing as RFI despite expected behavior.
41
+
- Administrative or diagnostic endpoints that allow users to supply IP addresses or URI schemes (ftp://, smb://, file://) to test connectivity or preview resources (e.g., target=192.168.1.10) can return 200 and trigger this rule even though no inclusion vulnerability is present.
42
+
43
+
### Response and remediation
44
+
45
+
- Immediately block offending source IPs and request patterns at the WAF/reverse proxy (e.g., GETs where page=, url=, or src= contains http://, https://, ftp://, smb://, or file://) and temporarily disable the affected include/loader endpoints until fixed.
46
+
- Restrict outbound connections from the web server to the domains and IPs referenced in the requests and quarantine the host if 200 OK responses align with remote downloads or wrapper usage such as php://, data://, file://.
47
+
- Collect forensic images, then remove newly created or modified scripts in webroot and temp directories (e.g., /var/www, uploads, /tmp), delete unauthorized .htaccess/web.config entries, clear caches, and terminate suspicious processes running under the web server account.
48
+
- Redeploy the application from a known-good build, restore clean configuration files, rotate credentials exposed by local file probes (e.g., config.php, .env), invalidate sessions, and verify functionality before returning the service to production.
49
+
- Harden by disabling risky features and enforcing strict input controls: set PHP allow_url_include=Off and allow_url_fopen=Off, apply open_basedir restrictions, implement scheme/domain allowlists for any include/load functionality, and sanitize and normalize user-supplied parameters.
50
+
- Escalate to incident response and preserve disk and memory images if remote content was fetched and executed, a webshell or unknown script is found in the webroot, or the same actor generates successful 200 RFI-style requests across multiple hosts.
51
+
- Enhance monitoring for RFI attempts by tuning WAF rules to alert on suspicious include parameters, enabling detailed web server logging, and setting up alerts for anomalous outbound connections from web servers.
Copy file name to clipboardExpand all lines: rules/cross-platform/initial_access_file_upload_followed_by_get_request.toml
+33-1Lines changed: 33 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
creation_date = "2025/11/27"
3
3
integration = ["endpoint", "network_traffic"]
4
4
maturity = "production"
5
-
updated_date = "2025/11/27"
5
+
updated_date = "2025/12/08"
6
6
7
7
[rule]
8
8
author = ["Elastic"]
@@ -19,6 +19,37 @@ index = ["logs-endpoint.events.*", "logs-network_traffic.*"]
19
19
language = "eql"
20
20
license = "Elastic License v2"
21
21
name = "Initial Access via File Upload Followed by GET Request"
22
+
note = """## Triage and analysis
23
+
24
+
> **Disclaimer**:
25
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
26
+
27
+
### Investigating Initial Access via File Upload Followed by GET Request
28
+
29
+
This rule flags a common initial-access pattern: a multipart/form-data upload that drops a dynamic web script on a server, followed shortly by a request to execute that file and establish a foothold. Attackers exploit a permissive upload form to plant shell.php or shell.jsp in an uploads or temp directory, then immediately request it to spawn a web shell, enumerate files, and run commands—often leveraging redirects or 2xx/3xx responses that indicate successful placement and access.
30
+
31
+
### Possible investigation steps
32
+
33
+
- Correlate the upload transaction with the server-side file creation and the subsequent access to the same resource, matching timestamps, source IP, and path, and follow any redirects to the final executed file.
34
+
- Retrieve the uploaded artifact from disk, verify it sits in a web-accessible location, inspect content for web shell traits (eval/system/exec, obfuscation, password gates), and record hashes.
35
+
- Examine server process telemetry immediately after the access for interpreter or shell spawns and unexpected outbound connections originating from web server workers.
36
+
- Review application logs and access context to determine whether the upload was authenticated, which account or session performed it, and whether user-agent, referer, or headers deviate from normal clients.
37
+
- Broaden the timeline to identify related uploads, file renames, or repeated requests from the same actor, including parameterized calls that suggest command execution or directory enumeration.
38
+
39
+
### False positive analysis
40
+
41
+
- An authenticated administrator installs a legitimate plugin or module via the application’s upload form, which unpacks or renames .php or .jsp files and then auto-loads a setup page, producing the multipart upload, file creation/rename, and immediate GET pattern.
42
+
- Automated deployment or QA routines upload and deploy a .war or server-side script through a web-based admin interface and then perform health-check or warm-up requests, resulting in the same multipart upload, server-side file creation, and follow-up GET sequence.
43
+
44
+
### Response and remediation
45
+
46
+
- Immediately block access to the uploaded script that was invoked via GET/POST (e.g., /uploads/shell.php) and the source IPs that executed it, restrict the site to allowlisted IPs or maintenance mode, and temporarily disable the upload endpoint.
47
+
- Quarantine and remove the uploaded web shell and any additional executable scripts or WARs in web-accessible directories (uploads, webroot, temp), terminate interpreter or shell processes spawned by the web server account (www-data/nginx/w3wp/tomcat), and revert malicious .htaccess/web.config rewrites.
48
+
- Hunt for persistence and lateral-movement artifacts created after the upload, including recent .php/.jsp/.cgi file creations or renames in static asset folders, cron/systemd tasks, startup scripts, unauthorized admin users or plugins, and remove them.
49
+
- Restore altered application files from known-good backups or redeploy a clean container/VM, rotate database and API credentials stored in config files or environment variables, invalidate active sessions, and only re-enable uploads after confirming execution is blocked in upload directories.
50
+
- Escalate to incident command and privacy/legal if you observe command execution parameters on the uploaded page (?cmd=, ?exec=), shells spawning (/bin/sh, powershell.exe), database dumps, or outbound callbacks from web server processes to external hosts.
51
+
- Harden by storing uploads outside the webroot, denying execution in upload paths (disable PHP/CGI handlers and set noexec permissions), enforcing strict extension/MIME allowlists and AV/sandbox scanning for multipart/form-data, enabling file-integrity alerts on new .php/.jsp in served paths, and deploying WAF rules to block direct requests to uploaded executables.
0 commit comments