This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

OWASP Honeypot Project

Jump to: navigation, search
OWASP Project Header.jpg

OWASP Honeypot Project Background

Scientists at National Institute of Science and Technology claim that 92% of security vulnerabilities lie within the applications; handing the advantage over to the cyber-thieves. Many of these bugs can be eliminated simply by improving the code in which the software applications are written. The UK government estimates that the cost from cyber-attacks to be on average around £310,000 for a UK SME per annum, with almost 1 million UK SMEs having suffered from a data breach in 2017. SMEs are 70% more likely to be attacked than larger organisations, simply because they lack the ability to protect themselves. Regulations such as GDPR (which replaced the Data Protection Act in May 2018) exist to enforce that organisations protect data. Yet little in the way of understanding the threat exposures exist, with even less guidance on how to protect against the risks.

The web application Defender's community already exists. Not-for-profit charitable organisations such as OWASP (Open Web Application Security Project) raison d’etre is to provide an open source community to help organisations develop safer software applications that can be trusted to be secure against criminal attack. TSI (the Trusted Software Initiative) and OWASP create educational information on how software should be written and some of the more obvious bugs that are left open to give attackers access to confidential information.


Researchers are beginning to realise that by “watching” how Internet criminals behave, we can learn directly from their work flow activities, and use this information to protect ourselves. The past 20 years of research into Internet security, has made internal hosting infrastructures more secure, especially in large businesses. So today, Internet criminals take advantage of bugs in the software applications themselves. These bugs originate wholly because software has been poorly written and designed.

Large businesses may already employ a team of people to evaluate and protect any software facing the Internet. However, a key area lacking protection are the millions of smaller businesses worldwide that trade via the Internet, right down to the one person hobby-business selling products from home on eBay.

This project is about collecting and maximising intelligence from the cyber-battlefield that exists between attackers with criminal intent and the people creating the software upon which the Internet runs. By collecting intel on what the criminals are doing, we can define rules for writing software that can be fed back to the front line troops writing the code, so they can close these bugs and other vulnerabilities in their software. An attacker only needs to be lucky once, whereas we need to be lucky in protecting against all attacks, all of the time. By sharing the findings from our reconnoitres out in the field, this project provides educational information back to the community of software coders, be they professional developers or school kids working in their bedrooms. Today, the advantage lies clearly with the attackers. With this kind of threat information we take the advantage back into the hands of the defenders.


The goal of the OWASP Honeypot Project is to identify emerging attacks against web applications and report them to the community, in order to facilitate protection against such targeted attacks. Within this project, Anglia Ruskin University is leading the collection, storage and analysis of threat intelligence data.

The purpose of this part of the project is to capture intelligence on attacker activity against web applications and utilise this intelligence as ways to protect software against attacks. Honeypots are an established industry technique to provide a realistic target to entice a criminal, whilst encouraging them to divulge the tools and techniques they use during an attack. Like bees to a honeypot. These honeypots are safely designed to contain no information of monetary use to an attacker, and hence provide no risk to the businesses implementing them.

The project will create honeypots that the community can distribute within their own networks. With enough honeypots globally distributed, we will be in a position to aggregate attack techniques to better understand and protect against the techniques used by attackers. With this information, we will be in a position to create educational information, such as rules and strategies, that application writers can use to ensure that any detected bugs and vulnerabilities are closed.

Project progression:

  1. Honeypot software. The honeypot software that is to be provided to the community to place in their networks has been written. Honeypots are available in a variety of forms, to make deployment as flexible as possible and appeal to a diverse a user set as possible.
  2. Collection software. The centralised collection software has been written and evaluated in a student driven proof-of-concept project. Honeypots have been attacked in a laboratory situation and have reported both the steps taken by the attacker and what they have attacked, back to the collection software.
  3. Rollout to the Community. The project now needs a dedicated infrastructure platform in place that is available to the entire community to start collecting intelligence back from community deployed honeypots. This infrastructure will run the collector software, analysis programmes and provide a portal for communicating our finds and recommendations back to the community in a meaningful manner.
  4. Going Forward. Toolkits and skills used by attackers do not stand still.  As existing bugs are plugged, others open. . Follow up stages for the project will be to create a messaging system to automatically update the community on findings of significant risk in their existing code that requires attention.

What is the OWASP Honeypot Project?

The OWASP Honeypot Project provides:

  • Real-time, detailed Web Application Attack Data
  • Threat Reports to the community

News and Events

Project Resources

Project Leader

Related Projects



Project Type Files TOOL.jpg
Incubator Project Owasp-builders-small.png
Affero General Public License 3.0

How can I participate in your project?

All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.

If I am not a programmer can I participate in your project?

Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator. See the Road Map and Getting Involved tab for more details.



As of August, 2018, the priorities for the next 6 months are:

  • Setup Proof of Concept to understand how Mod Security baed Honeypot/Probe interacts with a receiving console (develop a VM and/or Docker based test solution to store logs from multiple probes).
  • Evaluate console options to visualise threat data received from ModSecurity Honeypots/probes in MosSecurity Audit Console, WAF-FLE, Fluent and bespoke scripts for single and multiple probes.
  • Develop a mechanism to convert from stored MySQL to JSON format.
  • Provide a mechanism to convert ModSecurity mlogc audit log output into JSON format.
  • Provide a mechanism to convert mlogc audit log output directly into ELK (ElasticSearch/Logstash/Kibana) to visualise the data.
  • Provide a mechanism to forward honest output into threat intelligence format such as STIX using something like the MISP project
  • ( to share Threat data coming from the Honeypots making it easy to export/import data from formats such as STIX and TAXII., may require use of concurrent logs in a format that MISP can deal with.
  • Consider new alternatives for log transfer including the use of MLOGC-NG or other possible approaches.
  • Develop a new VM based honeypot/robe based on CRS v3.0.
  • Develop new alternative small footprint honeypot/probe formats utilising Docker & Raspberry Pi.
  • Develop machine learning approach to automatically be able to update the rule set being used by the probe based on cyber threat intelligence received.

Getting Involved

Involvement in the development and promotion of the Web Honeypot Project is actively encouraged!

You do not have to be a security expert or a programmer to contribute.

Some of the ways you can help are as follows:

  • Coding aspects of CRS/JSON
  • Working on Component Integration
  • Deploying a Honeypot/Probe
  • Testing