Static Low-interaction Honeypots
I love honeypots. They are so much fun. I haven’t run one in a very long time: the reason is that a while back (almost a decade now,) I had a high-interaction honeypot that was compromised, and what I saw was scary. Not that the attacks were all that interesting, but what else they had compromised made me worried. Enough said.
But recently, I have been putting a lot of time and thought into production honeypots—low interaction systems with minimal attack surface that can act as early warning of a real attack. Research-honeypots are fun, but allowing actual compromises, keeping them contained, and doing forensics is a lot of work. My interest at this point is more tactical than academic. There are a lot of really cool honeypot systems out there, but I wanted to get practice building custom web application honeypots. The premise is to create a static mirror of a website, and either introduce simulated, or previously well-known vulnerabilities. Then knowing exactly what vulnerabilities exist, monitor for only those, and automate whatever measures are appropriate, like D-Natting the attacker to a shadow-network away from valuable targets. It’s not a new idea—I wrote a paper on what I called then “bait and switch honeypots” in 1999.
SLowDeATH: Realistic Web-Application Honeypots with only static HTML and NGinX Rewrite Rules
As part of this, I have released a few of the “generic” applications I have created simulations of and have made them available as a project called SLowDeATH (Static Low-interaction Deceptive Attack Target Honeypots) on GitHub.
Right now I have only released two example configurations: Umbraco 4.7 and Tomcat 5.5, and (at the time of writing this at least,) there is a live system you can look at on the Internet: Umbraco Honeypot and Tomcat Honeypot.
Here’s the project’s README from GitHub
Static Low-interaction Deceptive Attack Target Honeypots
This is a collection of NGinx configuration files and static HTML that emulates vulnerable web applications. It requires the NginxHttpHeadersMoreModule, but otherwise does not require any active scripting languages to be in place. Because it is an entirely static configuration, it is very portable and convenient to place as the default virtual host.
- Create a wide range of simulated applications
- Test with tools such as metasploit, NMap, popular exploits found on Exploit DB, Nikto, and others to get as close as possible to the same scan results.
- Be as accurate as necessary so that an actual human attacking the site believes that it is real (correct headers, error messages, and so on.) Basically, I want a skilled attacker to waste as much time as possible before they finally figure out it isn’t real.
How are the configurations created?
It’s an entirely manual process. I interact with the site and take notes on what headers should be present, or not present, what the expected behavior is for successful and failed logins, the rewrite the headers, and create rules that emulate the site. I create a static copy of the HTML by crawling with WGet and then map the file names appropriately (aspx and jsp etc.)
Then I use various attack tools, run the actual MSF exploit until it looks like it was successful—up to the point where a reverse shell is supposed to be popping back.
Tomcat 5.5 (Debian 4):
- Manager application is accessible with tomcat:tomcat login.
- Exploitation with metasploit’s
exploit/multi/http/tomcat_mgr_uploadmodules appear successful up to the point where code execution would take place.
- Nikto successfully detects vulnerability.
- There are some problems with a few rewrite rules, so it’s not entirely believable to a human attacker yet.
Umbraco 4.7 on IIS 7.5 (Windows 7):
- This is not a very popular application to exploit, so it produces less-noise. Very useful for finding attacks driven by a person, and not just a mass-exploit script.
exploit/windows/http/umbraco_upload_aspxappears successful, but no code execution takes place.
- Nikto flags Umbraco headers as “interesting”.
- A few misc errors, but the overall experience for a human attacker is very convincing.
- I am actively working on a Wordpress configuration with half a dozen or so vulnerable plugins. It’s a little tricky though because I don’t want to expose any DoM XSS vulns on the honeypot. Right now it is close to being completed, but not entirely believable yet. The WP-Scan flags most of the vulnerabilities introduced, but I have not yet finished rewrite rules to make a login look successful. I also want to put some work into simulating successful trackback spamming and comment spamming so it can be used as a spam trap.
The next few planned after this are Drupal, JBoss 4 or 5, and maybe a MySQL admin or other popular tool. If you have any ideas please feel to contribute to the project.
Since NGinX isn’t modular you are somewhat limited with regards to using certain functionality like ModSecurity, for example the only system that makes it easy to get ModSecurity and HeadersMore installed together without building it yourself is FreeBSD using the ports tree, it still has to compile everything, but at least upgrading is easy.
It’s also useful to add rate-limiting through the
limit_rate module to make things take longer, but be careful not to go too slow my testing has been that right around
limit_rate 1k; exploits start timing out.
On debian you can install the NginxHttpHeadersMoreModule NGinX package by running:
apt-get install nginx-extras