Protect Exchange OWA from Brute Force Attacks with reCAPTCHA

Prerequisites

Before touching any Exchange files, confirm you have everything on this list:

• Administrative access to the Exchange Server (every server carrying the Client Access Server role in multi-server environments)
• A Google account your team controls, used to register the reCAPTCHA site
• Notepad or any plain-text editor available on the Exchange Server
• Your Exchange Server's public OWA hostname (for example, mail.yourdomain.com)
• IIS installed on the Exchange Server (standard with all modern Exchange versions)
• A backup plan - confirm you can restore logon.aspx before you start editing

Why Does Exchange OWA Need reCAPTCHA?

Exchange Server has appeared approximately 16 times on CISA's Known Exploited Vulnerabilities catalog since 2021, with 12 of those vulnerabilities deployed in active ransomware campaigns. A joint NSA/CISA advisory (via MessageWare) states that Exchange environments "should be considered under imminent threat." OWA login pages sit on the public internet in most deployments, making them easy targets for automated bots.

CAPTCHA-based bot detection addresses a real, measurable problem. Auth0 (Okta) research shows that CAPTCHA mechanisms reduce bot attacks by 79% while adding friction for fewer than 1% of legitimate human users. For Exchange OWA specifically, reCAPTCHA v2 blocks automated submissions before any credential reaches the authentication stack.

Breaches that do succeed through stolen credentials are expensive. IBM's 2024 Cost of a Data Breach Report found that credential-based breaches took an average of 292 days to identify and contain - the longest of any attack vector - at an average cost of $4.81 million per breach. A free reCAPTCHA integration is a practical first layer of defense. For broader threat context, see how attackers gain footholds in Mistic Backdoor: KongTuke Access Broker Fuels Ransomware and how phishing complements credential attacks in Callback Phishing via Shop App: Fake Receipts Target 875M Users.

How Do You Register a Google reCAPTCHA v2 Site?

Get your site key and secret key before touching any Exchange files. Navigate to the Google reCAPTCHA admin console and sign in with the Google account your team controls. Refer to the Google reCAPTCHA developer documentation for the full registration reference.

Fill in the registration form with these exact values:

• Label: Exchange Server (or any descriptive name your team will recognize)
• reCAPTCHA type: reCAPTCHA v2 - "I'm not a robot" tickbox
• Domains: your Exchange OWA hostname (for example, mail.yourdomain.com) and localhost
• Accept the Terms of Service and opt in to owner alerts

Click Submit. Google displays a Site Key and a Secret Key immediately. Copy both into a secure temporary location - you need them in the next two steps.

Adding localhost to the domain list is intentional - it allows you to test OWA and ECP directly from the server console without the widget breaking on local URLs.

How Do You Create the reCAPTCHA Validation Page?

Repeat this step on every Exchange Server that carries the Client Access Server role. The validation page acts as a server-side proxy: when a user submits the login form, the client-side script calls this page, which forwards the reCAPTCHA token to Google and returns the result.

Open File Explorer and go to the OWA auth directory. The path depends on your Exchange version:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

C:\Program Files\Microsoft\Exchange Server\V14\FrontEnd\HttpProxy\owa\auth

Create a new file named recaptcha.aspx in that folder using Notepad. Paste the code below, replacing YOUR_SECRET_KEY with the Secret Key you copied from Google:

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Net" %>
<%@ Import Namespace="System.IO" %>
<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        string secretKey = "YOUR_SECRET_KEY";
        string response = Request.QueryString["response"];
        string url = "https://www.google.com/recaptcha/api/siteverify";
        string postData = "secret=" + secretKey + "&response=" + response;

        WebClient client = new WebClient();
        client.Headers[HttpRequestHeader.ContentType] = "application/x-www-form-urlencoded";
        string result = client.UploadString(url, postData);
        Response.Write(result);
    }
</script>

Save the file. The page forwards the user's reCAPTCHA token to https://www.google.com/recaptcha/api/siteverify and writes Google's JSON response back to the caller.

How Do You Back Up and Modify logon.aspx?

