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

WASC Distributed Web Honeypots Project Update

As the WASC Distributed Web Honeypots Project Sponsor, we are excited to announce that we have officially launched the next phase of the project! If you would like to participate, please read below.

Project Overview

The goal of the Distributed Web Honeypot (DWH) Project is to identify emerging attacks against web applications and report them to the community. This may include automated scanning activity, probes, as well as, targeted attacks against specific web sites or applications. The scope of this project has recently been expanded to include deployment of both standard web application honeypots and/or open proxy honeypots. Project participants may choose whether they want to run their honeypot as an open proxy or a stand-alone sensor.

Project Leader

If you would like to be involved with the project, please contact the project leader - Ryan Barnett (rbarnetttrustwave.com).

Why are you doing this?

Web attacks are increasing at an alarming rate. There are constant news stories of web application breaches; however there is normally not much technical information as to what vulnerabilities were exploited. See the WASC Web Hacking Incident Database (WHID) for data. Without knowing how the attackers were able to compromise the web site, we do not know how to protect our web applications. This is one of the main goals of this project - to provide technical details about web-based attack vectors. This project aims to answer the following types of questions:

  • What web applications are the bad guys targeting?
  • Are they using new tools or techniques?
  • Is there a new worm out on the web that is mass rooting websites?

How did you configure this web honeypot?

The new WASC web honeypot architecture is setup with the following:

  1. ModSecurity web application firewall engine.
  2. OWASP ModSecurity Core Rule Set (CRS).
  3. Centralized logging of the ModSecurity audit_log data with the mlogc program along with the Trustwave SIEM and the ModSecurity Audit Console.
8906_40bedec9-0e83-4db6-b9e9-b687dc1bfb83



Are there any legal issues I should be concerned with?

The short answer is yes - if you choose to run your honeypot as an open proxy server. There are some legal issues to be aware of in this type of honeypot setup where we will be capturing third party user information. The Honeynet Project has excellent information on the challenges and issues surrounding due diligence in deploying honeypots/honeynets. Refer to this paper on Honeynets. In their book Know Your Enemy they have an entire chapter dedicated to Legal Issues. It is this concern over increased risk why we expanded the project scope to allow for deployment of stand alone web sites instead of running it as an open proxy.

Should I run this on my production environment?

That depends on your risk tolerance and whether or not you want to run the honeypot as an open proxy. If your organization is willing to approve it, then the program itself is a virtual host and will run under any host that runs VMware. We have many varied organizations participating ranging from universities, ISPs and government networks.

Can I run the sensor at home?

Sure, many participants are running the sensors from their home network. You shoud, however, consult your ISP's AUP info before deploying any web servers. There may be conflicts with your ISP allowing inbound HTTP traffic however the honeypots are pre-configured to listen on common proxy ports including 8000, 8080 and 3128.

Should I announce the honeypot IP address on public lists?

That is up to you however be aware that if the sensor IP address becomes posted to pubic open proxy lists that more than likely your sensor will become flooded with SPAMMER traffic.

What prerequisites do I need to participate?

An understanding of ModSecurity functionality will help to understand the rules and logs being generated. Review the following:

How to Participate

There are two ways to participate:

  1. Deploy a honeypot sensor

You can participate by deploying the WASC Web Honyepot sensor on your own network. WASC has created a VMware image of the standard sensor. This image includes all of the software to quickly get your sensor up and running with little configuration on the end user's part. You must contact the project leader via email in order to participate. You will then recieve the link location to download the VMware image. You will need to have the free version of VMware player or Server. If you would like to deploy a honeypot sensor, include the following details in your email to the project leader:

  • Sensor Point of Contact (POC) name
  • Source IP address that the logs will be coming from
  • Geographic location (Country, State, Locality)
  • Network Block Owner

The Project Leader will send back an email with instructions for downloading the VMware honeypot image data and the OS root credentials. The VMware host is configured with dhcp, so after you login, verify that the host has successfully obtained an IP address. The Project Leader will also provide you with the ModSecurity log agent credentials you will need to authenticate when sending your log data. ModSecurity uses a C program called mlogc located in the /usr/local/apache/conf/ directory. This program will take the data generated by the ModSecurity concurrent audit log and uses HTTP PUT requests to upload the individual audit_log files to the central console host. Each WASC honeypot sensor will have a unique username/password combination. The file that you will need to update is /opt/wasc-honeypot/etc/mlogc.conf. The final step is to start up the apache web server - /etc/init.d/wasc-honeypot-ctl.sh start. You should then review the log files to ensure that they everything is working properly.

  1. Data analysis

Even if you do not deploy a honeypot sensor, we need help with data analysis for the capture traffic. We will provide access to the ModSecurity AuditConsole web interface to all project participants. The AuditConsole has built in searching and reporting functions that may be used for batch analysis. We will provide all project participants with a reporting procedure so that we have a consistent process for vetting data prior to releasing to the public.

 

 

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