White-listing Tor in CloudFlare with PowerShell

CloudFlare has been one of those technologies that has dramatically improved the Internet since its arrival. CloudFlare provides a number of amazing features, from DDOS protection, traffic analytics, performance optimizations and even free SSL! To top it all off, CloudFlare off the majority of their features for an amazing price – FREE!

Unfortunately, there are a group of users who have suffered with the rapid adaption of websites being protected by CloudFlare; Tor users. Whilst the majority of us receive the benefits of CloudFlare, it has made life for Tor users extremely miserable.

What is the issue with CloudFlare and Tor?

To understand the issues CloudFlare and Tor, we first need to understand how CloudFlare protects a website. When you visit a protected website, CloudFlare performs a risk assessment of your IP address. If CloudFlare decides that you are friendly, then you get to view the website. If it decides you are suspicious, then you will either be prompted with a CAPTCHA request or, in the extreme cases, it will deny access to the website.

The Tor is an interesting network, developed with the aim to protect privacy and defend against surveillance; the network has become a bit of a hive of scum and villainy. Due to the high use of Tor for malicious activity, CloudFlare is naturally suspicious of any connections coming from a Tor exit node, which results in a high risk assessment for all Tor users accessing protected websites.

A high risk assessment results in lots of CAPTCHA requests for Tor users to complete. Every protected page that a Tor user visits, will result in a CAPTCHA request, whilst most of us don’t mind completing these, consider how you would feel answering one every 15 to 20 minutes. It impacts productivity and your sanity.

What is the solution?

The trust of the matter is that there isn’t a simple solution, there isn’t a magic “trust Tor” button in the CloudFlare. It is down to individual website operators to white-list the Tor exit IP addresses; this isn’t trivial, requiring operators to maintain a white-list as the Tor network changes, adding new exit IP addresses that join the Tor network, whilst removing those that leave.

Now is the best time to point out the risks of white-listing. White-listing isn’t without its own risks! When you white-list an IP address in CloudFlare, you are telling it to ignore how risky the traffic coming from that address might be. Not all Tor users legitimately want to view the content of your website; some Tor users are malicious, they are out for blood. White-listing significantly changes the security protection of your site, and you need to be extremely aware of the risks it introduces.

Set and Forget White-Listing

Donncha O'Cearbhaill developed a Python based script with the aim of providing a “set and forget” mechanism for white-listing Tor exit IPs. Donncha’s Automatic CloudFlare Tor Exit Whitelister takes your CloudFlare API token and email address and does all the hard work. The script will grab the latest listing of the Tor exit IPs, and then updates CloudFlare’s white list as appropriate.

When I saw the script, my immediate reaction was “what an amazing idea”, my next was, “how could this be made more accessible to more website operators?

Turning to PowerShell

The obvious answer to encouraging more web site operators to white-list Tor exit nodes is to provide the process in more accessible formats. For Windows users, the best option is to provide the process as a PowerShell script.

So I sat down, learn some Python, and then worked on developing a PowerShell script with similar functionality as Donncha’s. This was a super fun and interesting process. In the end, I deliberately tried to stick a similar logic flow, similar parameters are supported (via parameter liases), and the scripts default output is similar. I added some additional verbose and debug options and added progress bars for long operations. I haven’t included support for specifying the CloudFlare API token and email address via environment variables.

The final result can be found over at GitHub, at https://github.com/poshsecurity/PowerShell-CloudFlare-Tor-Whitelist. All of the functionality is provided by the Set-CloudFlareWhiteList.ps1 script.

Please feel free to raise pull requests, issues, or provide any feedback that you may have.


I have included comment based help, with examples on how to make use of the script. There are three common usage methods.

  1. Specifying a CloudFlare token and email. This will white-list exit node IP addresses across all of the domains in your CloudFlare account
  2. Specifying a CloudFlare token, email and a DNS zone. This will white-list exit node IP addresses for a specific DNS zone.
  3. Specify a Token, email and optionally a DNS zone, and the -ClearFlags parameter. Remove all Tor specific rules for all domains in your CloudFlare account, or for a specific DNS Zone.

Finishing Up

I want to thank Donncha for his work in developing the original Python script. Without his work, I wouldn’t have been able to develop mine.

If you want to find out more about CloudFlare, Troy Hunt has put together a terrific PluralSight course, Getting Started with CloudFlare™ Security. He covers the basics including migration, SSL configuration and even HSTS.

Kieran Jacobsen

