Web Application Fortification with ModSecurity over IIS : The classic three thwarted!

XSS, SQLi and the path traversal attack are the golden three payloads we see over and over again. In this segment we will oversee how ModSecurity securing IIS reacts to these payloads.

First and foremost , we will fire the payloads in ModSecurity’s demo site and see that the information is reflective in that it is sent back to the user for input. Evidently this is due to the fact that we are using a demo site and that a dashboard or log viewer is not available to oversee the errors. In the real world we would be exposing ourselves as we would let the attacker know that we are using brand x or IDS/IPS or in this case a WAF that is augmented with the OWAPS CRS to become and IDS.

Classic payloads and the online model.

Classic payloads and the on-premise solution housed in IIS.

Happy defending!

ASP.Net WebAPI and CorrelationID/RefCorrelatonID

Somethings can be foreshadowed and some things are always expected. As is the case of looking in log files and not seeing a Correlation ID nor any RefCorrelation ID’s. Thing is when your logs do not have alot of throughput you can find your customers/clients/elements/daemons log entry with ease with just a log stamp (datetime). However , even with low latency Correlation ID’s should always be utilised.

What is a Correlation Identifier?  Simple Guid that is Unique and identifies a transaction. See the link for a more enterprise integration perspective, but in the end a guid is all this is.

A curious thing that I always see is that in all the logging examples:

1) No provisioning for Correlation ID’s
2) No provisioning for Ref Correlation ID’s

I then ponder on …

how is it that you correlate?

(Pun intended)

Inbound Web.API calls should have a header containing a Correlation ID. Which is a GUID that can clearly and uniquely identity the transaction.

This in turn then becomes the RefCorrelation ID in your log, as you spawn a Correlation ID of you own based on the Request.CorrelationID which is a unique identifier to the transaction. The client should see his/her payload coming back with an echo of the ID they sent in. At times the RefCorrelationID is also sent as an echo. All depending on requirements and standards.

I very much like this implementation: https://mderriey.github.io/2016/11/18/correlation-id-with-asp-net-web-api/

The only variant that I advise is to accept a correlation ID from the client and to use the correlation ID from the request [request.GetCorrelationId()] as the Unique ID in the logs.



First example of standard flow a request comes in and is processed internally via multiple logging points. The RefCorrelation ID is what the client passed in, the Correlation ID is what we generated or decided was going to be the unique idenitfier.

In the second example another service is call. Say to process a payment.

Which ID is passed?

Your correlation ID is passed and the new service uses yours as a REF and generated a new unique ID for its transaction. So on and so forthat as many times as we have subsequent calls.

Having worked in integration for over 12 years, I know the value of being able to correlate all data especially when execitions can go from Java to ASP.Net Web.API to IBM MQ to Biztalk to Appliances.

Food for thought!




Transient Fault Application Block -The transient fault that was not!

I was perusing the source files for the ServiceBusTransientErrorDetectionStrategy in the TFAB core.

To my suprise I saw these constructs!

Before we start pondering on what is a transient fault and what is not!

Remember that for this implementation MS utilises the IsTransient.
public bool IsTransient(Exception ex)
return ex != null && (CheckIsTransient(ex) || (ex.InnerException != null && CheckIsTransient(ex.InnerException)));

All of the items are correct however I am struggling with a few elements:


ex is SecurityTokenException) return true;

How does this comprise a temporary condition in which we cannot reach a partner nor do a transaction….I am not sure it applies!


ASP.Net Web API and Project HoneyPot : BFF’s

Sometime ago, I presented an ASP.Net Security Skeleteton session at Microsoft TechDays. The concept was simple, build a base layer that can aid in the defence and forensics gathering of an ASP.Net WebSite whether it was WebForms or MVC.

An interesting element that was in the security skeletons layer as a HoneyPot Module. This element would utilise a module to verify IP Addresses against malicious behavior.

Think of a HoneyPot as a boobytrap.

You create a fake login page that is not acceccible by normal means except a scan and presto you know someone is up to something. Same goes for ports, fake robot file entries.

These ip addresses are sent to a centralized repository and you can analyse your inbound requests for the IP and compare against their list.

Now in order to do so one has to be efficient, you would want to either send a payload or verify against a cache. Either or is possible with different vendors/free implementations but in the end you want to check if an IP has been flagged as malicious.

