nturley3/zeek-http-rce

A Zeek package to detect potential remote code execution attempts over HTTP.

Zeek HTTP RCE

Purpose

This module tags HTTP logs and generates a notice log when it detects possible remote code execution (RCE) attempts over HTTP, similar to how the Zeek SQL injection script works. It's based on common characteristics security analysts observed of RCE attempts of exploits or webshells. It is not based on CVEs, but rather on RCE behaviors found in the "Delivery" and "Installation" phases of the cyber kill chain.

Installation/Upgrade

This script was written and tested using Zeek 3.0.11 and 4.0.3.

Install the latest version through the Zeek package manager:

zkg refresh
zkg install https://github.com/nturley3/zeek-http-rce

Note: A script logging the HTTP post body is required for examining post body data. There are two suggested packages when running the above command. You only should install ONE package, not both. The two packages will conflict and add a performance hit to Zeek. To ignore the suggested packages, include the --nosuggestions flag.

To upgrade the package:

zkg refresh
zkg upgrade zeek-http-rce

See the Zeek Package Manager Docs for more information.

Configuration

No additional Zeek configuration is necessary for this module.

See the zkg.meta file for suggestions, or accept one of the suggested package when using zkg to install. Do not install both packages.

Generated Outputs

This package adds a tag to the HTTP log:

tags Field Value	Description
HTTP_RCE::URI_RCE	Identifies possible RCE attempts in the URI.
HTTP_RCE::POST_RCE	Identifies possible RCE attempts in the post body. (MUST HAVE A POST_BODY SCRIPT INSTALLED.)
HTTP_RCE::HEADER_RCE	Identifies possible RCE attempts in the HTTP headers.

This package generates a notice log:

Field Name	msg	sub	src
HTTP_RCE::RCE_Victim	An RCE victim was discovered!	Samples of RCE Attempts	The victim IP address
HTTP_RCE::RCE_Attacker	An RCE attacker was discovered!	Samples of RCE Attempts	The attacker IP address

Usage

A security analyst could treat this similar to the SQL injection notice log or HTTP logs tagged with SQLI. Many RCE attempts will likely be unsuccessful and not require further action. While threat hunting, an analyst may identify targeted web applications or deployed webshells. Often the RCE attempt will trigger the victim system to reach out to another website to download a web shell or other malware, although the RCE could also deliver the webshell itself.

A generated notice log or HTTP tag does not mean the RCE attempt was successful, just that an attempt occurred. This script is prone to producing false positives.

Type: Threat Hunting

About

Written by @forewarned and @nturley3.

zeek-http-rce's Issues

Create a Config file

We should create a config.zeek file and move the const variables to it. Also include a variable to examine just local networks which will be enabled by default for performance.

Raise Notice when server returns HTTP 200/500 Status Codes

To improve fidelity, we could raise a notice if the server returns an http 200 or 500 status code.

Test Regex For URL Encoded/Decoded

Currently the regex looks for both [[space]] and the URL-encoded space +. I'm not sure how Zeek handles the data at the point this package analyzes the post_body. Do we need both? Or just one? It's worth testing further.

Too many False Positives with /(curl[[:space:]]+)/i

The /(curl[[:space:]]+)/i produces too many false positives. We can increase the accuracy by including additional regex. Possible ideas include:

• Look for a hostname, IP address, or URL. Drawback is the regex becomes more costly.
• Look for a protocol such as http://, ftp://, or maybe just ://. Downside is curl doesn't require specifying a protocol.
• Look for output flags or redirection such as -o, -O, --output, or >. Probably the simplest approach with higher fidelity. I wonder if there are RCE attempts that don't write out something to a file initially.

Cookie RCE not implemented

RCE checks on the cookie have not been implemented. I have no examples of RCE attempts over the cookie field, or any field for that matter. This brings up the question--Should we look for RCE attempts in other HTTP headers too?