Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
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
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
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

Setting HoneyTraps with ModSecurity: Adding Fake Cookies

8916_414fd62e-28a6-4879-adc0-71e6dd74ff78This blog post continues with the topic of setting "HoneyTraps" within your web applications to catch attackers. Please review the previous posts for more examples:
This blog post will discuss Recipe 3-5: Adding Fake Cookies from my book "Web Application Defender's Cookbook: Battling Hackers and Protecting Users". These HoneyTrap protections are also included as part of the commercial Trustwave SpiderLabs ModSecurity Rules package.

Recipe 3-5: Adding Fake Cookies

This recipe will show you how to add fake cookies and to alert if the data is ever manipulated.

Ingredients

Cookie Usage

The HTTP protocol has no built in session-awareness. This means that each transaction is independent from each other. The application, therefore, needs a method to track who a person is and what actions they have previously taken (for instance in a multi-step process). Cookies were created precisely for this purpose. The application issues Set-Cookie response header data to the client web browser. This cookie data instructs the browser to send back data to the web application on subsequent requests. For instance, upon an initial request to the Ebay main page you will receive the following response headers:

12116_da04d8cd-2e8a-41f3-befe-bbd27519e1d0

As you can see, there are six Set-Cookie response headers. When you make follow-up requests, these headers will now be included within the request headers:

9218_4eef146b-7336-4e9c-b216-ea70e795620b

Cookie Manipulation Attacks

Much in the same way that attackers take aim at parameter payloads, they also attempt to alter cookie data that is handed out by the application. Both parameter and cookie data is evaluated by the application upon each request. Cookie data may even be an even more attractive target for attackers as this information often controls authorization restrictions. If an attacker can alter cookie data, they may be able to become a completely new user, be presented with new user interface options or even gain higher privileges within the application. Due to this modus operandi of attackers, we want to set a honeytrap embedded within the normal application cookies in hopes that we will catch when attackers start to manipulate them.

Adding Fake Cookie Data with ModSecurity

Much in the same way that we added in fake hidden field honeytrap data in Recipe 3-4, we want to do the same with fake cookie data. There are two implementation considerations:

  1. When to issue the fake Set-Cookie data – we want our cookie honeytrap data to look innocuous so we only want to add it in when the application itself is legitimately issuing Set-Cookie response headers.
  2. What to name the fake Set-Cookie data – since we want our honeytrap data to blend in and look like it belongs, we should try to name our cookie something similar to existing cookie names.

The following ModSecurity/Apache directives addresses these two considerations:

8903_40a64470-4ccd-4ed7-bb89-4058dada4a0a

These rules will capture the name of the last Set-Cookie header and then append the "-user_role" text to it. This is to try and trick the attacker into thinking that this cookie is controlling the user's role within the application. For the cookie payload, we put the enticing "Admin:0" data which would lead the attacker into thinking that by changing the 0 into a 1 might enable administrative privileges within the application. With these rules in place, the new response header data looks like this:

12616_f117646e-59ff-4e71-9763-cbf50a5a19ee

Notice the bolded Set-Cookie response header line holds our new honeytrap cookie data. Next, on subsequent requests, the client's browser will send back our fake cooke data along with all of the normal cookies:

10685_949d7cfd-f333-49c5-874c-ee6048a9b9a7

Detecting Cookie Manipulations

We next need to add a rule that will catch if the client ever changes this cookie data.

11672_c4f28513-f6d2-4746-b369-fcc4728e879a

This ruleset will check to see if the honeytrap cookie name is present and then will alert if the "Admin:0" value is ever altered. It will also set the malicious_client variable in the IP Collection to let us know that this client is up to no good.

Example Attack

In this example, the attacker has decided to change the honetrap cookie value from a 0 to a 1 in the hopes that this might change their level of access:

10988_a308004f-36d5-4a55-b508-84de0a82be0a

This request would then trigger the following ModSecurity event in the normal error log:

9301_5320532c-241f-4879-947a-3016ea1218e1

Conclusion

HoneyTraps are an extremely valuable defensive technique to use when defending your web applications. They offer a very high signal-to-noise ratio and allow defenders to quickly zero in on real attackers and take appropriate actions. Setting fake cookie data is a great way to identify malicious clients.

Latest SpiderLabs Blogs

Secure Access Service Edge: Another Multi-Tool for the SOC

Over the years, several security defense architectures have merged into a single solution. Endpoint detection tools can perform sophisticated detections and correlations that used to require a...

Read More

Search & Spoof: Abuse of Windows Search to Redirect to Malware

Trustwave SpiderLabs has detected a sophisticated malware campaign that leverages the Windows search functionality embedded in HTML code to deploy malware. We found the threat actors utilizing a...

Read More

The Sentinel’s Watch: Building a Security Reporting Framework

Imagine being on shift as the guard of a fortress. Your job is to identify threats as they approach the perimeter. The more methods you have for detecting those threats, the better your chances of...

Read More