Why Remoting vs SSH vs RDP Shouldn’t Be A Thing

Microsoft recently announced that they would be introducing SSH support in the coming Windows Server release. It has taken three attempts by the teams within Microsoft to gain the necessary approval to do this, and finally, third time is the charm. Hats off to those within Microsoft who have had the courage to keep to their guns with this one and get SSH included. You truly have made a positive improvement.

The introduction of SSH opens up a world of possibilities for administrators, developers and integrators; unfortunately, there seems to be quite a few in the industry that don’t share in the excitement. 

I think some people misunderstood why people were so excited. Some went so far as accusing a few of us of shouting “Death to Remoting”. I don’t see this as the death of Remoting, it is naïve to think that SSH will replace Remoting; SSH will compliment Remoting and solve a number of challenges which currently exist with Remoting.

Native support for SSH both as a client and as a server opens up a number of functions and tasks which until recently were only achievable via third party utilities, modules and just plain hacky code. Carlos Perez and I have both written PowerShell modules (his is better), that integrate with SSH, Posh-SSH and SSHFunctions respectively. We wrote these to bridge a number of gaps, gaps that will/should be removed with native SSH support. 

This is a new world for administrators and developers alike, be that those who work primarily in the Microsoft space, as well as those working with Linux.

Remoting –ne SSH –ne RDP

It should be painfully clear, but I want to make it absolutely crystal clear; Remoting does not equal SSH, SSH does not equal RDP and RDP does not equal Remoting.

Each of these protocols have a different aim:

  • Remoting (or WinRM) is roughly a remote management protocol
  • SSH provides a Secure Shell for text based management
  • RDP provides remote GUI access for GUI management

We really shouldn’t get these confused, each of them have different goals and aims, and as administrators/developers you need to know each one, when each one is appropriate to use and when each one is inappropriate.


Remoting is an implementation of the WS-Management, which is an open, SOAP based protocol for the management of things like servers, workstations, devices and applications. The WS-Management standard was developed by a bunch of smart people at AMD, DELL, Intel, Microsoft and Sun back in 2005.

Unfortunately, WS-Management didn’t really take off, with only 4 major implementations found on Wikipedia: Windows Remote Management (WinRM), an implementation in SUSE Linux Enterprise, a European research project and finally Intel’s Active Management Technology. It is easy to speculate why WS-Management didn’t take off, the most obvious is the heavy overheads of SOAP web services. SOAP was big back in the 2000s, it isn’t as popular now and with good reason.

Believe it or not, I like WS-Management and Remoting. Remoting supports two pieces of software to connect to each other, and efficiently exchange complex pieces of data, allowing administrators, developers and integrators to build rich pieces of software on top. 
Multifactor authentication is pretty limited with Remoting. While you can add two factor into RDP, remoting hasn’t had the same treatment. 

Server authentication in Remoting is typically a complex story. To start with, typical deployments will be based upon HTTP providing limited (read: no) authentication, if you want strong server authentication, then you need to switch to HTTPS. 

The switch to HTTPS for Remoting is where things start to fall apart. A typical Remoting HTTPS deployment will be based upon self-signed or internal PKI. If you stick with self-signed, you either need to manually trust each server’s certificate, or you can skip the CA trust checks. If you want proper certificates, typically you are going need to deploy a CA infrastructure, and then configure each server to use HTTPS; you can’t use Group Policy, it doesn’t support enabling HTTPS for Remoting. Finally, don’t turn off HTTP if you want to keep using the Windows Server Manager. If you want to understand how bad configuring HTTPS for Remoting is, check out the best guide available at Carlos’ Blog, WinRM SSL Certificate Deployment via GPO.

Remoting has unfortunately been missed when it goes for secure configuration guides, the same goes for things like IDS and IPS rules. Whilst there are obvious challenges for IDS/IPS scanning of Remoting traffic that is over HTTPS, thankfully we can apply a lot of the same policies and rules for IIS to Remoting.

I feel a little jaded by Microsoft’s release of a reference implementation of WS-Management for Linux. It should be obvious to Microsoft by now that big companies cannot force the open source community to implement the standards and solutions they want. I was kind of shocked to hear about this one.

Side note: How long till Remoting is RESTful?


SSH, or Secure Shell, is an encrypted protocol for the initiation of text-based shell sessions on remote machines and was originally developed to replace Telnet, RSH and REXEC. If you ask the average person what SSH is for, they will tell you it is what you manage Linux and Unix with.

