Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. 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
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 HTML Comments

image from ecx.images-amazon.comThis 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-3: Adding Fake HTML Comments from my book "Web Application Defender's Cookbook: Battling Hackers and Protecting Users".

Recipe 3-3: Adding Fake HTML Comments

This recipe will show you how to add fake HTML comment data that may be flagged if ever accessed or used by a client.

Ingredients

HTML Comments

The Hypertext Markup Language provides a syntax which allows developers to embed comment information within the html code. The HTML RFC states the following:

3.2.4 Comments

HTML comments have the following syntax:

<!-- this is a comment -->

<!-- and so is this one,

which occupies more than one line -->

White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments.

Information that appears between comments has no special meaning (e.g., character references are not interpreted as such).

Note that comments are markup.

While the intended purpose of this functionality is to be helpful, it often divulges sensitive data. Let's look at a practical example.

During the reconnaissance phase, an attacker will most likely run an automated spidering tool against the site. They can then review various elements of the site off-line and look for pieces of sensitive information. For example, Figure 3-1 shows the Burp Suite Pro application assessment tool.

8426_28ae6221-191c-4f14-8042-d9d0567b8648

Figure 3-2: Burp Suite's Engagement Tool Find Comments

This screenshot demonstrates how to use the find comments action of the engagement tools interface. This will search through any saved HTTP transactional data. Figure 3-2 shows some example output with various html comment data.

10299_8294db95-517a-46b9-9b84-e96aa336ad46

Figure 3-3: Burp Suite's Find Comments Search Results

While the html comments show here are rather innocuous, there are other examples that are not. Figure 3-3 shows an example where the web developer has decided to place stack trace debugging information within the html comments.

8203_1c3a60fe-0ce2-4984-8aff-95e240b5c782

Figure 3-4: Stack Trace Data Inside HTML Comment

This information should never be sent to a client as it exposes the inter-workings of the application. With this data, an attacker may be able to better plan and execute attacks against your web application.

Adding Fake HTML Comments with ModSecurity

Building upon the configuration in the Adding Fake robots.txt Entries configuration, we can add another ModSecurity directive called SecStreamOutBodyInspection:

SecContentInjection OnSecStreamOutBodyInspection On

This directive will place the normal RESPONSE_BODY variable data (HTML) into a re-allocatable buffer which allows us to modify and re-inject this buffer back into the response body stream. In layman's terms, this directive allows us to be able to modify outbound response data.

Now that we have the capability to dynamically insert our own data, we need to choose a good location to deploy our honeytrap HTML comment. An ideal candidate is to seed any login pages with this fake data as attackers are sure to focus their attention in this location. Figure 3-4 shows the html for an example login page.

8154_19fb9ff9-f847-45ae-96a7-8140aa23b03b

Figure 3-5: Example DVWA Login Page HTML

Note the highlighted FORM tag data in the html source code? That is going to be our key data element to use as our injection point. We can then use the following ruleset to insert out honeytrap html comment data directly in front of the open FORM tag:

SecRule REQUEST_FILENAME "@streq /dvwa/login.php" "chain,id:'999007',phase:4,t:none,nolog,pass,setvar:'tx.form_comment_honeytrap=<form action=\"login.php\" method=\"post\">'"       SecRule STREAM_OUTPUT_BODY "@rsub s/%{tx.form_comment_honeytrap}/<!-- DEBUG - the source code for the old login page is login.php.bak -->%{tx.form_comment_honeytrap}/d"

The key piece of data to focus on is in the second SecRule where the @rsub operator is using macro expansion to do our data substitution and prepending our honeytrap comment information. With this rule in place, Figure 3-5 shows how the new html data looks.

8732_371f8d85-49bf-4a42-b8d6-77a821a20b3c

Figure 3-6: Fake HTML Comment Data

Now that we have set our trap, we must create a separate ModSecurity rule that will identify if a client ever attempts to access the fake login.php.bak page.

SecRule REQUEST_FILENAME "@streq /login.php.bak" \  "id:'999008',phase:1,t:none,log,block,msg:'HoneyTrap Alert: Fake HTML Comment Data Used.',setvar:ip.malicious_client=1"

If this alert ever triggers, you know that the client is reviewing HTML source code and inspecting comment data. You can then choose how to react to client based in this intel. In the example rule, we are setting a new local variable "malicious_client" to the IP-based persistent storage collection. This flag will allow you react as you want whenever the client returns to the site. Perhaps you want to simply create audit logs of this user's activities or optionally proxy their connections off to some other honeypot web application. The response actions are varied however the key is that you were able to use this honeytrap to identify the suspicious disposition of this user.

Conclusion

Hopefully this blog post has give you ideas on how you might implement similar types of fake HTML comments to entice and track would-be attackers on your site. Make sure to use variation in the types of data that you use in your honeytraps so that it will not be easy to identify. Examples can include:

  • HTML comments contained links to hidden (unlinked) directories
  • Backup files (e.g. - with .orig extensions)
  • Authentication credentials for a test or debug account. Don't laugh. We have seen this more than once...
Good luck combating attackers on your site!

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More