Get free SSL certificates with Let’s Encrypt

I have previously blogged about how you can get a free SSL certificate from the Certification Authority called WoSign, but they have been misbehaving lately (see details here) and some big companies like Apple, Google and Mozilla are actually considering removing the built-in trust to WoSign in their browsers.

So I decided it’s time to write a new post, this time using the Certification Authority Let’s Encrypt, which also makes it a lot less complicated. But still free!


So what is Let’s Encrypt?

It is a free, automated and open certificate provider. The organization behind Let’s Encrypt is called Internet Security Research Group (ISRG) and they have a lot of official sponsors. Here are a few of the more well-known, which shows that Let’s Encrypt is a serious player on the market and that they should be around for a long time:

clip_image003 clip_image005 clip_image007 clip_image009 clip_image011 clip_image013

Let’s Encrypt is already trusted by most browsers today. To achieve this already in the early stages, Let’s Encrypt’s intermediate Certificate Authorities have been cross-signed by IdenTrust. Eventually, when enough browsers trust Let’s Encrypt natively, they will stand on their own. Read more about the cross-signing here.

The certificate issuance is based on Domain Validation, which means that you have to prove your ownership of a domain name by creating a publicly accessible file under that domain name. You are then allowed to request a free SSL certificate for that domain name. The protocol used is called ACME (not the best name if you ask me, since it makes me think of the cartoon Road Runner).

The validity time of certificates from Let’s Encrypt is shorter, only 90 days instead of the usual 1-3 years for SSL certificates. Read why here. But since re-enrollment is automatic (and free) it should not be an issue.

There are currently over 8.6 million unexpired certificates issued by Let’s Encrypt. See more statistics here.

Update 2016-10-19: Today they reached 10 million!

In this blogpost I chose to go the ACME client letsencrypt-win-simple. It is limited to IIS but is very simple to use. There are many different clients for different operating systems, web servers and languages that you can choose from.

Note that the certificate will have the Enhanced Key Usage Server Authentication and Client Authentication, which means that it also can be used for other things than just web servers, such as VPN servers, email servers etc.

The steps

First the basic setup. I installed a Windows Server 2016 (as an Azure VM, but that is not really relevant here).

I installed the role Web Server (IIS), no other roles or features are needed.

I created a new Web Site called certdemo that points to the folder C:\certdemo:


I configured the site binding to use the host name and the port 80. The tool I am using will scan IIS for bindings based on host names, so you need to make sure that web sites you want to enroll certificates for has host name configured:


If I browse that URL I can access the site over HTTP:


But if I try to access it over HTTPS it fails, which is expected since no binding or certificate for this exists:


Next, I downloaded the zip-file containing the letsencrypt-win-simple files. The latest version at the time of writing this blogpost was v1.9.1 and is about 4 Mb:


Extract the files from the zip archive. Do not use a temp folder that might be deleted or that is hard to find. The application will be regularly run from that folder going forward (for the automatic re-enrollments). I chose C:\letsencrypt-win-simple:


Note the file letsencrypt.exe.config here, it will be referenced later in this post. It contains some setting that you might want to modify before running the tool. You can search for that file name in this post to find them.

Run letsencrypt.exe as administrator:


Enter an email address that will be used to send notifications if renewal will fail. I have not received ANY unrelated emails or spam to that address:


Agree to the Subscriber Agreement by typing Y (after reading it thoroughly of course):


Now a configuration file and a secret key is created. These will be used for certificate requests going forward. The files are stored in the following location:


Note: This location can be modified by editing the setting CertificatePath in the file letsencrypt.exe.config before running the tool.

Now I type A to get certificates for all hosts (which in my case is only one):


Below you can see the Domain Validation actually being performed for you automatically:

  • It receives a Challenge Type http-01
  • It writes the challenge answer in a file in a new subfolder called \.well-known\acme-challenge
  • It configures IIS to allow that folder to serve files without file extensions
  • It submits the answer
  • When the challange answer is validated by Let’s Encrypt it deletes all the files related to this validation:
    Note: You can disable the deletion of these temporary authorization files and folders by editing the setting CleanupFolders in the file letsencrypt.exe.config before running the tool.