Whilst it is possible to use SSH as an integration point into automation and management of remote endpoints, it doesn’t support the exchange of complex object types, it only supports strings. For those who haven’t tried using SSH for large amounts of remote command execution, the closest would be something like invoke-command. Don Jones explained it well, “It’s all text, all the way down to the turtles.” As he goes on to summarise, whilst text isn’t bad for automation, string manipulation isn’t good. I also feel that it is wise to point out that string manipulation is a great way to introduce security vulnerabilities as well.
SSH makes up for all of this, by being extremely secure. SSH supports multifactor authentication with support for both password and key authentication, something that Windows still hasn’t caught up to (natively). 

Server authentication, that is, the authentication of the server by the client (so we know we are connecting to the right server and we are not being MITM), is quite easy. Servers have a public and private key pair, we just need to verify the thumbprint of the public key, and then we can establish a trust relationship (from here to eternity if we so desire). 
Another advantage of SSH is we know extremely well what valid SSH traffic looks like. This is critical in protecting connections either leaving our networks perimeter or those entering from outside. If devices like our IPS and IDS systems know what a valid SSH packet looks like, then we can make an attempt to weed out the nefarious traffic.

Transferring files over SSH is extremely easy, fast and efficient. I have used SSH as a file transfer mechanism in a number of environments, be it at home, in financial institutions or even for backups and server migrations. In banking SSH is an industry standard, much like PGP/GPG for a reason.

In summary, SSH gives us a secure text session in a manner that is extremely easy and without a PKI, unfortunately it is pretty bad at the exchange of complex data.

Side note: Check out Mosh an SSH replacement (not available on Windows yet). I really like the idea’s behind Mosh and can’t wait to see where it goes. I would really love to see a synchronised state console like this one.


We should all by now, know what RDP is! RDP allows us to connect to remote devices and servers via a graphical session. RDP does remote graphical consoles really well, has a simple but quite reliable security model and supports some limited file transfer options.

RDP is a heavy protocol on a network connection and for obvious reasons. Even with the advances in later RDP protocol versions, sending a graphical interface over the Internet can still be slow and laggy; combine this with file transfers, and you are in for a long wait.
There are a number of ways to add multifactor authentication to RDP, most notably solutions from DuoSec

Server authentication in RDP is actually pretty good. RDP comes by default with a self-signed certificate which does provide a degree of server authentication. You can step it up a notch by moving up to certificates issued from an enterprise CA. Configuration of RDP to use an enterprise CA is extremely simple, you can use group policy all the way. For a great write up on how to set it up, check out Carlos’ post, RDP TLS Certificate Deployment Using GPO.

RDP has been around for a long while, and a significant number of IDS and IPS products have developed rules to detect malicious traffic. Much like SSH, there are plenty of secure configuration guides for RDP from a number of trusted sources.

We need to reduce our reliance on RDP, not just because of how slow it is when managing cloud based infrastructure but also because it doesn’t support automation to any extent. RDP will always exist, there are times when we will need to run a GUI on a remote machine. 


Enter-PSSession deserves a special mention. Providing functionality much like SSH, Enter-PSSEssion allows users to initiate a text based shell session with a remote device all over Remoting. Yes, in many ways it does provide a similar functionality to SSH, but from personal experience it can be a bit slow and clunky. 

Why is Enter-PSSession a bit slow and clunky? Well the best way to understand why, is once again by Don <link>. With Enter-PSSession, keystrokes are not transmitted in real-time, instead, each whole line is transmitted, executed, and then the results sent back to us. With all of the SOAP overheads, you can start to see where things get bogged down.

The right tool for the right job

Different tasks require different tools. You don’t use a sledge hammer to drive a screw, you need a screwdriver.

If you are running a graphical interface directly on a server (for an application that doesn’t support running remotely), then you need RDP. If you have to run the GUI on the box, you don’t have any other option but to run the GUI on the box via an RDP session. Obviously, in this case, Remoting, SSH and Enter-PSSession aren’t going to be much help here.

Want to configure a server, well, then PowerShell with Remoting is probably your best tool. You could use a text based console session with SSH or Enter-PSSession, but that might be a bit too much. If you were working with say configuration files, maybe jumping to a full text session might be worthwhile.

The final situation is a complex but common one. You have a single server, maybe its hosted by a provider like Azure; your client doesn’t have any reason to trust that server, there isn’t a shared PKI to support server authentication. SSH in this situation will shine, chances are it will be easier and more secure. Either you are going to switch down to HTTP, trust a self-signed certificate or tell PowerShell to ignore CA validation errors. This is a great time for SSH to shine.

