HTTP Header Internal IP Disclosure

In a recent PCI DSS Compliance Report, I had an HTTP Header Internal IP Disclosure Vulnerability; which, I have dealt with before on a vanilla 2016 Exchange server but have really struggled to find any up to date information on this Vulnerability and the best way to fix it…

I use the term vulnerability very loosely in this tutorial as its what is stated in the PCI Compliance Report. Having only the internal IP address of a server is not going to get you very far; however, as part of your enumeration or as a wider attack, the internal IP address might be very useful.

I have added links to there Nessus pages showing the two vulnerabilities below:

Microsoft Exchange Client Access Server Information Disclosure:

Web Server HTTP Header Internal IP Disclosure:

These two Vulnerabilities exist because you can send the IIS webserver a specially crafted HTTP 1.0 GET request, without any host header set. This causes the server to divulge its own internal IP address.

The reason this happens is that the HTTP 1.0 protocol does not require the host header to be set by the client as part of the request. However, HTTP 1.1 requires the client to specify a host so is not affected.

In my test lab, I decided to recreate the Issue with a vanilla install of Windows Server 2016 and 2016 Exchange.

The tool ill be using to test these vulnerabilities is OpenSSL but there are other tools you can use like ncat or Nmap, you can even use burp and get the same results.

Microsoft Exchange Client Access Server Information Disclosure

Connect to the open HTTPS port of your exchange server using OpenSSL and the command below.

openssl s_client -host -port 443 
Open SSL making conection to exchange server

Once the connection is made, you will be prompted to input a command.

Input GET request

Make a GET request to autodiscover.xml using the command below.

GET /autodiscover/autodiscover.xml HTTP/1.0

You need to hit Enter twice after you typed the GET request; before the server will respond.

Internal IP

This spits out its local IP address under the header WWW-Authenticate: Basic realm=.

Web Server HTTP Header Internal IP Disclosure

To test this vulnerability, it is basically the same procedure as the previous one; But, this time we are sending our GET request to the root of the webserver instead of autodiscover.xml.

Connect to your exchange server using OpenSSL as below.

openssl s_client -host -port 443

Then send this GET request to the root page of the webserver.

GET / HTTP/1.0

Notice the response kindly lets you know the Internal IP in the Location: header.

302 Redirection causing Internal IP disclosure

Updated FIX

Originally when I started this tutorial my fix was to manually re-write the headers, so the headers displayed the external domain name instead of the internal IP address. This has got me through many a PCI DSS Compliance scan but there is a better way.

In researching this tutorial, I stumbled across this blog post from and their solution to this issue is to configure the IIS server to deny requests made without the Host header set. They achieve this by using the URL rewrite module for IIS.

I have tested this in my lab and it works a treat and would say is my prefered method to fix the two vulnerabilities.

URL Rewrite

Download the URL Rewrite module onto your exchange server and install it.

Install URL Rewrite

If installed correctly you should see a URL Rewrite shortcut in IIS, after clicking on the default website.

Url re-write installed in iis

Click URL Rewrite to open it. Then click the Add Rule(s) button under actions.

Add Rules

Choose Request blocking rule and click OK.

Request Blocking Rule

Set Block access based on Host Header, Block requests that do not match the pattern, using regular expression and set the pattern to .+ (i.e match one or more of any characters).

Regular expression URL Rewrite rule

Click OK and this rule should now display in URL Rewrite as below.

Rule showing in URL Rewrite

Connections now made via HTTP 1.0 without any Host header will be rejected by the server.

Url Rewrite Read Error

The Orignal Autodiscover.xml fix

This is my original fix for both the vulnerabilities, which I have left here just in case the URL Rewrite method does not work for you.

Let’s start with the exchange autodiscover local IP disclosure first, Open up IIS Manager, navigate to Autodiscover and then authentication.

click Authentication on Autodiscover

Then right-click Basic Authentication and select edit.

Edit Basic Authentication

Enter your external domain name into the Realm: and hit OK

insert external domain name

Now resend the HTTP 1.0 Get request to autodiscover.xml and you should get back the external domain name instead of the local IP address.

correct Domain in realm

HTTP Header Internal IP Disclosure

This is how to fix for the HTTP Header Internal IP Disclosure, took me ages to work this out.

The problem is that, even though there are no URL Redirections set In IIS by default with Exchange; the root of the website always redirects to Outlook web access(OWA).

This web 302 redirection is what exposes the Internal IP address of the server and the only way I have found in stopping this redirection before the URL Rewrite module is by removing OwaJavascriptRedirectModule from the web.config.

The web.config file is located in the inetpub folder which in my test lab is C:\inetpub\wwwroot\web.config

!!! Make sure you have a backup copy of the web.config before making any changes to it !!!

With the web.config backed up, open up the web.config with notepad and remove the line with OwaJavascriptRedirectModule from it.

web.config file

With OwaJavascriptRedirectModule removed; save the web.config and type iisreset from a command prompt to restart all the IIS services.

iisreset to restart the iis services

This fixes the issue as the server now does not do any 302 redirections and if you try the GET request again, the server now responds with the HTML for the default IIS landing page.

GET now showing HTML

If you open up a web browser and navigate to the root of web server, you should see a page like this.

Default IIS 10 page

Re-Setting up the Redirection

You can Easily re-setup the 302 Redirection to OWA with the HTTP Redirect module in IIS.

Click on Default Web Site in IIS Manager and Select HTTP Redirect.

manual Redirection

Make sure, “Redirect requests to this destination” is ticked; Then type in

Also, tick the box that says “only redirect requests to content in this directory (not subdirectories)”.

Apply the Redirection, now if we hit the root of our website it should automatically 302 redirect us to OWA as it did before when we still had the OwaJavascriptRedirectModule in the web.config

Re-run the GET request without any host header, and it should now give the external domain name instead of the internal IP address.

location now showing domain


Please let me know in the comments, if this tutorial has helped you out or if you have had any difficulties sorting these vulnerabilities. I read and respond to them all.


IT and security Expert with 20+ Years of Experience. _______________________________________________________ With over two decades of experience in the dynamic field of Information Technology and security, I have honed my skills to become a leading expert in safeguarding digital landscapes. My passion for technology and an unquenchable thirst for knowledge have driven me to stay at the forefront of the ever-evolving IT industry.

11 thoughts on “HTTP Header Internal IP Disclosure

    1. Hi James

      Yeah i know that exact feeling, I had the same problems in my quest to get PCI Compliance that is why i wrote this tutorial.

      Probably, just as much to help me remember the steps as to help others.

      also thanks for adding the link back to my site a lot of people do not bother.

      I have actually done a lot of PCI compliance over the years, so if you have any questions or need a hand with anything leave me comment here or over on my Facebook page or Twitter.


  1. Amazing writeup. Took me ages to find a fix for this IP disclosure.
    Thanks mate!!! Hugely appreciated!!

    1. Hi Matt

      Yeh I don’t think it is an issue anymore but worth keeping around just in case as you can use the URL rewrite for other compliance issues like this.


  2. Anyone have issues with their Exchange App Pools connecting after this modification with the URL rewrite? Found mobile clients wouldnt load email content but connected. Error logs showed “… MSExchangeMapiFrontEndAppPool’ failed to stop a listener channel for protocol ‘http’ in the alloted time…” This occurred for several app pools and they failed to start back up when attempting to restart them.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top