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

Drupal Compromise Analysis Including Indicators of Compromise

11784_c968303e-4f94-4684-8aa7-3013638e66c2I would like to thank fellow SpiderLabs Researcher Chaim Sanders and Dennis Wilson, Bryant Smith and Casey Critchfield for their help with gathering data and analyzing this attack.

Analysis of a real Drupal compromise

In this blog post, we will walk you through a real-world compromise of a Drupal web application. This analysis will differ from our typical posts that only cover the initial phase of an exploit attempt based on data from our web honeypot deployments. Web honeypots provide a wealth of valuable information, but they do not include real, vulnerable targets for the attacker to actually exploit. In these scenarios, we usually only get to see the first phaseof an attack sequence meaning we can only observe the initial method of entry an attacker attempts to exploit.

So, from a threat intelligence research perspective the question then becomes, "How can we get visibility into the second phase of an attack beyond the initial intrusion?". We can't answer that unless:

  1. A real web application exists for the attacker to compromise, and
  2. A web application firewall (WAF) is in place in a detection-only monitoring mode. If the WAF is actively blocking attacks then the attack never proceeds to the post-exploitation phase.

The SpiderLabs Research team manages a number of out-of-line research deployments of the Trustwave Web Application Firewall (WAF) in monitoring only mode. These deployments allow us to see full inbound attacks and, more importantly, outbound web application responses. In this blog post, we will provide an analysis of an "incident" observed as the result of a research deployment to highlight some of the tools and processes SpiderLabs Research uses when investigating web application attacks.

Web Application Indicators of Compromise (IOCs)

Breach activity does not transpire in a vacuum. An attacker will interact with the compromised system and typically leave behind some sort of clues indicating some activity. These clues are commonly referred to as indicators of compromise (IOCs). Monitoring systems for indicators of compromise and responding appropriately is critical to reducing the duration and potential impact of a breach. Here is a Top 10 listing of IOCs from last year's Trustwave Global Security Report:

10725_96a5fed2-9169-443c-a1b9-6b96d94df4a3

Keep in mind that this is only a top 10 list of IOCs, and there are many indicators to consider. With these IOCs as our guide, let's start searching for signs of successful web application compromises!

IOC #1: Anomalous "admin" account activity (Drupal)

Normal Drupal Login

Here is an example of a normal Drupal log-in screen:

11264_b0db4a0d-0899-4b2d-a156-de88759118f0

In a normal, non-malicious log-in request for Drupal, this is how the resulting raw HTTP request looks:

11434_b90ca98c-5e5b-47f1-96e4-2dffba7f9709

Notice the single "name" parameter in the POST payload? That is the parameter name that maps to the "Username" parameter data in the Login UI above. This "name" parameter is the target vulnerability injection point for the attacks explained below.

Drupageddon Attack - Adding an "admin" Account

In the first step of this sequence, an attack was observed originating in California.

8214_1cc97b42-45a8-4099-b51b-8dc513d62ec7

Here is the RAW event that the Trustwave WAF generated:

7608_008000cc-b86e-4e2c-aa02-9bdabeb27697

Notice the yellow highlighted section of the POST request body. The attacker has successfully exploited the Drupageddon vulnerability by placing an SQL Injection payload within the "name[]" array contents. If you look closely at this SQL Injection payload, you will notice that the desired goal is to add and activate (by setting the "status=1" setting) a new admin account ("uid = 1") with a preset password hash. In searching the web for this specific SQL Injection payload, we were able to find a Mass Drupal Exploit php program on PasteBin:

11160_ab7a397b-0e00-41f5-8621-01f8faa36208

If we look at the source code, we can see the following data which matches up with the attack request from above:

12060_d713a3cc-7c31-4b07-a160-75a091309c4b

This sets the password hash to match "admin". Meanwhile, the WAF generated an alert that lists many different detection mechanisms:

11738_c79ebf66-c608-464f-a85e-83817646372a

It is important to note that this event consists of both anomaly-based detections and negative security signatures.

IOC #2: Unexplained or suspicious outbound data (PHP/SQL Error Messages)

Looking back at the Mass Drupal Exploit code from PasteBin, after sending the attack payload, the tool then checks the response body content to see if the SQL injection generated a specific error string:

11742_c7d677ec-9d42-439a-807f-bee49fff1413

If we inspect the HTML response data captured by the Trustwave WAF, we can see that this attack was indeed successful based on the following SQL error message data:

9660_657d91ad-1ba0-437b-99d8-94a1c1f2b608

IOC #3: Geographic anomalies in logins

After the initial Drupalgeddon exploit, the attacker then pivoted to use a different IP address from the country of Morocco to then use the new admin account and log into the Drupal site.

10056_793daf6e-fa27-4f88-a70e-e4739f32d9bd