Here are just a few of the IP Direcories available.

  1. Directory of Harvester IPs

  2. Directory of Spam Server IPs

  3. Directory of Dictionary Attacker IPs

  4. Directory of Comment Spammer IPs

In ASP.Net I like to use handlers whether message handlers or htphandlers to 

  1. Verify for excessive request
  2. Verify my blacklist
  3. Verify a honeypot
  4. ….so on and so forth

However throughout the years I have come to realise that tooling such as ModSecurity has HoneyPot integration built in. When no IDS is available I use a security related base layer but when I can utilise an IDS I rather go that route as it can secure an entire stack.

The service that Project HoneyPot offers is this:

HTTP Blacklist

The HTTP Blacklist, or “http:BL”, is a system that allows website administrators to take advantage of the data generated by Project Honey Pot in order to keep suspicious and malicious web robots off their sites. Project Honey Pot tracks harvesters, comment spammers, and other suspicious visitors to websites. Http:BL makes this data available to any member of Project Honey Pot in an easy and efficient way.

Http:BL provides data back about the IP addresses of visitors to your website. Data is exchanged over the DNS system. You may query your local DNS server and receive a response back that indicates the type of visitor to your site, how threatening that visitor is, and how long it has been since the visitor has last been seen within the Project Honey Pot trap network.

Several software authors have written implementations for a variety of web platforms. If you would like to integrate with http:BL, check out the http:BL API document.


IIS HttpFingerPrinting Pragmatics

For order of business in any appsec reconnaissance usually involves Maltego, Sploitego, and for me  HTTPFingerprinting.

Trying to identify the landscape is important as you will want to know how hackers go on the offense and determine your o/s and web server pragmatics. 


From moving response date formats ; to changing the Server header, to altering ordering…are all valid ways you can confuse the http reconnasance tools. However one thing remains.

When someone is scanning you? Are you aware?

Let’s take a look at ModSecurity and how it handles the various payloads from a few classic tools.


I always recommend to scan yourself as part of the SDLC in order to see if you have leaky response headers, if your IIS implementation still has the x-powered-by etc.

The more someone knows about your landscape the more they can act on.

Happy Defence!

Visual Studio Talk Show – Joel Hebert and ModSecurity Over IIS

I had the pleasure to be on the VS Talk show with Guy Barette and Mario Cardinal. 

Nous discustons avec Joel Hébert de son expérience avec ModSecurity et IIS. ModSecurity est un pare-feu applicatif web qui ajoute des fonctions de sécurité pour le serveur HTTP Apache, IIS et Nginx. C’est un logiciel libre distribué sous la licence Apache 2.0.


Joel Hebert est un architecte logiciel qui réside à Ottawa. Il se passionne pour la sécurité et l’architecture. Il est un MVP ASP.Net et est un des leaders du groupe d’utilisateurs à Ottawa. Il aime partager ses connaissances du piratage, des tests de pénétration et d’audit en continu sur les vecteurs d’attaque modernes de sécurité.


Livre: Web Application Defender’s Cookbook: Battling Hackers and Protecting Users
Site Web de Troy Hunt: Have I Been Pwned?

Enterprise Distributed Logging – Necessary Constructs!

Service Bus for Windows Server is my friend, why? you might ask. I have been closely tied to this friend for over a year as I created a large distributed logging framework for a Client. Once of the realizations that I had is that in Enterprise Integration where so many different systems must interact; it is difficult to correctly aggregate all of the data and satisfy both Business and Technical teams. 

What I was able to induce from my time with the Service Bus , building out a complex logging ecosystem are a set of constructs that all should adhere to.

Here they are:

Logging is not just for errors.
Synchronous vs Asynchronous
No retry logic implemented
No fall back strategy
Single Point of Failure
No Data Persistence and Replay Capabilities
No Logging level specified
No correlation identifiers
No Priority set on the logs



Web Application Fortification with ModSecurity over IIS : Brutus

Et tu, Brute?”==> “and you, Brutus?”

ASP.Net whether WebForms of time past or MVC and even Core are all plaforms that can utilise BasicAuthentication and with this comes the daunting task of securing the username and password.

In comes Brutus: from main site (google flagged as dangerous – omitted)