Side Note: It would be nice to see a PowerShell CMDLet to help verify Remoting certificates and even configure trust.

In each of these situations, a different remote management protocol was required. Where as in the past, we had to make do with three options (PowerShell with Remoting, Enter-PSSession, RDP) we have now gained a fourth (SSH).

A Whole New World…

I want to point to a post by Mattias Geniar, How SSH In Windows Server Completely Changes The Game. Mattias has put together an exceptional post on why SSH is a game changer in his mind.  

I feel that the introduction of SSH opens up more administration possibilities, there is an SSH client for Android, from that I could be managing my servers in minutes something that I can’t easily do that right now (well there is the PowerShell web page thing). 

The introduction of SSH also opens up opportunities for Windows in environments that are currently predominately OSX/Linux/Unix, which has to help in the adoption of products like Nano (but alas Nano will miss out this time round) and the IOT versions of Windows.

Remoting isn’t going to go away just because SSH support has been introduced. I wasn’t rejoicing the death of Remoting when SSH support was announced, I was rejoicing that progress is being made in cleaning up the whole landscape, starting with compatibility and trust. I have always seen Remoting as a successful failure, we have proved the idea works, now it is time to start working on something that is better. I really hope to see a more improved remote management protocol coming out from Microsoft over the coming years, something that is actually cross platform and easy to integrate. Until then, we have three exceptional management protocols in tool kit to use.

Kieran Jacobsen

Why isn't Remoting Disabled by Default on Windows Server?

I was recently involved in a brief and quite lively Twitter discussion with Don Jones and Jeffery Snover about PowerShell Remoting and why it is enabled by default. I have been involved in a number of discussions about this topic, but never with such a distinguished crowd such as this one. My opinion, and my original comments, where along of the line of  “I believe Remoting should be off by default”, “Well, RDP is disabled by default, why not Remoting”, and “SSH has been off by default for years”, whilst the counter arguments were of the form “Because Nano Server” or “You could always customise your environment to be off by default”. 

Don Jones posted a follow up to this discussion on PowerShell.org titled “Why is Remoting Enabled by Default on Windows Server?” and asked me to put together a post on why I felt it should be off by default. This was difficult for me to put together, so here goes!

It has long been an industry practice, to disable/stop services which are not in use on your clients and servers. The argument is quite simple, enabled services are vulnerable servers, they expose your devices to potential risks. Simply having Remoting off, unless explicitly required, will reduce the attack surface area and increase the security of our systems.

Even Microsoft has followed an off by default methodology for the past 10 to 15 years. Services like POP3 and IMAP are off by default in Exchange, SQL servers do not listen for IP addresses by default, we need to install roles and features individually. Microsoft learnt from a number of major security blunders in the early days (Code Red, Slammer and even Blaster), and focused on a more secure development and deployment model. Why should there be an exception to this posture that has worked extremely well since Windows 2003?

Linux administrators, and developers of Linux distributions have been in a similar situation in the past. For a significantly long period of time, SSHD has been off by default, and administrators have still be able to manage their server fleets. One of the early reasons for an off by default approach in Linux, was that it ensured that administrators were aware of the risks prior to enabling SSHD. Now it can be argued, that this has been a failure, and I think most would agree. I do, however, believe that the failure is not in the off by default configuration, but is in the lack of documentation covering the secure configuration of SSHD. People in glass houses shouldn’t throw stones, as Remoting can be just as poorly deployed.

Remote Desktop is a great example where Microsoft followed these methodologies. RDP is off for a number of reasons with security being only one of them. Ironically, one of the obvious reasons to have RDP off by default is to encourage the move from on server management to remote management. Whilst adoption has not been as high as was expected (due to issues with third party vendors, administrators and to a big extent Microsoft), it is clearly a sign of how ahead of the curve Microsoft has been.

It has become increasingly dangerous to expose management services, be they SSH or RDP on the Internet. If you have ever been responsible to auditing the log files of a server where SSH or RDP is exposed to the Internet, you will be well aware of the automated scan attempts that are performed. Brian Kreb’s has posted on Internet criminals selling access to Linux and Windows servers whose credentials they have brute forced. What happens when the criminals discover Remoting? Bruteforcing credentials via Remoting should be even easier and have written about just such a thing on previous occasions. Should we be enabling these criminals and providing them with even more machines that they can take over?

Well, we are doing this to an extent right now. Users, administrators and developers have all been busy provisioning virtual machines on platforms like Azure and AWS, and whilst in many cases RDP endpoints are on random high ports, the same cannot be said for Remoting. Those who deployed and manage these systems may be well unaware of the risks that they have introduced to their networks. Moving to an off by default model could protect these environments from this sort of configuration error.

As a side note, it is still interesting to me how Microsoft changed Remoting from off to on by default in Windows Server 2012, with very little fanfare. In 2014 when I presented on Lateral Movement with PowerShell, audiences typically responded with a significant amount of surprise, be they from an administration or security background.

In Don’s post, he talks about the fact we could easily create an off by default environment if we so wanted. I really have to disagree with him, and say that he has missed the point to a degree. Whilst it is true, that we could use a customised gold/master image, Group Policy or some other tool to create an environment where Remoting is off by default, it must be highlighted that the inverse, an on by default environment would be just as simple to create with these tools. If you want it on, then turn it on, it isn’t that hard. 

Don also talks about the fact that Remoting is an incredibly controllable, HTTP-based protocol. This introduces the other issue I have with Remoting. Unless you are deploying an Azure Virtual Machine, post install, you will be exposing Remoting over HTTP and not HTTPS. Is this 2015 or 2001? Do we really still need to talk about the virtues of HTTPS? It would be trivial for Microsoft to change the default from HTTP to HTTPS in a manner similar to RDP. 

Now let’s talk about the big elephant in the room, or should I say Nano elephant in the room? What about Nano Server?!?!? Nano Server, whilst it is a new concept for some of us, isn’t a completely new in our industry. Whilst I agree, it is probably easier to have Remoting (and WMI) enabled by default, it isn’t like the deployment of a Nano Server is currently a simple process. Currently Nano Server is coming as a standalone WIM image, we need to manually add packages providing roles, and we currently need to join a domain during installation. How hard would it be to have a step enabling Remoting? It is trivial. 

Having said all of that, perhaps the best middle ground would be to have Remoting enabled on Nano Server, and off for Core and Full installs? Administrators have more option on the latter two than the former. Perhaps a compromise is in order?

Another side note, why doesn’t Microsoft want to enable Remoting on Clients? If Remoting is safe for Internet exposed servers, shouldn’t it be ok for Windows Clients?

So in summary, why should Remoting be off by default?

  • Off by default is an industry standard practice.
  • Off by default has been Microsoft practice for over 10 years.
  • Linux administrators deal with SSHD off, so can we!
  • RDP has been off by default, we lived with that.
  • RDP and SSH are actively brute forced, why open up another attack vector?
  • Off by default reduces administrative misconfiguration/insecure configuration
  • It is just as easy to switch it on, as it is to switch it off.
  • Nano Server isn’t as much of a challenge as we thing, but it could be the exception.

As Don said, whether you agree or not, it is entirely up to you and you are welcome to add your polite, professional comments to this post, or over at the PowerShell.org forums where I have cross-posted. Like Don, I wanted to explain and attempt to justify why I think Microsoft’s approach is not correct. I often believe the discussion is more important than the outcome, and I believe this is definitely the case here.

Kieran Jacobsen

MS15-034 Update

I just wanted to let everyone know that over the past few days I updated my MS15-034 code to support HTTPS connections. The work involved was much easier than I expected, so I felt that it was worth including.

Working with HTTPS is pretty simple. I have followed the usual convention and defined the –UseSSL parameter, it should be noted you will need to specify a port with the –Port parameter as well. Typically –Port 443 –UseSSL will perform what you need.

Let’s take a look at a few quick examples.

1)    Testing a Windows 2012 server with HTTPS and determining if it is vulnerable:

2)    Invoking the DOS, this time there is a custom port number in use:

One thing to note, the certificate will be validated, so make sure it is trusted/valid etc.

I am still seeing and hearing of this attack occurring, with a significant number of systems still remaining unpatched. I still haven’t seen any code examples supporting Remote Code Execution (RCE), but I am sure someone has figured that one out and is keeping it very secret.

You can find the updated code at the GitHub repository MS15034, or download the code as a zip file.

Kieran Jacobsen

Exploiting MS15-034 with PowerShell

On Thursday morning, I woke up to an extremely busy Twitter stream; the topic which that was on everyone’s’ lips was Microsoft Security Bulletin MS15-034.

MS15-034 is a critical security bulletin impacting HTTP.SYS, which forms a core component of IIS and a number of other Windows roles and features. The vulnerability described in the bulletin is a Remote Code Execution (RCE) however at the time of the publication of this post, only a Denial of Service (DOS) of the system has been achieved. There are a number of claimed RCE pieces of code on sale, yet none have been verified.

Over the days since the original release of the bulletin and its associated fixes, things have moved quite quickly. Simple detection (more) and exploitation code had been developed, as well as more complex pieces and even a Metasploit module. Now it is fine for those of us who have Linux systems, or even maybe those who have Windows ports of perl, python, curl or wget installed to use a number of these scripts/examples that are out there, however I feel it is important that this be presented in a way that is accessible and understandable by the average Windows administrator.

Chris Campbell (@obscuresec), put together some PowerShell code that would allow administrators to determine if a system was vulnerable. Unfortunately, there were some issues with this code that means it isn’t as effective as it could be. Firstly, Chris’ code doesn’t report if any other HTTP errors are generated, for example, if you specify an invalid page, the code wouldn’t alert you to the HTTP 404 that would be returned. The next issue is that a non-vulnerable system returns a HTTP 400 after the patch, something the code doesn’t pick up on. Finally, the range header values specify do not match what has been specified in other pieces of code. I felt we needed not only PowerShell code to test if a server was vulnerable, but that it would be interesting to see if we could also exploit a vulnerable server.

Now it should be noted, that you simply can't use the .Net WebRequest class to specify the appropriate “Range” header values, you need to use the TCPClient class and run at a lower level. This is more of a separate discussion I will leave for a later post.

Over the course of past few days, I developed PowerShell code, heavily inspired by the Metasplout module, to allow for the testing and exploitation of MS15-034. This code is contained in the module, MS15034.psm1 up on the Posh Security GitHub. There are two functions which will be of interest; Test-MS15034, which allows for the testing of servers, and Invoke-MS15034DOS which is capable of performing a denial of service against a specified target.


The CMDLet Test-MS15034 requires the specification of a computer name or IP address, and optionally a port number, and then 3 different parameter sets:

  1. Specifying the -Windows2008 parameter
  2. Specifying the -Windows2012 parameter  
  3. Specifying a custom HTTP path with the -ServerPath parameter

The first two are simply to simply the testing against lab environments, as they will connect to the URL of the format http://<Computer>/welcome.png and http://<Computer>/IIS-85.png respectively. The third option is to specify your own HTTP path, which is something you are more likely to do in a real world scenario. You can specify any file or structure using -ServerPath, examples could be:

  • /index.html
  • /CompanyLogo.png
  • /images/logo.jpg

Let’s look at some examples (these may not display correctly via RSS)!

1) Testing a Windows 2008 server and determining that it is vulnerable:

2) Testing a Windows 2012 server and determining that it is vulnerable:

3) Testing a Windows 2012 server and determining that it is not vulnerable :

4) Testing a server using a custom server path and determining that it is vulnerable:

5) Testing a server and specifying the wrong operating system (or the default files do not exist):

6) Testing a server using a custom server path, which doesn't exist:

This CMDLet will connect to the URL determined by the parameters, specifying the header Range: bytes=0-18446744073709551615. If the response from the server is a HTTP 416, then it is vulnerable, if the response is HTTP 400, then the server is not vulnerable. Other errors will be displayed and managed accordingly. 


Now let’s take an attack to the next level and take the server down! The CMDLet Invoke-MS15034DOS will do the trick for us. This CMDLet works much like the Metasploit module. The CMDLet accepts the same parameters as Test-MS15034, however it will begin by testing if the server is vulnerable, and if so, will then perform a denial of service.  The denial of service will be performed by specifying the header Range: bytes=0-18446744073709551615. 


In the examples that follow, I am simply using the default out-of-the-box images as the addresses, much like in the previous tests.

1) Invoking a denial of service against a Windows 2012 (R2) server:

2) Invoking a denial of service against a Windows 2008 (R2) server:

3) What happens if you try to invoke a denial of service against a patched server:

Next is a video of Invoke-MS15034DOS against an unpatched Windows 2012 R2 server. Note how quickly the server is taken down. I think it makes a nice alternative to Restart-Computer.

It should be noted that my code will only support HTTP and not HTTPS. I could develop support for HTTPS, but I suspect that in most environments, testing if a server is vulnerable via HTTP will be sufficient.

You can download my module from my GitHub repository MS15034, a zip file can be found here.

I really hope people will find this code useful. I will be putting together some follow up posts on this topic, including some observations around the issue and how I developed the code.

Kieran Jacobsen