Now the client performs the following steps:

  • It creates a certificate request (the private key is created locally and never leaves your computer)
  • It saves the signed certificate
  • It saves the certificate of the issuing CA (needs to be installed on the IIS)
  • It adds the certificate to the computer’s WebHosting certificate store (can be modified, see later in this post)
  • It adds HTTPS binding on the web site, using the new certificate
  • It creates a Scheduled Task that will run once a day to see if the certificate is older than 60 days
    Note: You can modify how many days after issuance renewal shall occur by editing the setting RenewalDays in the file letsencrypt.exe.config before running the tool. Leaving it at 60 gives you 30 days to troubleshoot before the 90 days are up.


Now it asks for credentials for the scheduled task to run with. Use an account that has NTFS write permission on the web sites root directory, since it will need to perform a challenge/response on every renewal:


After it has configured the Scheduled Task, I pressed enter and the command prompt closed:


Now we are done.

The result? Going back to the HTTPS version of my web site (that failed before) you can see that it now works, without warnings of any kind:


That’s not too bad, considering it didn’t take long, it will be automatically renewed and did not cost me a single penny.

Behind the scenes

Ok, let’s look at the changes this tool made to the server.

You can see the installed certificate in the Web Hosting certificate store. The Web Hosting certificate store was introduced in IIS on Windows Server 2012 and is similar to the Personal store, but it was designed to support a much higher number of SSL certificates without a noticeable impact on the performance of the server, since certificates here are only loaded into memory on demand.
Note: You can modify in which container the certificate should go into by editing the setting CertificateStore in the file letsencrypt.exe.config before running the tool. You can also manually move/copy the certificate to other certificate stores after it is created.


By double-clicking the certificate you can see that the certificate has a validity time of 90 days:


In IIS Manager you can see the new binding using the default post 443:


and verify that the new certificate is configured:


You can see the created Scheduled Task


and its corresponding action:


You can also see all the files that were created during enrollment:


Note that the certificate (including its private key) is available here. The .pfx version can be imported on any machine you chose. By default, there is no password set on the .pfx (just leave the password field empty when importing). You can set a password to be used for the pfx file by editing the setting PFXPassword in the file letsencrypt.exe.config before running the tool.

I hope you found this primer on Let’s Encrypt together with IIS useful.

Please test this before performing this in production environments, especially if you use a non-English version of the OS, have multiple web sites and/or use non-default ports.

Let me know if you have any questions.

Posted in Okategoriserade | 1 Comment

Links from my Windows Security and ATA session

2016_10_04 - EMS ATA

A few days ago I spoke about IT security in general and Advanced Threat Analytics in particular at Microsoft’s headquarter in Stockholm.

I showed a few sites and was asked to share them. So here they are:



Norse is a company that has over 8 million sensors all over the internet that detects attacks. They visualize the current attacks on a world map, which is available here:

World’s Biggest Data Breaches


Over a decade of data breaches are visualized in this interactive map, where you can sort, color code and click for more information:

‘;–have i been pwned?


Security expert Troy Hunt gathers and verifies credentials in data leaks, and gives you the possibility to search for your email address to see if it was present in any of the confirmed leaks. You can also subscribe to alerts if your address appears in a future leak and if you can prove ownership of a domain you can subscribe to alerts for all addresses in that domain:



The entire IPv4 network is continuously scanned for exposed services and the result is stored in a searchable database. If a bug or weakness is found in a particular software version, all public servers using that exact version can be immediately found and exploited, which makes quick patching very important:

Posted in Okategoriserade | 1 Comment

SSL Certificates and SAN – What domain names are valid?

An SSL certificate has a field called Subject. The Subject field contains the domain name that the certificate is valid for. Subject can only contain one domain name:



