Skip to Main Content
All Trimarc services are now delivered through TrustedSec! Learn more
October 10, 2025

Skimming Credentials with Azure's Front Door WAF

Written by @ nyxgeek
Cloud Penetration Testing

Table of contents

A Web Application Firewall (WAF) is a powerful thing. It inspects all traffic that traverses it, seeing everything that is submitted to a page. EVERYTHING.

Figure 1 - Behold the Power of WAF

Today we’ll demonstrate how an attacker could use access to the Front Door WAF in Azure and Log Analytics to skim credentials from a site that the WAF is protecting.

By creating a custom rule to match logon events, we can capture both usernames and passwords in cleartext as they make their way through the WAF.

Figure 2 - Of Course!

How it Works

The Azure Front Door WAF allows you to create custom rules. These rules can match on specific IPs, headers, body content, and POST parameters.

Figure 3 - Match Selections

If we create a Custom Rule that matches on POST parameters 'username' and 'password' for any values, and we set the rule to 'Log traffic only', we'll quietly send people's usernames and passwords to our logs.

Figure 4 - Logging Only

Demonstration

Sounds great in theory – let's prove it!

WAF Setup

Here is the logon page for Acme Computer Company. It is protected with the Azure Front Door WAF.

Figure 5 - Example Logon Page

Note: This attack does not work against the Application Gateway WAF. It will only work with the Front Door WAF for reasons I'll explain later.

If we examine the HTML source, we see that it POSTs two parameters: username and password. We'll make a note of that for later.

Figure 6 - POST Parameters

Logging Setup

Next, make sure that logs are set up to flow from the Front Door WAF to your Log Analytics workspace. To do this, go to 'Diagnostic setting' under the Monitoring header on the left side of the Azure portal. If it's blank, select 'Add diagnostic setting' and configure it like the screenshot below.

Figure 7 - Enabling Logging

We only truly need the 'FrontDoor WebApplicationFirewallLog' category.

Adding a Malicious Rule

To start skimming passwords, we'll first create a new custom rule in our Front Door WAF. Let's call it something innocuous, like 'PasswordCapture'. Set the Priority to something low, like 5.

Figure 8 - Creating a Custom Rule

This will make sure it is evaluated before any other rules that might block or allow traffic. (Don't worry – those other rules will still be evaluated, as I'll explain later.)

Next, configure the If condition to match on POST arguments identified earlier -- 'username' and 'password'. For these, we set our Operator to the 'Any' value. This will match any values for username or password. Configure the Then portion to 'Log Traffic Only'.

Figure 9 - Custom Rule Configuration

Click 'Add' at the bottom. You should now see your new Custom Rule in the list, with an action of 'Log'.

Figure 10 - New Rule Created

Click 'Save' to complete the change.

It is worth noting that usually, once a rule is matched, the WAF stops evaluating other rules. However, since our rule is set to 'Log' only, the other rules still get evaluated.

Generating an Event

Normally we would just wait for our users to log in. However, this time we'll perform that action ourselves.

Here, we can pretend to be a normal user logging in via a browser.

Figure 11 - Performing Logon

And for demonstration purposes, we'll show it as a curl request, with the POST parameters highlighted:

Figure 12 - Logon as Curl

Let's Farm Some Loot!

After collecting some logon events, it's time to reap our rewards!

Go to your Log Analytics workspace for the WAF. Select 'Logs' on the left.

Figure 13 - Log Query Lookup

In the upper-right corner, switch it from 'Simple mode' to 'KQL mode':

Figure 14 - KQL Mode

Now enter the following query. If you named your rule something other than 'PasswordCapture', enter that instead.

AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
  and ruleName_s == "PasswordCapture"
| project TimeGenerated,  ruleName_s, details_matches_s
| order by TimeGenerated desc

This should result in a listing of recent traffic that matched our rules for containing a 'username' and 'password' POST. Expand the details, and you'll see the username and password revealed.

Figure 15 - Query Results

I should note that during normal WAF operations, it is possible to protect sensitive data from appearing in fields, using Azure's data-scrubbing feature. I recommend that admins include a filter for password fields at the least.

Figure 16 - Sensitive Data Masking

What are the Prereqs for this Attack?

To pull off this attack you'll need a few things:

  • Azure Front Door WAF
  • Protecting a logon page
  • Access to modify the Custom Rules for the WAF
  • Access to Log Analytics workspace for the WAF

Let's take a more in-depth look at each of these requirements.

1. Azure Front Door WAF

As mentioned, this attack only works with Front Door WAF, not with Application Gateway WAF. The logs for the Front Door WAF are very verbose and show the matching pattern. The Application Gateway logs for Custom Rules only show what rule was matched but not the offending content.

Figure 17 - Application Gateway Firewall

The curious thing is, the values will still show up in the logs if they are matched by a Managed Rule like the OWASP SQLi rules. We just can't force the Application Gateway WAF to give up its secrets directly.

Figure 18 - Application Gateway Firewall Results

2. WAF Protecting a Logon Page

Now for the second of these requirements – the logon page – something worth capturing. If a company is protecting a site with a WAF, it's probably because the site takes user-supplied input and has dynamic pages. This is not always the case, but often it is. Why put a big fancy WAF in front of a static page? There's a decent chance that if Front Door is being used at all, it's being used with a site that takes logon data.

3. Access to Modify WAF Custom Rules

The following subscription-level roles will have access to update custom rules:

  • Owner
  • Contributor
  • Network Contributor

4. Access to Read Log Analytics Workspace

In order to read a Log Analytics workspace, you will need any of the following roles assigned at the Subscription, Resource Group, or the Log Analytics workspace itself:

  • Owner
  • Contributor
  • Reader
  • Log Analytics Contributor
  • Log Analytics Reader
  • Monitoring Reader
  • Monitoring Contributor
  • Monitoring Policy Contributor

Conclusion

I stumbled upon this idea while I was trying to solve false-positives from the Azure WAF. It would keep picking up passwords with certain strings and special characters as potential SQLi.

While this has been demonstrated with the Azure Front Door WAF, the general approach might also be applied to other products. We aren't limited merely to usernames and passwords. We can also be on the lookout for API keys and bearer tokens that are passed in headers.

I guess the important takeaway from this is: be careful who you let inspect plaintext network traffic, and be careful who is allowed to read your logs. While this configuration was intentionally evil, I have seen many passwords accidentally captured by a WAF during normal operations.