Introducing HASH: The HTTP Agnostic Software Honeypot framework

Honeypots are one of the most powerful tools for security professionals to gain intel about current emerging threats against specific technologies or around the internet.

One of the primary challenges for creating a honeypot is making it realistic enough to avoid being detected as a honeypot so malicious actors will continue to use it. The usual way of doing this is to create a custom application each time you want to create a honeypot, but this is very costly in terms of time and effort.

To solve this problem, we developed a framework to make it easy to mimic HTTP-based software with just a couple of YAML files.

Introducing HASH

We are excited to announce the release of HASH (HTTP Agnostic Software Honeypot), an open source unified framework for creating and launching low-interaction honeypots.

Low-interaction honeypots are a type of honeypot that simulate a vulnerable system or service in order to attract and monitor attacks. Unlike high-interaction honeypots, which provide a fully functional virtual environment, low-interaction honeypots are designed to emulate vulnerable behavior without much interaction from the attacker.

HASH is designed with a focus on ease of configuration and flexibility to mimic any software running on HTTP/HTTPs through fully randomized capabilities powered by fakerJS. In this post, we’ll cover how to quickly get started with HASH using YAML files, our pre-built honeytraps for added security, and optional out-of-the-box integrations with Datadog Log Management, Application Security Management, and APM for detailed honeypot monitoring

Using HASH

You can easily get started with HASH by simply defining how requests should be handled in YAML files inside profiles/<your-app-name>, as shown below:

id: sqli-error
info:
    title: "SQL error honeytrap"
requests:
  - isTrap: false 
    expect:
      method: GET
      path: '/author/:Id([0-9]+)'
    reply:
      status: 200
      headers:
        content-type: "text/html"
      body: 
        view: "author.html"
  - isTrap: true 
    expect:
      method: GET
      path: '/author/:Id'
    reply:
      status: 500
      headers:
        content-type: "text/html"
      body: 
        contents: "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 2"

And in the HTML file you can have something similar to the following:

<h1> Welcome $<faker.name.fullName()>, User ID </h1>

In the above example, we defined two requests: one for the normal expected route and the other if anyone added unexpected inputs.
If someone accesses the URL /author/123, for example, it will generate the HTML file author.html with information like:

Welcome Allen Brown, User ID 123

Notice that Allen Brown is randomly generated, and due to HASH caching, it will be the same if this endpoint is hit several times. But if you re-deploy HASH again or clear the cache, another value will be randomly generated.

On the other hand, User ID 123 is the same as the ID added in the URL to mimic normal application behavior.

Let’s observe if someone tries to inject a non-integer value—for example, a basic SQL injection attack:
/author/123%20UNION%20SELECT%20'a',NULL,NULL,NULL
The second request will be triggered and generate a fake MySQL error message:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 2

HASH supports a couple of logging mechanisms (console, file, datadog) that you can toggle on and off in the .env file. Based on your configured logging, you will see all of the details about each attempt:

hash-default  | warn: HASH: GET /author/123%20UNION%20SELECT%20'a',NULL,NULL,NULL: SQL error honeytrap {"http":{"client_ip":"::ffff:172.19.0.1","host":"localhost:8081","method":"GET","path":"/author/4123%20UNION%20SELECT%20'a',NULL,NULL,NULL"},"info":{"title":"SQL error honeytrap"},"request":{"body":{},"headers":{"accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7","accept-encoding":"gzip, deflate, br","accept-language":"en-US,en;q=0.9","connection":"keep-alive","cookie":"outrageous-hurricane=s%3AfknX0MQjfMfL0NKyJCHkBDf45cyczVUc.3tkiteJnNLai3G6psceWvqKhOKs49Cl2dwbv2n2bvY8","cookie_parsed":{"outrageous-hurricane":"s:fknX0MQjfMfL0NKyJCHkBDf45cyczVUc.3tkiteJnNLai3G6psceWvqKhOKs49Cl2dwbv2n2bvY8"},"host":"localhost:8081","sec-ch-ua":"\"Google Chrome\";v=\"111\", \"Not(A:Brand\";v=\"8\", \"Chromium\";v=\"111\"","sec-ch-ua-mobile":"?0","sec-ch-ua-platform":"\"macOS\"","sec-fetch-dest":"document","sec-fetch-mode":"navigate","sec-fetch-site":"none","sec-fetch-user":"?1","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"},"params":{"Id":"4123 UNION SELECT 'a',NULL,NULL,NULL"},"query":{}},"templateId":"author-sqli-error","type":"malicious"}

Simulating common technology stacks

In order to test HASH in the wild, we used HASH to simulate a simple Spring Boot application. We simulated the behavior of a typical Spring Boot API and added some traps.

Here is the result of a quick security scan against our created honeypot using FFuF & Nuclei.

Nuclei

As you can see below, Nuclei is detecting the honeypot as a Spring Boot application, making it an attractive target for attackers.

FFuF

Monitoring honeypot activity with Datadog

One of the nice features of HASH is its optional built-in integration with Datadog APM, Application Security Management, and Log Management, allowing us to have full visibility on HTTP requests and generated logs.

After deploying it, we created a simple dashboard to track activities on the honeypot:

The deployed honeypot was quickly picked up by bots and scanners. We noticed a few bots identified it as Spring Boot and tried to access the actuator endpoints (the default endpoint in most of Spring Boot applications and often contain sensitive information) but the majority were generic scans:

We also noticed that a lot of scans were looking for credentials via misconfigured application and hidden files:

What’s next

While HASH covers most of the use cases to build and maintain low-interaction honeypots with easy YAML-based configuration, we are looking to expand it toward medium-interaction honeypots while maintaining the same level of flexibility and seamless configurations.

Stay tuned for follow-up posts about interesting attacks we witnessed in the wild with HASH-based honeypots, as well as more honeypot profiles for common pieces of technologies, that you can leverage to run your own honeypots.

As always, we'd love to hear from you. Shoot us a message at securitylabs@datadoghq.com! You can also subscribe to our monthly newsletter to receive our latest research in your inbox, or use our RSS feed.