Part 4 - Data Disclosure and Exfiltration Playbook: Azure WAF Security Protection and Detection Lab
Published Feb 11 2021 01:27 PM 5,114 Views




Tutorial: Data Disclosure and Exfiltration Playbook




The last tutorial in this four-part series for Azure WAF protection is the data exfiltration playbook.  The purpose of the Azure WAF security protection lab is to demonstrate Azure WAF's capabilities in identifying and protecting against suspicious activities and potential attacks against your web applications.  This playbook explains how to test Azure WAF's protections against a SQL Injection (SQLi) attack with emphasis on Azure WAF protection ruleset and logging capabilities.  The lab does not include advanced application security concepts and is not intended to be a reference for application security testing as these areas are broader than the use cases demonstrated herein.


This playbook demonstrates the protection capabilities of Azure WAF against a simulated SQL Injection attack from common, real-world, publicly available hacking and attack tools.


In this tutorial you will:

  1. Simulate SQL Injection (SQLi) attack against the target OWASP Juice Shop application directly and then attack the same instance of the web application published through Azure WAF
  2. Observe the difference in the web application behavior in the two scenarios
  3. Review the summarized logs in the WAF Workbook (Azure Monitor Workbook for WAF)





  1. A completed Azure WAF security lab setup
    • We recommend following the lab setup instructions as closely as possible. The closer your lab is to the suggested lab setup, the easier it will be to follow the Azure ATP testing procedures.
  2. Completion of the reconnaissance playbook tutorial
  3. Completion of the vulnerability exploitation playbook tutorial



Configuring Burp Suite and Firefox


Before you being, please refer to the Configuring Burp Suite and Firefox section in the previous tutorial, Vulnerability Exploitation Playbook to setup Burp Suite and the Firefox web browser on the Kali VM.



Sensitive Data Exposure and Exfiltration


In this phase, the attacker is ready to use a vulnerability they have previously discovered, tested, and developed further to achieve their objective to access and exfiltrate data.  In this playbook, we will perform a SQL Injection attack to disclose and then exfiltrate the list of all user credentials in the OWASP Juice Shop application.



Performing SQL Injection against the Target Web Application


In this tutorial, you will perform a SQL Injection (SQLi) attack against the OWASP Juice Shop application two times. 


  1. Scenario 1: Performing SQL injection in the target web application directly
  2. Scenario 2: Performing the same injection in the same target web application protected by Azure WAF on Application Gateway



Scenario 1:  Performing SQL Injection when going to the OWASP Juice Shop Application directly


  1. Sign into the Kali VM using your lab credentials
  2. Launch Burp Suite and ensure you have Burp Suite configured and running as described in the Configuring Burp Suite and Firefox section of the Vulnerability Exploitation Playbook
  3. Using Firefox, browse directly to the Juice Shop site by going to http://owaspdirect-<deployment guid>
  4. In Burp Suite, check the Proxy --> HTTP history tab for the request and response data for this website
  5. In the search bar on the Juice Shop website, type "apple" and examine the request and response in Burp Suite



! IMPORTANT:  For the scenarios demonstrated in this document, OWASP Juice Shop application was running on HTTP port 3000.  This is not the case when you use the Azure WAF Attack Testing Lab Deployment Template as it configures the application to run on port 80, 443 and assigns it a URL.  For the lab tutorials, you will connect to the application on HTTP port 80 only.  The URL for the application will be http://owaspdirect-<deployment guid>  <deployment guid> is unique to every deployment


  1. We see that when searching, the client makes a connection to the /rest/products/search endpoint




  1. The /rest/products/search endpoint of the OWASP Juice Shop application is vulnerable to SQL injection.  In this tutorial, we will be exploiting the SQLi vulnerability in this endpoint
  2. To exploit the SQLi vulnerability in the /rest/products/search endpoint, we will use Burp Suite's Repeater functionality to inject a specifically crafted SQL query in the request to this endpoint
  3. To do this, right click one of the GET requests to the /rest/products/search endpoint and then click Send to Repeater


Figure 1 - Send Request to Burp Repeater



Figure 2 - Request in Burp Repeater



  1. When ready to perform the injection, we will copy/paste and append the following encoded SQL query to the Request URI /rest/products/search?q= (as value to the query parameter) in the Burp Repeater window


a. URL encoded SQL query






b. Plain text SQL query (for reference)



qwert')) UNION SELECT id, email, password, '4', '5', '6', '7', '8', '9' FROM Users-- 



  • Tip: You can also append the plain text SQL query to the request URI, but it may fail in certain conditions


  1. After appending the encoded query to the request URI, as value to the to the query parameter, click Go (or Send button)




  1. You should see a successful response from the OWASP Juice Shop application with details of all the users and their credentials disclosed by the web application.  This indicates that our SQL injection attack was successful