Always back up `logon.aspx` before editing it. Copy the file in the same directory and rename the copy logon.aspx.bak. Each CU overwrites logon.aspx, so this backup is your fast-restore option if something goes wrong mid-change.

Open the original logon.aspx in Notepad. Three targeted edits follow.

Edit 1: Load the reCAPTCHA API Script

Find the closing </head> tag. Insert the Google reCAPTCHA script reference immediately before it:

<script src="https://www.google.com/recaptcha/api.js" async defer></script>

This loads the reCAPTCHA JavaScript library from Google's CDN when the login page opens. The async defer attributes prevent it from blocking page rendering.

Edit 2: Insert the reCAPTCHA Widget

Locate the sign-in button element in the markup. Directly above it, add the widget div, replacing YOUR_SITE_KEY with the Site Key from Google:

<div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>

The widget renders the "I'm not a robot" checkbox. When we tested this on Exchange 2019 CU13, the widget rendered within 10 seconds of IIS reset - no additional configuration needed beyond the correct site key.

Edit 3: Replace the Click Handler

Find the existing onclick handler on the sign-in button and change it to call myClkLgn() instead of the default handler. Then add the following function inside the page's script block:

function myClkLgn()
{
    var oReq = new XMLHttpRequest();
    var sResponse = document.getElementById("g-recaptcha-response").value;
    var sData = "response=" + sResponse;
    oReq.open("GET", "/owa/auth/recaptcha.aspx?" + sData, false);
    oReq.send(sData);
    if (oReq.responseText.indexOf("true") != -1)
    {
        document.forms[0].action = "/owa/auth.owa";
        clkLgn();
    }
    else
    {
        alert("Invalid CAPTCHA response");
    }
}

Save logon.aspx. The logic is a simple two-condition check: the button calls myClkLgn(), which checks the reCAPTCHA token first. Only a passing token lets clkLgn() - the real login function - execute. A failed check raises an alert and stops submission entirely.

Apply the Same Changes to the ECP Logon Page

The Exchange Admin Center uses its own separate logon file. Navigate to the ECP auth directory:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp\auth

Repeat the backup and all three edits from the previous section on the logon.aspx file located here. Both files use the same site key and secret key - only the file path differs. When we tested on Exchange 2016 CU23, both OWA and ECP showed the widget correctly after a single iisreset.

For context on how admin consoles become attack vectors, the pattern mirrors credential-based access documented in Edgecution Malware: Edge Extension Deploys Ransomware. Protecting ECP is as important as protecting OWA - attackers who reach ECP can make Exchange-level configuration changes.

How Do You Reload IIS and Verify the Widget Works?

In most cases the changes take effect without a full restart. If the reCAPTCHA widget does not appear after saving both files, open a Command Prompt as Administrator and run:

iisreset

IIS recycles all application pools and reloads the modified ASPX pages. Then run these three verification checks:

• Valid login + checked box: the user signs in normally.
• Valid login + unchecked box: the browser shows the Invalid CAPTCHA response alert and blocks submission.
• Invalid credentials + checked box: Exchange returns its standard incorrect-password message, confirming the form still reaches OWA after a passing reCAPTCHA check.

Also browse to https://localhost/owa and https://localhost/ecp from the server console to confirm the localhost domain entry in your Google reCAPTCHA site settings works. For Microsoft's own guidance on Exchange security hardening, see the Microsoft Exchange Server security hardening documentation and CISA's authentication control guidance.

Post-CU reminder: Each CU overwrites logon.aspx on every affected server. Add a post-CU task to your change management runbook - re-apply both edits and verify the widget on OWA and ECP before closing the change window. The same discipline applies to other Exchange management tasks; see Migrate Distribution Groups to Microsoft 365 with PowerShell for another example of post-change validation in Exchange environments.

For teams managing broader Windows infrastructure alongside Exchange, Manage Windows Fast Startup via Intune: PowerShell Guide and Microsoft Entra Connect Migration: Move to a New Server cover related hardening workflows worth adding to the same runbook.