The field Subject can have more information, like the screenshot below, but still only one domain name:


An SSL certificate can also contain an optional field called Subject Alternative Names, or – as it is more often called – a SAN field. The SAN field contains one or multiple domain names that the certificate is valid for.


Note that in this example I only have one single SAN name. You can have many domain names in the SAN field of a certificate.

A common misconception around this is that a certificate with both Subject and SAN is valid for all domain names that are present in both of these fields. But if an SSL certificate has a SAN field, then SSL clients are in fact supposed to ignore the Subject field and look only in the SAN field for a domain name match.

This behavior is clearly specified in the RFC for HTTP Over TLS:

“If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used.”

In other words: If SAN exists, use only that. If no SAN exists, use Subject.

To see this behavior in action, see my short video below [52 sec], in which I use the certificate from the screenshots above on two different websites: and Can you predict what will happen?
[the video has no audio]

Since the Subject field is not used when using SAN, it can be set to anything, it could in fact be empty.

Perhaps a new best practice would be to set the Subject to something that would avoid the risk of this confusion whenever a SAN is used, like this certificate:


Posted in Certificates, PKI, SAN, SSL | Tagged , , , | Leave a comment

Get a free publicly trusted SSL-certificate


This blog post will guide you through the steps of obtaining a publicly trusted SSL certificate with up to 5 domain names, at no cost. There are no hidden costs, ads or referrals involved.

You do need to be able to verify that you own the domain name that the certificate will be issued for. You can do this by either receiving a verification code via email (sent to specific administrative email addresses of the domain) or the ability to publish a text file with a verification code on a webserver running on that domain.

I am using the Chinese certificate provider WoSign. Before you stop reading just because of this, consider that their ONLY involvement in this is procedure to sign your public key. They never see your sensitive private key, which is created on your computer and never leaves your control at any time.

Didn’t you know that your Windows computer most likely already trusts WoSign Root CA? Read my short blogpost Which Root CAs do you really trust?

If you want to verify that your client really trusts certificates obtained using this guide, please visit this link:  You should not receive any certificate warnings. If you do, please let me know what browser/device you are using via the comment section below.

There are other ways to obtain free SSL certificates, such as Let’s Encrypt and StartSSL, but at the moment I prefer WoSign, since they allow you to add 5 SAN attributes for free.

Ok, lets go.

Create the key pair

The best option, to reduce the number of steps and also the risk of exposing the private key of the certificate, is to create the key pair directly on the computer that will actually use the certificate. But you can export the certificate and private key when you are done, so you can use any trusted Windows computer for the enrollment process. If you plan to use multiple SAN names, it’s likely that you must export the certificate to other computers anyway.

Normally you specify attributes when creating the key pair and the corresponding CSR (certificate signing request), such as Subject, Validity Time, SAN, Key Usage and so on, but WoSign will ignore all attributes in the CSR, and only use the public key. You specify the attributes in the enrollment flow at WoSign instead.

Certificate requests can be created in many ways, in this guide I am using the MMC snap-in.

Run certlm.msc to open the local certificate store for the computer.

Right-click Personal / Certificates, expand to All Tasks / Advanced Operations and click Create Custom Request:


On the Before You Begin page, click Next:


On the Select Certificate Enrollment Policy page, click Next:


On the Custom Request page, select (No template) Legacy key, make sure that the Request format is PKCS #10, and then click Next:
Note: I choose Legacy key for compatibility reasons, you might want to choose CNG key if you are sure that your services are compatible with this.


On the Certificate Information page, click on the down-arrow next to Details and then click Properties:


Click the Private Key tab. Click the down-arrow next to Key options and change the key size to 2048. Optionally select Make private key exportable (which I recommend, see the update at the bottom of this post why), then click OK:
Note: No other certificate information needs to be entered at this point.


Back at the Certificate Information page, click Next

On the Where do you want to save the offline request? page, enter a path and filename for your certificate signing request, make sure the File format is Base 64, then click Finish:


Now we have created a key pair and a Certificate Signing Request.


Create the certificate at WoSign

Direct your browser to the following URL:

Add the domain names you want to have a publicly trusted SSL certificate for. Make sure that the cost remains zero (US$0):


You may add additional domain names and also extend the certificate validity to 3 years, but that means that the certificate will no longer be free, and that is not the topic for this blogpost. Note that the cost is not updated until you click outside of the Domain name textbox.

Notice that I added domain names from two different domains, and, just to show how domain verification looks in this scenario.

Now you have to either create an account or login with an existing one. WoSign helps you determine if you created an account with them when you fill in your email address. I use a dedicated email address for this, but I have never received any email from them after enrolling the certificate.

If you have an account, it will look like this (you need to click outside of the Email textbox to trigger the check):


Click on the link forget password? to reset your password (it should be forgot, I know).

It you have not registered an account with the email you provide, you will instead be given the option to Send Verification Email:


Click the Send Verification Email button:
Note: This will start a 30 second countdown, but don’t panic, the only thing that will happen when the countdown reaches zero is that you will have the option to resent the verification code.


The verification email might take a 5-10 minutes to show up in your Inbox, do not request a new verification to fast.

Copy the verification code from the mail that you eventually receive:


Paste the Verification code in the field Verification code.

Enter an Account password for your WoSign account.

Enter the captcha. If it is hard to make out the characters you may click change it to get a new one (it will not reload the page or remove the other info you have entered).

Check the I have read and agree checkbox (you read the agreement, right?  Smile)


Click the Submit request button.

You are now taken to a page that looks like this:’’


If you see Chinese characters, click on the link called ENGLISH at the top of the webpage.

At this point we have created an “order” for a free certificate and supplied the names we want in the certificate, but we have yet to verify that we own the domains and to supply the public key we created earlier.

Click on the link Domain Control Verification.

We can now prove that we own the domain by either using special email accounts (that hopefully are reserved to admins of the domain):


or by placing a special file on the webserver:


I will continue with email verification in this guide.

Select the email address you have access to and click the Click to send verification Email button. A countdown similar to the one when we created the WoSign account appears. Wait until you receive the verification email, that will look like this:


The sender is, remember to also check your spam mailbox.

Enter the verification code in the Verification Code field. Also complete the captcha and then click Verify Now:


If the verification succeeds, you will be prompted to verify the next domain (assuming that you entered different domains when requesting the certificate):


The verification of the next domain looks identical, so I do not show those steps here.

Note that once you verified your domain you can later request new certificates (within the same domain) without the verification step, which makes it much easier.

When all domains are verified you are taken to the Generate the Certificate Signing Request(CSR) page. This is a bit misleading, since we do not want the generate the CSR at this point, we want to submit the CSR we have already created.

Open the previously created CSR-file in notepad and copy all of the text:


Make sure that Option 2:Submit the CSR is selected. If you choose Option 1, WoSign will create the public and private key for you, and we do not want this.

Paste the text content of the csr-file in the textbox that says Please paste Certificate Signing Request.

Click Check CSR and make sure the text box on the right says

Encryption algorithm:RSA
Key length:2048bite     (yeah, should be “byte”)


Remember that the file only contains the public key, the sensitive private key is still safely stored on your computer that created the request.

Click the Submit button.

Now your certificate should be issued. Click on the link in the blue box to download a zip file containing your signed certificate:
Note: You will also get an email saying that the certificate is ready for collection. You can ignore this mail.


You will get this message:


This warning is only relevant if WoSign generated the private key and the CSR, the public part of the certificate will be available for download when you login with your WoSign account:


The downloaded zip file contains 4 other zip files, with the certificate and it’s issuers certificates in formats optimized for 3 different webservers:

for Apache

for IIS

for Nginx

for Other Server


Import the certificate

The last step is to import the signed certificate to the server that created the CSR.

Extract the file

On the server that created the CSR, run certlm.msc to open the local certificate store for the computer.