JSON data in the response body






  • Tip:  Data in the "Description" field in the server response is the password hash of the users which can be reversed using free tools available on the internet



Scenario 2:  Performing SQL Injection when going to the OWASP Juice Shop Application through Azure WAF


You will now attempt to perform SQL Injection with the same query when going to the OWASP Juice Shop site through Azure WAF.


  1. On Kali VM, launch a new instance of Burp Suite and the Firefox browser
  2. Using Firefox, browse to and check the Proxy --> HTTP history tab for the request and response data for this website in Burp Suite




  1. Search for "apple" in the search bar, find the request to the vulnerable /rest/products/search endpoint and send it to the Burp Repeater


Send Request to Burp Repeater



Request in Burp Repeater



  1. Append the encoded SQL query (from Step 10 in Scenario 1 above) as value to the query parameter in the Burp Repeater and click Go (or Send)




  1. Upon examining the response, we find that the request was blocked by Azure WAF on Application Gateway





Understanding What Happened


Upon reviewing the HTTP requests and responses for the two attempts to perform SQL Injection in the same instance of the Juice Shop application, we see the pattern as shown in the below table.  This clearly indicates that the potentially malicious payload which could otherwise be stored in the application is not allowed through by Azure WAF.


SQL Injection Route




Through WAF



Now let us use the Azure Monitor Workbook for WAF to understand how the WAF handled traffic with the SQL Injection query.  This workbook visualizes security relevant WAF events across several filterable panels.  It works with all WAF types, including Application Gateway, Front Door, and CDN, and can be filtered based on WAF type or a specific WAF instance.


Click here to deploy Azure Monitor Workbook for WAF to your subscription in Azure.


  • Tip:  To understand what is happening when traffic with SQL Injection query destined for the Juice Shop application goes through the Azure WAF, you can also examine the log entries associated with ApplicationGatewayFirewallLog in the Azure Monitor



Reviewing WAF logs in the Workbook


  1. You can access the WAF workbook by going into the Workbook blade and then selecting the WAF workbook deployed for this testing.  Once in the workbook, ensure that you have selected the appropriate Time Range, WAF Type and WAF Items




  1. You should also ensure that you have selected the correct Public IP address for your attacker machine (Kali VM) in the Top 10 Attacking IP Addresses, filter to single IP address pane


  • Tip:  If you are using the Azure WAF Attack Testing Lab Environment Deployment Template and have followed the lab setup instructions then the client IP address will be the public IP address of the Azure Firewall in your demo environment




  1. After selecting the correct client IP, we scroll back up to the top of the Workbook and review the visualizations at the top, in the WAF Workbook.  Below are the sections of the workbook we will be using as numbered in the below figure


a. WAF actions filter

b. Top 40 Blocked Request URI addresses, filter to single URI address

c. Top 50 event trigger, filter by rule name

d. Message, full details



Note:  For a detailed overview of these sections of the WAF workbook, please refer to the Overview of the Workbook Sections in the prior tutorial, Reconnaissance Playbook


  1. From the sliced data in the WAF workbook, we can see that two requests to the /rest/products/search URI were blocked by WAF.  Upon reviewing the Top 50 event trigger, filter by rule name we see all the rules which evaluated the POC code in the request, the Message, full details section shows that the traffic was blocked by Mandatory rule because the Anomaly Score threshold was exceeded (Total Score: 43, SQLi=43) with SQL Injection attack being the closest match
  2. The below table shows an extract of the Top 50 event trigger, filter by rule name output for scanner traffic.  This data shows that the WAF evaluated the encoded query in the HTTP request to detect that it was a SQL injection attack and therefore blocked it




SQL Injection Attack Detected via libinjection


Detects MSSQL code execution and information gathering attempts


Looking for basic sql injection. Common attack string for mysql, oracle and others.


Detects MySQL comment-/space-obfuscated injections and backtick termination


Detects basic SQL authentication bypass attempts 2/3


Detects classic SQL injection probings 1/3


Detects classic SQL injection probings 2/3


SQL Injection Attack


Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)




Key Takeaway


SQL Injection (SQLi) is one of the most common type of application security vulnerability which allows an external adversary to exploit a vulnerable application to disclose and exfiltrate sensitive information in the application.


For web applications secured with it, Azure WAF can protect against SQL Injection (SQLi) attacks by detecting and blocking suspicious SQL queries at the network edge, with its out of the box ruleset.




Previous: Vulnerability Exploitation Playbook





Version history
Last update:
‎Feb 09 2021 12:16 PM
Updated by: