Trustwave SpiderLabs Uncovers Critical Cybersecurity Vulnerabilities Exposing Manufacturers to Costly Attacks. Learn More

Trustwave SpiderLabs Uncovers Critical Cybersecurity Vulnerabilities Exposing Manufacturers to Costly Attacks. Learn More

Managed Detection & Response

Eradicate cyberthreats with world-class intel and expertise

Managed Security Services

Expand your team’s capabilities and strengthen your security posture

Consulting & Professional Services

Tap into our global team of tenured cybersecurity specialists

Penetration Testing

Subscription- or project-based testing, delivered by global experts

Database Security

Get ahead of database risk, protect data and exceed compliance requirements

Email Security & Management

Catch email threats others miss with layered security & maximum control

Co-Managed SOC (SIEM)

Eliminate alert fatigue, focus your SecOps team, stop threats fast, and reduce cyber risk

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
The Trustwave Approach
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Platform
SpiderLabs Fusion Center
Security Operations Centers
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Detecting Malice with ModSecurity: HoneyTraps

This week's installment of Detecting Malice with ModSecurity will discuss how to implement HoneyTraps in order to detect malicious activity on your website. HoneyTrap excerpt section of Robert "Rsnake" Hansen's book "Detecting Malice" -

Booby Trapping Your Application

I briefly mentioned honeytokens in a previous chapter, but there are lots of other tools available to the paranoid, you just haven't built them yet. Bad guys follow a certain set path of tricks, and if you can anticipate those, there's a good chance you can catch one in the act. Creating fake cookies that look particularly tempting like "admin=false" is a great way to detect that someone is tampering with cookies and trying to gain higher privileges. Think of this as the application equivalent of a honeypot – you don't want to make yourself hack-able, and you may not care about robots, but you probably care a lot about bad guys manually hacking your website. This too may alert a bad guy to the fact you are monitoring them, so use techniques like this sparingly.

Other ideas that are less likely to let an attacker know they are being tracked might revolve around creating admin directories on your server that have login pages that cannot log the person in, but instead simply monitor what the user is doing. These kinds of tricks can cost you development time, but the nice thing is it can often help locate people who are simply out to hack you. While this is sort of the virtual equivalent of entrapment in some ways, users should never inadvertently tamper with cookies, or try to hack an admin login page, so creating a function that is specifically designed to never be touched or tampered with by any normal user will reduce the operational overhead of looking at the traffic to those functions. You'll find yourself looking at the worst of the worst. The goal here is not to take direct action but to begin monitoring everything that user does – these are the bad guys and you want to keep your eye on them.

Use these ideas, and create your own. The more false paths you create for your determined bad guys, the more likely it is that you can identify them and identify if they have caused any other types of harm on your site. Who knows, you may even be able to mitigate the risk of an attack that might end up working eventually, like brute force, if you proactively identify a malicious user before it is too late.


OWASP AppSensor Detection Points - HoneyTraps

We recently added new AppSensor HoneyTrap Detection Points. Example:

Honey Trap

HT1: Alteration to Honey Trap Data




Alteration to Honey Trap Data




Fake (not otherwise needed by the application) data sent to the user and returned (e.g. as form, URL, cookie values or in the path or HTTP header) is modified. This is usually combined with making the name or value a tempting item for an attacker to try modifying.


Similar techniques can also be used for the creation of accessible CAPTCHA.

See also ideas at


Example 1: Otherwise useless hidden fields, which look like potential vulnerabilities, added to some forms are sent back to the server modified (e.g. <input type="hidden" name="admin" value="false" />).

Example 2: An additional URL parameter, which is not used by the application, is modified by the user (e.g.

Example 3: An additional fake cookie is added and is modified by the user.

Example 4: URL rewriting is used and a fake directory name is added; this is modified by the user (e.g.


[Java] [.Net] [PHP]

OWASP ModSecurity Core Rule Set (CRS) HoneyTrap Example

We recently added an example HoneyTrap rules file to the CRS which implements a fake debug HIDDEN form field parameter.

## -=[ HT1: Alteration to Honey Trap Data ]=-## - #SecRule ARGS:DEBUG "!@streq false" "phase:2,id:'981131',t:none,block,msg:'Tampering of Hidden Parameter Honeytrap Data.',logdata:'%{matched_var}',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.error_anomaly_score},setvar:tx.profiler_score=+%{tx.error_anomaly_score},tag:'HONEYTRAP/HIDDEN_DATA_TAMPERING',tag:'OWASP_AppSensor/HT1',tag:''"## Add a fake "debug" hidden parameter to forms.## Here are some examples of parameter names/values that could be used:## - debug=false# - debug=0# - role=user# - role=1# - admin=false # - admin=0## Make sure that your settings here match the detection rules above.#SecRule STREAM_OUTPUT_BODY "@rsub s/<\/form>/<input type=\"hidden\" name=\"debug\" value=\"false\"><\/form>/" "phase:4,id:'981132',t:none,nolog,pass"

This example ruleset uses the ModSecurity @rsub data modification operator to inject our new HIDDEN form field data right before the closing HTML </form> tag. The result of this ruleset is that the page form will now include a new parameter "debug=false" when sending data to the app. The SecRule at the beginning of the file then validates that the debug parameter value is always set to "false". If not, then this means that a client has manipulated this HIDDEN parameter value and is most likely attempting some type of bypass attempt.


This is just one example of implementing the HoneyTrap concept within ModSecurity. We have plans to implement many more in the near future. If you have any ideas, please let us know. If you are attending DefCon in Las Vegas this week-end, and you like the HoneyTrap concept, then I suggest you attend "Traps of Gold" which is being presented by a SpiderLabs colleague Andrew Wilson.




Latest SpiderLabs Blogs

Trustwave SpiderLabs Report: LockBit 3.0 Ransomware Vs. the Manufacturing Sector

As the manufacturing sector continues its digital transformation, Operational Technology (OT), Industrial Control Systems (ICS), and Supervisory Control and Data Acquisition (SCADA) are becoming...

Read More

Overview of the Cyberwarfare used in Israel – Hamas War

On October 7, 2023, the Palestinian organization Hamas launched the biggest attack on Israel in years, resulting in numerous casualties and hostages taken. Israel responded with a large-scale ground...

Read More

The 2023 Retail Services Sector Threat Landscape: A Trustwave Threat Intelligence Briefing

The annual holiday shopping season is poised for a surge in spending, a fact well-known to retailers, consumers, and cybercriminals alike. The latter group, however, is poised to exploit any...

Read More