Right-click Certificate Enrollment Requests / Certificates and click All Tasks / Import:


Note: There are other ways to import a certificate, but this way makes sure that the waiting private key and the imported certificate are correctly associated.

On the Welcome to the Certificate Import Wizard page, click Next:


Browse and select to the file


Change to Automatically select the certificate store based on the type of certificate and click Next:


On the Completing the Certificate Import Wizard page, click Finish:


You should see the message The import was successful:


You now finally have a publicly trusted SSL-certificate (with up to 5 domain names), all without paying a single penny:


If you export the certificate you will have the option to include the private key (if you selected this option earlier):


Here are some screenshots of the certificate:





Known issue with IIS

If the certificate is flagged as untrusted by clients when using the certificate in IIS, try importing the following certificates – that are included in the zip file – into the Intermediate Certification Authorities / Certificate (only on the IIS server itself!):

  • 1_cross_Intermediate.crt
  • 2_issuer_Intermediate.crt


The issue here is that when a client initiates a SSL handshake, IIS gives the client all certificates in the certificate path, not only the server certificate. If the Issuing CA is not present in the local store (on the IIS server) it does not sent it to the client. It doesn’t matter that both IIS and the client easily could locate the Intermediate certificate using the AIA attribute in the server certificate.

Note that no changes needs to be made on clients and that the warning it not because the certificate is not trusted, it is that the client cannot find the intermediate CA certificate and therefore cannot identify what Root CA certificate to verify trust for. When it is added to the IIS and given to the client at the SSL handshake, the client “realize” that they trusted the server certificate all along.  Smile

Phew, this became a much bigger blog post than I first imagined. I hope you found it useful!

=== Update 2016-06-03 ===

Some services has issues with the certificate, such as TMG (says Incorrect Key Type) and Exchange OWA (you are returned to the login page when logging in).

Assuming that you made the private key exportable in the first place you can solve this by exporting the certificate and it’s private key to a pfx, import that pfx into Firefox’s certificate store and then do a backup of that certificate in Firefox. This will create a new pfx, that when imported will work with TMG and Exchange OWA.

Note that the issues are not because the certificate is CNG, which many seems to suggest. Remember that we chose Legacy key a few steps up (which is the same as CSP) and not a CNG key:


Posted in Certificates, PKI | Tagged , , , | 2 Comments

My Advanced Threat Analytics session (in swedish)

About a month ago I gave a talk about Microsoft Advanced Threat Analytics (ATA) at TechX, a Microsoft event here in Sweden.

The session is now posted on YouTube and available for everyone to see. Please note that the talk is given in swedish.

Unfortunately the first few minutes – where I talked about the history of ATA – was not recorded.

If you only want to see the ATA demos, jump directly to 23:30.


Posted in Okategoriserade | Leave a comment

Installing CA via PowerShell : “-Whatif” not working

I just installed a CA server for testing, and noticed something strange.

First I installed the binaries with the cmdlet Add-WindowsFeature, without any issues:


When I was about to install and configure the CA role with the Install-AdcsCertificationAuthority cmdlet, I first wanted to see what the default values would be for parameters like CAType, KeyLength and ValidityPeriod, if I only supplied CACommonName and HashAlgorithmName.

According the the technet article about the Install-AdcsCertificationAuthority cmdlet (see here), I should be able to use -Whatif:


So I simply added “–Whatif” at the end:


I never saw any values in the output, but I figured that “ErrorId = 0” was a good sign and that the command at least would work as expected when I ran it without –Whatif.

I then removed “Root” from the CACommonName and ran the command again, this time without -whatif, but lo and behold, I got an error message saying that the CA was already installed!


At first I thought that WhatIf might be case sensitive, but it’s not:


So be careful when using -Whatif together with Install-AdcsCertificationAuthority.

Posted in Okategoriserade | Leave a comment

Require SSL on NDES admin site via PowerShell

Best Practices from Microsoft when deploying Network Device Enrollment Service (available here) states:

“Always set up the administrator site with SSL-only configuration. (Disable http access to this site.)”

This is to protect the sensitive One Time Passwords that are transmitted between the server and the client’s browser.

The path that you want to enable SSL requirement for is:
https://<FQDN of NDES Server>/certsrv/mscep_admin

Note that the path for NDES certificate requests should not be SSL enabled:
https://<FQDN of NDES Server>/certsrv/mscep/mscep.dll

If you have installed both the Network Device Enrollment Service and the Certificate Authority Web Enrollment role services, the virtual directory certsrv/mscep_admin is available in IIS Manager:


You can easily enable SSL via the GUI, here is one of many guides explaining how.

However, if you only install the Network Device Enrollment Service role service (and do not want to add Certificate Authority Web Enrollment), the virtual directory certsrv is not created in IIS:


This means that you cannot enable SSL requirement via the IIS Manager GUI.

The web server still answers requests to this path, and you can see the virtual paths in the Applications view:


But unfortunately you cannot configure SSL requirement in the Applications view.

The solution? Use PowerShell and the sslFlags setting.

To see the current SSL configuration on the CertSrv/mscep_admin site:

Get-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -location ‘Default Web Site/CertSrv/mscep_admin’ -filter “system.webServer/security/access” -name “sslFlags”


To require SSL for the CertSrv/mscep_admin site:


Set-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -location ‘Default Web Site/CertSrv/mscep_admin’ -filter “system.webServer/security/access” -name “sslFlags” -value “Ssl”


Note that the commands above do not include the name of the server, so they do not have to be modified to work in your NDES implementation (unless you manually chose another website than Default Web Site for NDES). Also note that you need a valid certificate installed on the server before requiring SSL to avoid error messages in the browser.

Here is the output when the commands are executed:


Here is the result when accessing the NDES admin page over http, after enabling SSL requirement:



Accessing it via https works:


The path for NDES certificate requests still works over http:


To revert back to the default configuration:


Set-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -location ‘Default Web Site/CertSrv/mscep_admin’ -filter “system.webServer/security/access” -name “sslFlags” -value “None”

Posted in CA, Certificates, NDES, PKI, SCEP | Tagged , , , | 3 Comments

Forced password change at next logon and RDP

If your AD account has the “User must change password at next logon” option enabled:


and you try to logon to a RDP session (with correct credentials):


you might encounter this error message:

“You must change your password before logging on the first time. Please update your password or contact your system administrator or technical support.”

This is a classic catch 22 issue: You have to logon to change you password, but you cannot logon until you’ve changed you password.

If you have access to a “normal” network connected Windows client you can change the password that way, but what if you only have RDP access?

Client side

Well, if the server allows it, you can temporary disable “Credential Security Support Provider (CredSSP)” in the RPD client. This disables Network Layer Authentication, the pre-RPD-connection authentication, and therefore enables you to change your password via RDP. CredSSP is enabled by default in the RDP client on Windows Vista and forward.

There is no option to disable CredSSP in the RDP client, so here is how you have to do it:

  • Start mstsc.exe
  • Click Show Options
  • Click Save As


  • Call it ChangePassword.rpd (or anything you’d like, but avoid the name Default.rdp)
  • Open the saved ChangePassword.rpd in Notepad
  • Add a new row at the end with the following text:


  • Save the rdp file
  • Double-click the rdp file
  • Enter the name/IP of a domain connected computer with RDP enabled

Instead of the local Windows Security prompt (the second image in the blog post) you should see a Windows Logon screen on the remote computer (if not, read on anyway):


If the account you log on with at this point has the “User must change password at next logon” option enabled, you get notified about that:


By clicking OK you get the possibility to change the password (yay!):


After changing the password you get confirmation about the change:


Clicking OK logs you in.

In fact, you do not need to have access to sign in through RDP, in that case this shows up, but only after you successfully changed your password:


Delete the ChangePassword.rdp file when you are done (or at least do not use it until you are forced to change your password again), since disabling CredSSP lowers the security of RDP connections.

If the server requires CredSSP

If the server does not allow you to disable Credential Security Support Provider, you get this error message when connecting:


In that case, try connecting using the FQDN ( and not only DC01) or connect to other servers that might allow you to disable CredSSP. As I mentioned above, you don’t have to have access to actually logon to the server.

Server side

You can also disable CredSSP on the server side, but since that lowers the security on all RDP connections to that server it is not recommended.

If you chose to do this anyway, you do it either by de-selecting “Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)” in System Properties:


Or if you run the Terminal Server Role:

  • Open Terminal Server Configuration
  • Open RDP-Tcp configuration page
  • On the General tab, set the Security Layer to RDP Security Layer


Note that if you already have an existing access to a server (with the account you need to change the password with) you could just change your password in that session by pressing Ctrl-Alt-Del (or Ctrl-Alt-End in an RDP connection) and choosing Change a password:


I hope this post helped.

Posted in Okategoriserade | 16 Comments

Keep your OneDrive storage size

A while back Microsoft announced that the storage in the free version of OneDrive will be decreased from 15 GB to only 5 GB. The bonus storage of 15 GB extra when activating Camera Roll Backup in OneDrive will also be removed.

This was not well received by users, and Microsoft is now offering users to to keep the old storage size and the camera bonus when the new limitations are rolled out.

All you have to do is go to this link:

After you have logged in and authorized the application called, you should see this message:


This offer must be redeemed before January 31 2016.

Note that this tip is about the consumer version called OneDrive, not the enterprise version, called OneDrive for Business.

Posted in Okategoriserade | Leave a comment

AppLocker Bypass Checker

One of the Default Rules in AppLocker allows everyone to execute everything in the folder C:\Windows:


The reasoning behind this must have been that a non-admin Windows-user should not have write permissions anywhere in that folder. But as it turns out that is not the case.

I wrote a PowerShell script that tries to copy an executable to every folder in Windows and (if the copy succeeds) tries to execute it. At the end it will show what folders are at risk for AppLocker bypass and must be managed accordingly. Preferably by creating exceptions in the default Allow Rule or by adding a new Deny Rule that includes these folders. I would not recommend messing with the NTFS permissions on folders in C:\Windows (or where your %systemroot% is located).

I chose mstsc.exe as the executable (it’s short for Microsoft Terminal Services Client), since it is small, built-in and can run multiple instances. During the test you will see instances of this showing up:


Do not close them manually, as they are enumerated by the script at the end. They will be closed automatically by the script.

Remember to run the script as a user. Admins have another Default Rule that enables them to run anything anywhere. And if you wanted to bypass AppLocker as an admin (in case the default Admin Rule was removed) you could just stop the service “Application Identity” that AppLocker relies on to function properly.

You might have an Execution Policy that prevents you from running the script. In that case you have (at least) two simple options:

  1. Open the script in Windows PowerShell ISE (by right-clicking the script and choosing Edit), select the entire script with Crtl-A and then press F8 to run the selected code.
  2. Run Powershell with the option “-ExecutionPolicy Bypass”:

This is also a good reminder that Execution Policy is NOT a security feature. It is meant to prevent accidental execution of scripts. Here are 13 additional ways to bypass it:

I did notice that I got these warnings when bypassing Execution Policy (but not when changing the Execution Policy to RemoteSigned). Just ignore them as well:


You will see some errors when the script could copy a file, but not execute it:image
You can ignore these too.

At the end you should see something like this (in this case it was run on a Windows 10 build 10565):


Download the script here:

Don’t forget you might need to validate all the Program Files subfolders in a similar fashion if you keep that Default Rule.

Standard Disclaimer: I am NOT a coder. I am not responsible for what this script does. Do a code audit of the script if you run it in a sensitive environment.

Please leave any feedback you have as a comment to this post.

Posted in AppLocker | 9 Comments