Using multiple IP addresses during the course of an attack is a common technique used by attackers. One way to identify this type of activity is by defining Restricted GeoLocations (Country Codes) for locations you know are frequently the source of fraudulent activity or countries with which you don't typically do business. Here is a screen shot of this capability within the Trustwave WAF :

9870_6ff5d065-9b48-466c-b852-eecc5166863a

IOC #4: New and/or suspicious files dropped (webshells)

After logging into Drupal as an "admin" user, the game is essentially over as an attacker is capable of almost anything. Still, we were able to identify the next steps in this specific attack sequence. Within two minutes, the attacker initiated a series of PHP file uploads in an attempt to abuse the following "Create Book" functionality in Drupal:

10933_a06a52cd-ed1a-4f1d-8a64-56b3ef2db5b2

The key way in which the attacker abused this functionality was via the enabled "Text Formats":

9550_5f894fb9-c69b-4c78-9e2b-c0eed27134f8

Notice the highlighted sections. This interface allows admin users to post PHP code to the site. The Drupal site even lists the following warning about this feature:

10440_8976cda5-9b42-431e-bd90-f2491cc77f8e

In this case, however, if the attacker is able to exploit a vulnerability and become an admin-level user, then it is game over. The attacker was able to place PHP code for a known webshell/backdoor into the body value parameter of the form:

12077_d80c8604-1301-4fc5-a609-c5445bd61afa

This attack results in the following HTTP request as captured by the Trustwave WAF:

7626_010527b2-7492-4fab-aecc-d030a79ddc6a

Similar to the Drupalgeddon SQL Injection attack from IOC #1 above, the Trustwave WAF again generates an alert identifying this as a PHP file upload attempt:

12517_ed09b953-a693-4e9b-92a9-7f506225c122

Since the Trustwave WAF was in a monitoring-only mode, the upload attempt was successful and the attacker could access their custom PHP webshell:

10864_9d70e5b9-4ec5-458d-8327-bbeb42746f48

Upon compromising a website, attackers want to maintain access for future use. In case the web site owners happen to upgrade the system and patch the initial exploit vectors, attackers like to upload a number of webshells and/or modify legitimate PHP files to allow them to regain access. In this attack sequence, the attacker uploaded the following files:

  • up.php - an extremely small html uploader
  • 404.php - WSO webshell
  • priv8.php - boffmax v1.0 web shell by the-c0de team
  • r00t.php - webshell
  • b374k.php - a copy of the original webshell that was uploaded

IOC 5: Unexplained or suspicious file changes

The final step in this attack sequence was a web page defacement of the main index.php webpage:

9403_58470637-46b1-48ad-bbea-ee0947ed5037

The Trustwave WAF generated alerts on the inbound upload of the bogus index.php file so in a normal scenario it would have been blocked. The final IOC here would be identifying that your legitimate main "index.php" file has been overwritten with a defacement page. Another valuable feature of the Trustwave WAF is its ability to learn a response page fingerprint for each resource so that changes found within the following elements can be tracked:

11364_b558ad43-70e9-49fc-980e-7838c2ca4a6d

With this type of fingerprint tracking, it is possible to identify significant deviations from the norm (like when a page is completely overwritten with a defacement). The Trustwave WAF would then generate alerts similar to this:

10257_802f9af5-c40b-4948-bc05-6463eb026294

Take-aways

Stay current on software patches and upgrades

In this scenario, the target site was not up-to-date on Drupal software patches despite public announcement of the vulnerability in 2014. As this blog post shows, attackers are still searching for, and exploiting, vulnerable websites. In this case it was Drupal, but tomorrow it might be another application. The key is to make sure that your organization does a comprehensive software inventory, implements processes to take note of new versions and deploys patches as quickly as possible.

WAFs need to be in blocking mode

WAFs have two main functions: 1) Detection, and 2) Response. If you are using a WAF in monitoring-only mode, then you are not realizing the true value of the technology. The WAF detected each of these different exploit steps, but based on the policy did not block them. This raises a larger question of why many WAF users don't configure them in a blocking mode. 

Twenty-eight percent of organizations are not getting the full value out of their security related software investments

Here is a breakdown of different reasons why:

12911_ff93d88a-3474-4a91-8c06-ea2486f02499

Many of these challenges are what is driving more and more organizations to managed WAF services, so that they can get the most out of their WAF deployments.

Continuous Monitoring

Regardless of the WAF policy response actions, this example also demonstrates how important it is to have constant, 24x7 monitoring of your web applications. Keep in mind that this compromise (from the initial Drupalgeddon SQL Injection attack all the way through to the final web defacement) only took ~18 minutes. Do you have security personnel that are monitoring your web applications and WAF events at all times looking for these types of attacks?

Latest SpiderLabs Blogs

Hunting For Integer Overflows In Web Servers

Allow me to set the scene and start proceedings off with a definition of an integer overflow, according to Wikipedia:

Read More

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