Brutus is one of the fastest, most flexible remote password crackers you can get your hands on – it’s also free. It is available for Windows 9x, NT and 2000, there is no UN*X version available although it is a possibility at some point in the future. Brutus was first made publicly available in October 1998 and since that time there have been at least 70,000 downloads and over 175,000 visitors to this page. Development continues so new releases will be available in the near future. Brutus was written originally to help me check routers etc. for default and common passwords

We know password re-use is predominant. We know that common user names are utilised. Many techniques exist to oversee if the accounts that are part of your domain are compromised. There are password lists , haveibeenpwned, and password dumps online (legality of pulling these is in question}. 

The best way to defend yourself against dictionnary attacks is to perform them. In comes our friend Brutus with Basic Autentication based attacks on our ASP.Net platform on IIS.

In this video we perform such an attack and ModSecurity over IIS is able to stop the cycle and also add forensics for us to identify the attack along with data for the security offices if need be.

Another consideration is Brutus not only can read from a text file but can also based on AutoGeneration. This is why I do not like exposing the password strength requirements. The brute force engines can iterate the site using the conditions imposed and well…..exposed by the site and this with pleasure.


The consideration we have here is that ModSecurity was not only able to stop Brutus as it excessively iterates the website or web.api but the forensics to report on this are also present. Alerting is also possible .

In a previous demo I used an HTTPModule to stop excessive iterations and report back a 500 internal server error to thwart certain attacks. Issue with this is it is not automaticly logging and providing forensics. 

Here is an example event viewer entry: 

Note the idnetification that that a security scanner has iterated the site. The scanner is brutus/aet and it was identified by OWASP CRS/2.2.9.

The CRS stands for CoreRule Set https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

ASP.Net / Web.API’s can report whom is excessively iterating them when under the umbrella of ModSecurity.

Happy coding!

ASP.Net Web Api Security : Remove Generated Http Response Headers

IIS and some of the constructs in ASP.Net love to let the populace know that you are utilizing IIS and what flavor of ASP.Net or MVC you are using. 

This can be great when debugging payloads and you know what the partner has as infrastructure but for an attacker it is an excellent way to reflect your landscape.

Let’s see what a standard payload looks like.

Start with creating a stand web app.

Select Web API and follow the same indices as illustrated.

Run the application to ensure it compiles and renders.

Start up a proxy of your choice , here we are using Telerik Fiddler.



  1. Server
  2. X-AspNetMvc-Version
  3. X-AspNet-Version
  4. X-Powered-By

To remove these headers (from http://stackoverflow.com/questions/12803972/removing-hiding-disabling-excessive-http-response-headers-in-azure-iis7-without):

 You can use the PreSendRequestHeaders and PreSendRequestContext events with native IIS modules, but do not use them with managed modules that implement IHttpModule. Setting these properties can cause issues with asynchronous requests. The correct version is to use BeginRequest event.

    protected void Application_BeginRequest(object sender, EventArgs e)
        var application = sender as HttpApplication;
        if (application != null && application.Context != null)

To remove X-AspNet-Version, in the web.config find/create <system.web> and add:

    <httpRuntime enableVersionHeader="false" />


To remove X-AspNetMvc-Version, go to Global.asax, find/create the Application_Start event and add a line as follows:

  protected void Application_Start()
      MvcHandler.DisableMvcResponseHeader = true;

To remove X-Powered-By, in the web.config find/create <system.webServer> and add:

        <remove name="X-Powered-By" />


Happy defending!

infosecinstitute Noobs CTF Level Three

Level three is fun , you get a qrcode that you can paste to :

It will decode to:


Raw text
.. -. ..-. --- ... . -.-. ..-. .-.. .- --. .. ... -- --- .-. ... .. -. --.
Raw bytes
22 57 8c cf be 1b c6 75   fc fb d7 b3 f7 8c cf d9
f7 c5 f8 6f 19 d7 f3 f7   5f f0 de 2f 3e f5 fc fd
e1 bc 67 86 eb d9 f7 af   67 ee bf 9f bc 66 7e f0
dd 7f 3e f5 f0 ec 11
Barcode format QR_CODE
Parsed Result Type TEXT
Parsed Result
.. -. ..-. --- ... . -.-. ..-. .-.. .- --. .. ... -- --- .-. ... .. -. --.

this is evidently a morse code…

use a translator: http://morsecode.scphillips.com/translator.html

and presto you have the flag