Configure OSD with 802.1x authentication

Many organisations are making the move from unprotected networks to secure ones using technology such as 802.1x.  Unfortunately, SCCM does not currently natively support 802.1x authentication for either PXE boot or boot from USB so the following post additional configuration that was completed in order to successfully deploy a machine on situated on the protected network.

This deployment is a multi-stage configuration, comprising of:

  1. Configure the ISE
  2. Initial 802.1x configuration to allow the task sequence to be discovered
  3. A profile configuration on ISE to allow the new devices to connect
  4. Unattend file reconfiguration to allow Windows, once installed, to discover the network

Cisco ISE Configuration

The first stage is to create an access profile for the authentication. It is recommended to only allow access to the following areas, required to start the process and deploy the machine:

The requirements are:

  1. Internal certificate authority servers
  2. Domain Controllers
  3. System Centre Configuration Manager

Using the following task list, create an authorization policy:

  1. Log into ISE as an account with enough privileges to create profiles
  2. Navigate to Work Centres > Network Access > Policy Sets
  3. Click the > icon on the wired access policy set
  4. Expand Authorisation Policy
  5. Navigate to the line above where you want the policy to be applied
  6. Create a new policy, with the below settings

  1. For network access results in security groups, choose Create a New Security Group and when the Create New Security Group screen opens, perform the following steps:
    • Enter a name and description (optional) for the new security group.
    • Check the Propagate to ACI check box if you want to propagate this SGT to ACI. The SXP mappings that are related to this SGT will be propagated to ACI only if they belong to a VPN that is selected in the ACI Settings page.
    • This option is disabled by default.
    • Enter a Tag Value. Tag value can be set to be entered manually or autogenerate. You can also reserve a range for the SGT. You can configure it from the General TrustSec Settings page (Work Centers > TrustSec > Settings > General TrustSec Settings).
    • Click Submit. For more information, see Security Groups Configuration.
    • Ensure the security groups restrict access only to the servers that are required

Initial 802.1x Configuration

To perform the initial 802.1x based configuration within a PXE environment, a pre-start batch file was created to:

  1. Set Wired Autoconfig (dot3svc) service startup to Auto
  2. Start Wired Autoconfig
  3. Import Configuration Profile
  4. Import Certificates
  5. Force adapter authentication event

To facilitate this, the following needed to be created:

  1. LAN Configuration Profile
  2. Prepare Certificates
  3. Create the deployment script
  4. OSD Injection
  5. Create a boot image
  6. Configure a task sequence for 802.1x

The section below shows how this was achieved, to allow updates to be carried out should they be required:

LAN Configuration Profile

To complete this process, the following is required:

  1. Locate, and use, a clean machine that doesn’t have IEEE 802.1x Policies applied.
  2. In Windows, go to Network Connections pane in the Control Panel
  3. Right-click the adapter and select properties

  1. From there, click on the Authentication tab.
  2. Configure as below:
    • Main properties:

  • Main properties:

  • Click OK to return the main settings
  • Select Settings under choose a network authentication method  

  • Configure as above. Then select configure under select authentication methods

  • Configure as above.
  • Click OK on each window until the properties are closed.
  • Open an administrative command prompt, and run “netsh lan show interfaces”
  • This will return the following:

which highlights the 802.1x configuration is applied, but unable to connect (this machine is not on an 802.1x network)

  • Take note of the interface name that was configured. In the example above, it is “Ethernet”
  • Run “netsh lan export profile folder=. interface=”Ethernet”” where Ethernet is the name of the adapter recorded in the previous step.
  • This will export the profile:

Once completed, an XML will exist containing all the settings previously configured. Save this as “InterfaceProfile.xml”

The below shows the configurations for the example given above:

[xml]<?xml version="1.0"?>
<LANProfile xmlns="">
<OneX xmlns="">
<EAPConfig><EapHostConfig xmlns=""><EapMethod><Type xmlns="">25</Type><VendorId xmlns="">0</VendorId><VendorType xmlns="">0</VendorType><AuthorId xmlns="">0</AuthorId></EapMethod><Config xmlns=""><Eap xmlns=""><Type>25</Type><EapType xmlns=""><ServerValidation><DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation><ServerNames></ServerNames></ServerValidation><FastReconnect>true</FastReconnect><InnerEapOptional>false</InnerEapOptional><Eap xmlns=""><Type>13</Type><EapType xmlns=""><CredentialsSource><CertificateStore><SimpleCertSelection>true</SimpleCertSelection></CertificateStore></CredentialsSource><ServerValidation><DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation><ServerNames></ServerNames></ServerValidation><DifferentUsername>false</DifferentUsername><PerformServerValidation xmlns="">false</PerformServerValidation><AcceptServerName xmlns="">false</AcceptServerName></EapType></Eap><EnableQuarantineChecks>false</EnableQuarantineChecks><RequireCryptoBinding>false</RequireCryptoBinding><PeapExtensions><PerformServerValidation xmlns="">false</PerformServerValidation><AcceptServerName xmlns="">false</AcceptServerName></PeapExtensions></EapType></Eap></Config></EapHostConfig></EAPConfig>

Prepare Certificates

This will need to be redone under the following situations:

  1. Root Certificate is updated
  2. Intermediate certificates are updated
  3. Machine certificate expires

One a machine that is AUTHENTICATED to the 802.1x domain, run the following:

  1. Root CA certificate export:

 Open an administrative PowerShell session, and run:
[shell]Get-ChildItem -Path cert:LocalMachineRoot[/shell]
To identify which ROOT certificate you need to export. Note the Thumbprint
Once identified, run the following to export the root certificate to a CER file
[shell]$rootcert = (Get-ChildItem -Path Cert:LocalMachineRoot6E9506C5517FF7B630EAC3CCDCE9C72CFDEF8620)
Export-Certificate -Cert $rootcert -FilePath .root.cer[/shell]
All together, this should look similar to the below:

       2. Intermediate CA certificate export:
Open an administrative PowerShell session, and run
[shell] Get-ChildItem -Path cert:LocalMachineCA[/shell]
to identify which intermediate certificate you need to export. Note the Thumbprint
Once identified, run the following to export the certificate to a CER file:

[shell]$intcert = (Get-ChildItem -Path Cert:LocalMachineRoot6E9506C5517FF7B630EAC3CCDCE9C72CFDEF8620)
Export-Certificate -Cert $ intcert -FilePath .intermediate.cer[/shell]
 All together, this should look similar to the below:

  3. Machine certificate
Open an administrative PowerShell session, and run
[shell]Get-ChildItem -Path cert:LocalMachineMy[/shell]
to identify which machine certificate you need to export. Note the Thumbprint
Once identified, run the following to export the certificate to a CER file:
[shell]$mypwd = ConvertTo-SecureString -String "1234" -Force –AsPlainText
Export-PfxCertificate -Cert cert:LocalMachineMyDCFC5EA138BCA5E5DDD2B22A4E86704CFA0E0EC8 -FilePath .endpoint.pfx -ChainOption EndEntityCertOnly -NoProperties -Password $mypwd[/shell]
All together, this should look similar to the below:

Create the deployment script

The following code details the batch file that was created for this purpose. This batch file works in associated with the previously created XML profile and certificates.

[shell]@Echo off
REM start the Wired AutoConfig service
Net Start dot3svc
REM Import Root certificate
echo Applying Certificates
certutil.exe -addstore Root "%~dp0root.cer"
certutil.exe -addstore CA "%~dp0intermediate.cer"
REM Import Computer Certificate
certutil.exe -ImportPFX -f -p "yourpassword" "%~dp0ComputerAuthCert.pfx"
REM Import Computer Auth Profile to all LAN interfaces
echo Configuring Interface Profiles
netsh lan add profile filename="%~dp0ComputerAuthProfile.xml" interface=*
REM Force all interfaces to reconnect
echo Reconnecting Interfaces
netsh lan reconnect interface=*
REM Discover the Interface names, then disable and re-enable them
echo Discovering, disabling then enabling interfaces
netsh lan show interfaces |findstr "Name" >c:interfaces.txt
FOR /F "tokens=1,2 delims=:" %%G IN (c:interfaces.txt) DO (
netsh interface set interface name="%%H" admin=DISABLED
netsh interface set interface name="%%H" admin=ENABLED
REM Pause the script for 30 seconds to allow the adapter to Auth
echo Wait 30 seconds…
ping localhost -n 30
REM Show the interface to see the status and show profiles to see which profile is applied.
netsh lan show interfaces
netsh lan show profiles[/shell]

OSD Injection

Once this point is reached, the following files should be available:

  1. Configure802-1x.cmd (the above batch script)
  2. Endpoint.pfx (the machine certificate exported with private key)
  3. InterfaceProfile.xml (the 802.1x authentication profile for the network adapter)
  4. Intermediate.cer (the environments intermediate certificate)
  5. Root.cer (the environments root certificate)

The files will now be injected into the boot image using the OSDInjection.XML method.

You can find your OSDInjection.XML on your ConfigMgr primary server under [SCCM Install directory]binx64OSDInjection.XML. This file is a manifest that SCCM uses to inject specific files into your boot image. There are several sections in the XML, so be sure to make your entries in the correct location.

To configure this, the following actions are required:

  1. Create a new folder named Custom under [SCCM Install directory]OSD
  2. Add the five files mentioned previously into this folder.
  3. Navigate to the OSDInjection.xml file

4. Edit the file, entering the details for the files mentioned above.
[xml]<File name="Configure802-1x.cmd">
<File name="InterfaceProfile.xml">
<File name="endpoint.pfx">
<File name="intermediate.cer">
<File name="root.cer">

5. This detail needs entering in the required location under Injection Files -> Architecture (either x86, x64 or both) -> Filelist (source=”SCCM”)

Creating a deployment package for the required files

In order to use the created files during the Windows installation, the files are required to be added to a package for later use.

To do this, following the below tasks:

  1. In SCCM Configuration Manager, navigate to software library, packages and create a new package

  1. Give the package a name, in this instance it is named OSD-802-Authentication
  2. Enter the location of the files saved previously (where SCCM can access them), click Next

  1. Select Do note create a program, and click summary, then finish.

Creating the boot image

Once at this point, the boot image that will drive the deployment of machines can be created. To do this, perform the following in the SCCM Management Console:

  1. Navigate to software library, operating systems, boot images.
  2. Right click on “Boot Images” and select “Add Boot Image”

  1. Enter the path to your template WIM file

  1. Populate the general information

  1. Select Next, then Summary to complete

  1. Once complete, highlight the new Boot Image, right click and select properties
  2. Select Optional Components

  1. Add the following components:W
    • inPE-Dot3Svc
    • WinPE-DISMCommandlets
    • WinPE-NetFx
    • WinPE-PowerShell
  2. Click OK to close

  1. Click OK to save and close.
  2. The following message will appear, select Yes:

  1. Wait for it to complete.
  2. Right click the boot image, and select Properties again.
  3. Navigate to the customization tab
  4. Select the “Enable prestart command” selection box
  5. Enter the following details:

  1. Select OK to close
  2. Distribute the content, as required

Configure a task sequence for 802.1x

It is recommended, that, for testing, a new task sequence is configured to allow easy modification. To do this, the below steps are required to be completed using the SCCM Configuration Manager:

  1. Navigate to software library -> Operating Systems -> Task Sequences
  2. Select an appropriate task sequence, then right click, and select copy

  1. Once created, edit the properties
  2. Select Advanced, and change the boot device to the one created for 802.1x

Once this is complete, the environment is now in a position to test by deploying a USB ISO. To do this, the below steps are required to be completed using the SCCM Configuration Manager:

  1. Navigate to software library -> Operating Systems -> Task Sequences
  2. Highlight the authentication test task sequence, then select “Create Task Sequence Media”

  1. Select Bootable Media, click next

  1. Select Dynamic Media, click next

  1. Select CD/DVD set, then Browse, navigate to the location to save the ISO file

  1. Select “Enable unknown computer support” then select next

  1. Select the required Boot image, which was created earlier in this document

  1. Although not strictly required, add in the pre-start command as below, then click next

  1. Select Summary
  2. Wait for completion
  3. Write the ISO to USB as per normal process

Once the USB is written, power up a machine that is connected to the 802.1x authenticated network.
The standard OSD screen will appear. Select Next to move to the task sequence selection screen and the batch script created earlier should run. Once it completes, the list of available task sequences will appear.
To confirm the authentication has succeeded, if you have command prompt enabled within the boot image, press F8 then type in: netsh lan show interfaces

The state of the adapter should say “Connected. Authentication Succeeded”. This shows that 802.1x authentication has been enabled.

Unattend File

So far, this process only enables the pre-installation environment to access the 802.1x network. Once Windows is deployed, and the machine rebooted, these settings no longer apply.

To ensure Windows also continues to operate on the network, an unattend.xml file is required to deploy the configuration during the “4 specialise” section.

To do this, the following tasks must be completed: 

  1. Download the Windows ADK from: This is version specific.
  2. Install “Windows Systems Image Manager” from the Windows ADK
  3. Run the WSIM
  4. Select File -> Create New Answer File
  5. The following warning will appear, select Yes:

  1. Navigate to your WIM file, and select open

  1. If this is a multi-version WIM, select the version required

  1. Generate a catalogue file if required
  2. Once this completes, right click on “components” in the answer file column
  3. Select “Insert Synchronous Command to Pass 4 specialise”

  1. Enter “cmd /c C:TempConfigure802-1x.cmd” into the window, select OK

  1. This will populate the answer file with the below:

  1. Save the answer file to “unattend.xml”
  2. Copy the unattend.xml file somewhere SCCM can access it from

Examining the XML file will show something similar to the below:
[xml]<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="specialize">
<component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
<RunAsynchronousCommand wcm:action="add">
<Path>cmd /c C:TempConfigure802-1x.cmd</Path>
<Description>Import Computer Auth Profile</Description>

Deployment Package

SCCM task sequences allow the use of unattend.xml via task sequence if the file is delivered as a package.

To do this, the below tasks must be carried out.

  1. In SCCM Configuration Manager, navigate to software library, packages and create a new package

  1. Give the package a name, in this instance it is named OSD-802-AuthUnattend
  2. Enter the location of the files saved previously (where SCCM can access them), click Next

  1. Select Do note create a program, and click Summary, then finish.

Update the task sequence

Once the packages are created, the task sequence needs to be updated to include the unattend.xml file, as well as the files required to deploy 802.1x authentication (packaged previously in this document)

To do this, open SCCM Configuration Management and perform the following:

  1. Edit the test task sequence, and locate the task which applies the operating system image
  2. Select “use an unattended or sysprep answer file”
  3. Select browse and navigate to the OSD-802-AuthUnattend package

  1. Enter unattend.xml in file name.
  2. Click Apply
  3. Add a new step located to “Run Command Line” after the OS image has been applied, but before the reboot of the machine
  4. Select Package, and select browse
  5. Select the OSD-802-Authentication package created earlier in this document

  1. Under command line, enter
    [shell]xcopy.exe ".*.*" c:Temp /E /C /I /Q /H /R /Y /S[/shell]
  2. Select OK to save and close

The second package will copy the files:

  1. Configure802-1x.cmd (the above batch script)
  2. endpoint.pfx (the machine certificate exported with private key)
  3. InterfaceProfile.xml (the 802.1x authentication profile for the network adapter)
  4. intermediate.cer (the environments intermediate certificate)
  5. root.cer (the environments root certificate)

to the C:Temp location on the OS Disk boot drive (change the path if you do not use C:). This way, when the unattend.xml stage runs “cmd /c C:TempConfigure802-1x.cmd” the files will have been pre-staged into the correct location, allowing the 802.1x authentication to complete successfully.

Once you get to this stage, everything should be in place to be able to run a task sequence over an 802.1x encrypted network. This doesn’t cover the tidy up process, but, time pending, I’ll create another post or extend this one to add it in.

Apart from that, good luck 🙂

Office Attack Simulator – Part 2

This post is part two in a series looking at Microsofts Office 365 Attack Simulator.

Part one looks at the ability Office 365 administrators have to be able to run three types of attacks on their users. These attacks are:

  • Spear-phishing
  • Brute Force
  • Password Spraying

For part one, click here.

Part two will focus on high-level mitigation’s for these types of attacks.

If you wish to jump to a related section, click one of the below links:

  1. Spear-phishing
  2. Brute Force
  3. Password Spraying

Spear Phishing

Spear phishing is an email-spoofing attack that targets a specific organisation or individual, seeking unauthorised access to sensitive information. In most cases, that confidential information is the user’s password to give attackers a platform on which to expand their efforts.

Spear-phishing attempts are not typically initiated by random hackers but are more likely to be conducted by perpetrators out for financial gain, trade secrets or other specific information you, or your company, have access too.

This type of targetted attack means that the perpetrators have usually investigated your company sufficiently to be able to pinpoint the exact user on which they wish to focus. That increased effort makes it harder to spot a spear-phishing campaign from a regular one that is generic to thousands of recipients. Often, attackers will use language and terminology the target can relate to, overcoming the trust barrier.

This focused effort makes identifying spear-phishing campaigns from a technology perspective is very hard. With most non-targetted phishing campaigns the following best practices from a technology perspective apply:

Mail Filtering – use a 3rd party mail filter in front of your email servers. This recommendation follows the defence in depth methodology, meaning, if you are using Office 365 Exchange Online Protection, consider adding additional services in front of this such as Mimecast. The more filters emails pass through before reaching the recipient, the higher the chance of full sanitisation before it arrives. Obviously having ten mail scanning applications would offer fantastic peace of mind. After the third and fourth application, however, the benefits would start to become minimal from each additional product. The cost of such an approach should also be considered when investigating.

Reputation-Based Web Filters – These can be on your firewall or installed directly on your endpoints (usually from anti-virus products). These will add an additional layer of protection between the user and the internet. Reputation-based filters will review websites against a known bad list to assess whether it is safe to allow the user to visit them. That bad list can be for multiple reasons similar to what traditional proxy servers manage. However, they can also prevent users from accessing sites they have detected as phishing. Once a user clicks on a known phishing link, the application intercepts the browser traffic and displays a notification to the user telling them they cannot go to the link provided, and why.

Unfortunately, the above two methods usually won’t stop a spear-phishing campaign against your organisation. Both systems rely on multiple triggers to alert them to problems, as well as large amounts of information. If a malicious actor targets your company, there is a high chance that you are the only company receiving the email aimed at you, and the URL will be unique. This unique method efficiently makes reputation and analysis based investigated almost redundant (in this scenario).

It is now commonly accepted that attacks of type will get through your defences. There is currently no technology that guarantees you 100% of phishing emails will be cleaned before being delivered. That leaves a single object between your company and a possible breach. The user.

This is why training your users to understand this type of attack is your best chance of defence against it. There are some excellent guidelines online, however, in general users should be looking for:

  • Correspondance from users who are asking for things out of the normal.
  • URL’s to click that are misleading (text reads, URL is
  • Emails explicitly saying don’t get in touch, I am unavailable but process this while I am out of reach
  • Emails that are suddenly urgent that you were unaware of until the email arrived.

An excellent way of measuring this type of awareness is training courses through companies such as knowbe4. They offer online courses and a mini quiz to ensure your users are fully versed in the potential hazards out there.

And, of course, test your users yourself, which is were the Spear-Phishing attack in Office 365 comes in. If you keep your users informed and regularly tested with real-world trials, this will keep awareness raised ensuring users are less likely to fall prey to this type of attack.

Gamification is a perfect play for this. Start to reward staff, create a leaderboard of sorts for people who managed to identify and report phishing campaigns of any type correctly. It could be added to monthly meetings with a small prize for the best one discovered that month, or the most discovered. All of this helps keep users interested and vigilant.

Note – Symantec recently released their “Internet Security Threat Report” for 2017. This shows that Spear-phishing is accountable for 71% of the overall attacks being conducted against organisations. That’s an incredible statistic and highlights the rapidly growing area of concern. It also shows a year on year increase of this attack vector.

Brute Force Attacks

Brute Force attacks have been around for possibly as long as the internet. This type of attack involves finding an exposed authorisation point and then continually trying passwords against a known username (or, sometimes, rotating through commonly used usernames).

Thankfully, unlike Spear-Phishing, this is something that technology has developed numerous solutions to discover, investigate and prevent unauthorised attempts of this type.

As the Attack Simulator focuses on Office 365, this document will highlight how to discover and thwart these attacks specifically in Office 365.

Multi-factor Authentication (MFA) – This is the process of having an additional layer of security after correctly entering your password (or, in some cases, before you input your password). Enabling MFA for users is a guaranteed way of preventing brute force attackers from successfully gaining access to the environment that provides MFA, should a password be guessed. However, this does mean that you have exposed user credentials, as once a malicious actor discovers that the password is accepted, they can then start to look for exposed applications that do not support MFA. Clearly, the scope of protecting Office 365 would be covered, but if the attacker finds a Remote Desktop Server that does not have MFA enabled, they then have a gateway into the environment. This drawback means MFA should not be relied upon solely.

Account Lockout Policies – There are a couple of ways of addressing this. The first, if you are on managed logins (not using Active Directory Federation Services (ADFS)), then Microsoft goes some way to watching out for Brute Force attacks. They also prevent users from password recycling from lists have previously been exposed through hacked website leaks.

For more information on password recycling and some cool tricks around it, click here.

If Microsoft detects that one of your users is being brute force attacked, they will lockout the account, as below:

This works in conjunction with MFA, which is perfect.

The next method is used to address organisations that are using AD FS, and again there are two primary ways to tackle this problem.

The first is Active Directory. Having a lockout policy in place in Active Directory will undoubtedly stall brute force attempts on your users. If brute force scripts only get to try three passwords every thirty minutes that pushes up the average time to find a password up exponentially.

It will also be highly visible, as, if a user is always being locked out, someone would be alerted to the fact. Unfortunately, this is also the downside to this method. The companies users are what drives the business, so having them locked out every ten minutes can drop productivity through the floor. And, you know it will be at the worst possible time for the user.

Investigating why accounts are being locked out also takes significant time as it could be one of (sometimes) hundreds of different systems that are locking out the account, either internally or externally.

This brings us to method two if you are using AD FS, Extranet Lockout.

With the extranet lockout feature in Windows Server 2012 R2, an AD FS administrator can set a maximum number of failed authentication requests (ExtranetLockoutThreshold) and an ‘observation window’s period (ExtranetObservationWindow). When this maximum number (ExtranetLockoutThreshold) of authentication requests is reached, AD FS stops trying to authenticate the supplied account credentials against AD FS for the set time period (ExtranetObservationWindow). This action protects this account from an AD account lockout, in other words, it protects this account from losing access to corporate resources that rely on AD FS for authentication of the user. These settings apply to all domains that the AD FS service can authenticate.

So, setting the ExtranetLockoutThreshold below the Active Directory lockout threshold alleviates the initial Active Directory lockout policy problem and allows quicker discovery of what is causing the problem. It does this by enabling the user to continue working internally. However, they would have problems accessing the external portals provided by AD FS, as they would be locked out.

Log Monitoring or Cloud App Security – Both of these items amount to the same thing. However, Cloud App Security is automated, whereas monitoring the logs is usually a manual process. For those fortunate enough to have Cloud App Security checking for Brute Force attacks should be easy.

The portal allows the creation of alerts via email and text message to administrators should certain conditions be encountered.

The image below shows and invalid password attempt registered by Office 365:

When the task is expanded, select the “New policy from search” button, to open policy editor.

Complete the top section, then under policy filters and alerts, configure as below:

Obviously entering your own 24/7 details into the email address and telephone number. 

This will ensure your on-call staff will be alerted should any user start to get locked out from your cloud services. 

A less streamlined way is log checking. This can be done manually or through automated scripts (such as PowerShell).

We won’t cover how to do that in this post (one for the future) however guidance can be found elsewhere on the internet. A good starting point to investigate is:


These are currently a little tricky to test due to the fact you should be using MFA for your logins however an internet search should assist here. As mentioned, we’ll cover all of this in another blog in the future.

If you wish to review the logs manually, you can do so by:

  1. Log in to Office 365 as an administrator
  2. Navigate to Admin Centres, Azure Active Directory Admin
  3. Select Users
  4. Select Sign-Ins

This page will allow you to traverse the log files adding filters for failed logins etc.


Password Spraying

Password Spraying is a difficult topic to address and protect against, mainly due to the secrecy necessarily people have around discussing passwords. How are users ever going to discover they have the same password without knowing what other people are using?

Unfortunately, it’s also one of the hardest to defend against as most people who are performing spray attacks will understand that you have account lockout procedures and complexity requirements on your passwords. This knowledge means, they will only try spray attacks at intervals to not lock-out the targetted accounts.

There are always multiple ways to harden against any security risk, however, this post will cover the following options:

  1. Password complexity and reset options
  2. Help-desk awareness
  3. Password recycling evasion

Password complexity and reset options A basic defence against to attempt to ensure users are not using the same password is the complexity requirements. As complexity requirements increase the likelihood of users using the same passwords decreases. Unfortunately, this adds overheads as, if you have to renew passwords every 45 days, this makes it difficult for users to manage,

One thing to remember about password complexity requirements and password reset times is they should be used in conjunction with each other. As you relax the complexity requirements, your users should be resetting their passwords more often. Increased complexity requirements give you the ability to extend the time they use their passwords for.

To understand this, it’s often worth thinking of how long your password requirements would take for a malicious actor to crack using standard brute force techniques. If your passwords are good for two hundred days, setting your passwords to expire after one hundred and eighty days (or every six months) would still leave you protected without inconveniencing your users too much.

An excellent resource to test your base requirements is by Dash Lane. The below image shows how long brute force would take using a typical password generator to crack [email protected]

This password meets all of the default Windows complexity requirements, but allows attackers to gain access within nine hours. Not great. Increasing the requirements to twelve characters, rather than eight, shifts this time exponentially and therefore would allow your users to change less often.

Help-desk awareness

Another great way of avoiding Password Spraying attacks is to train the help-desk staff to generate unique passwords every time a user requests a password reset or a new account is created.

For example, a malicious actor could follow the below to attempt to discover a crafted password spray:

  1. Malicious actor calls the help-desk with a known user account
  2. Help-desk staff reset the account to “Welcome01” and set the account to not require a reset at login (as the user is external only)
  3. Malicious actor now knows there will be multiple accounts that users haven’t reset as they have no facility to do externally.

The malicious actor now has a perfect Password Spray candidate that is more or less guaranteed to work. The actor doesn’t necessarily need to go as far as calling the help-desk, they could discover it sat in Starbucks or talking to any employee.

If help-desk staff are trained to be aware of this problem, they can generate individual passwords (possibly using a password generator) which ensure if a malicious actor does get a remote user credentials, it is limited to that one remote user allowing easier discovery and lock-down after the subsequent incident is discovered.

Password recycling evasion

This technique requires significantly more investment than any previous option. To understand password recycling, and get basic information on how to test for it, click here.

One way of implementing this in a real world scenario is adding checks into the 
Windows Password Filtering.

The Windows Password Filter feature allows you to add additional checks when a user attempts to pick a new password. The password first goes through the domain’s password complexity check. After passing the complexity check, it then gets passed through your custom check. You can have multiple checks if you’d like. The image below shows the process.


This allows organisations to deploy mechanisms to users that allows password recycling to be checked prior to the password being reset. 

This decreases the chances of password spraying attacks being successful however can be difficult to implement without an internal development team. Thankfully, as this problem is increasing in significance, vendors are becoming more focused on addressing the issue and there are a variety of free and pay to use products that will allow your company to implement these filters without writing your own.

As with everything else, if there is anything on this page you would like more information on or assistance with, get in using the form below.







Send a Message

Office 365 Attack Simulator

Brief Outline

This is the first of a two-part post on the new Office 365 Attack Simulator. This post covers accessing the Simulator and running attacks. The second post is available here.

To jump to a section to continue, click on one of the links below:

  1. Overview
  2. Requirements
  3. Simulating Attacks
    1. Display Name Spear-Phising Attacks
    2. Brute Force Password Attack
    3. Password Spray Attack


When it comes to the security of your environment the best line of defence is one that is reactive versus one that is proactive; however, if you are lucky enough to not currently be target my malicious actors (or even script kiddies) how do you know how you will stand up to a security incident?

Attack Simulator is designed to put organisations that use Office 365 in a position where they understand their weaknesses and in a situation where they can update their policies and procedures with real-world data collected during the simulation. With Attack Simulator companies can run realistic attack scenarios against themselves, to help you identify and find vulnerable users before a real attack impacts your bottom line.

Office 365 recently ran a public preview to allow security professionals (or the people who look after security) within organisations to run multiple attacks internally to discover weaknesses in their environments. The public preview was requested so many times that Microsoft pulled the application a week after the announcement and moved straight to general availability.

Currently, three kinds of attack simulations can be carried out.

  1. Display name spear-phishing attack
  2. Password-spray attack
  3. Brute-force password attack


Unfortunately, and probably due to the rushed release of this product, it can’t currently be discovered in the menu of the Security and Compliance centre of Office 365. It will come eventually, but for now, there are a few hoops that need to be jumped through to gain access to Attack Simulator.

The first major obstacle is licensing. Attack Simulator requires an E5 license. The cost for these licenses are obviously quite high, so hopefully, in the future, Microsoft will add another licensing category just for this.

If you don’t have any E5 licenses, head over to the trial page and grab yourself some for testing.

Another requirement to use Attack Simulator is that the administrator has Multi-Factor Authentication (MFA) enabled. If you don’t, you should, so now would be a great time to complete this.

The next hurdle is permissions. To be able to complete the setup, you will need to be a member of all the available permission roles. Again, hopefully, this is due to the rushed release but Microsoft currently doesn’t make a designated list of required permissions available (even internally), so we need to be in all roles.

To do this, follow the below:

  • Head over to
  • Click Create
  • Give your Role Group a name. I used “Test Threat Permissions” to easily identify it when Microsoft releases the correct guidelines
  • Click Next, and then select “choose roles.”
  • Click Add
  • Highlight ALL roles (select the box next to Name)
  • Click Add, then Done
  • Click Next, and then select “Choose members.”
  • Click Add
  • Place a check next to the ADMINISTRATOR account that will be used for Attack Simulation
  • Click Add, then Done
  • Click Next
  • Click “Create role group.”

Once completed, you should see a group that looks similar to the below:

Once the above is complete, you will have to wait for the permissions to propagate through Office 365. I waited about three hours however Microsoft tells me this could be anything up to a day.

Once you have waited, head to:

This link will take you directly to the Attack Simulator page. It’s a good idea to bookmark this until Microsoft add it to the Threat Management sub-menu of the Security and Compliance section of Office 365.

Once here, you will be greeted by an option telling you further configuration is required. Click the setup now button.

If it fails and comes back with the below, you need to wait more time for the permissions to propagate.

Simulating Attacks

As previously mentioned there are currently three kinds of attack simulations can be carried out.

  1. Display name spear-phishing attack
  2. Password-spray attack
  3. Brute-force password attack

These are covered in the following sections.

Display Name Spear-Phishing Attacks

Selecting attack details on this explains the why of spear phishing.

Phishing is a generic term for a broad suite of social engineering attacks. Social Engineering, in the context of Security, is the art of manipulating people into performing actions or divulging confidential information. This type of confidence trick is often used for information gathering, fraud or computer system access. If successful, Phishing attacks can often lead to a more complex attack. The end objective generally falls into one of three areas: Financial Gain Espionage Reputation There are a multitude of Phishing variants, however most Phishing attacks have a common structure: Source, Payload and Target. 


Display Name – Spear Phishing

To carry out this attack simulation, select “Launch Attack” on the main page. This will bring up a context menu to navigate you through the process.

The first section is naming the attack (for later reference) as well selecting a template to use.

Currently, there are only two templates to select from, which are:

  • Prize Giveaway
  • Payroll Update

You don’t have to select one of these, but for testing purposes I chose the “Prize Giveaway”

The next section allows administrators to select the target users for this campaign. Remember, multiple campaigns can be run in order to attack different people with different approaches.

Once the targets (or victims) are selected, we move on to how the message will appear to the users.

The only thing modified here is the From email address and the Custom Landing Page.

Office 365 makes several “Phishing Login Servers” available to allow you to select one that is close to the original purpose as possible. I would imagine as the number of templates increases, so will the number of URL’s that are available for selection.

For this demo, I’ve chosen to send the email from “[email protected]” with a landing page of (which is merely the WordPress short link for this page).

One thing worth noting here is the simplicity of the From email address. Having used several other programs which do very similar jobs to this, Microsoft has made sending it from any email address exceptionally easy.

Typically, due to email monitoring programs and policies the sender’s email address must be correctly entered and have SPF records correctly assigned, or the mail will be dropped as Spam at the border. As this system works inside the edge, it allows any From email address to be entered.

After this, it is simply a matter of confirming you wish to run the campaign.

After a few moments, your target users will receive your crafted email:

Navigating to Attack Details for your campaign (or, going to this URL will allow you to monitor the progress of your attack.

The user experience

As with most phishing techniques, certain things will give away the fact that things are not what they seem.

The first is the URL in the link

If you sent the email from this wouldn’t be so bad, but as my test came from Instagram users should be looking to be directed to one of Instagrams servers. Unfortunately, with most legitimate mailing campaigns, this isn’t always the case.

The next is clicking on the URL brings you here:

Which, as you can see is a HTTP (not secure) link asking for credentials. It looks like the Microsoft portal login (which, Office 365 users will be familiar with) however the URL is still “” which would never appear for a Microsoft website.

Here, if you test it yourself, enter your email address but put a RANDOM password in (it’s insecure, and the wrong website anyway!) and Microsoft will move you onto the redirected URL you selected earlier (in my case, the WordPress short link).

Going back to the Attack report, you will see one of your targets has been silly enough to click through the link and expose their credentials.

Incidentally, should you use this in production and a user does fall for it, please ensure they change their password immediately. It has just been sent un-encrypted over the internet!

One thing to note, which was discovered during these tests, was the fact that Firefox is automatically tagging the website we used as deceptive. If your primary browsers within your company are Firefox, you may need to add an exclusion or risk seeing something like this:

which would give the game away completely.

Note, I forgot to screenshot the deceptive site page, so the one above is from a google search, and not the website Microsoft redirected us to.

Brute Force Password Attack

Selecting attack details explains the why for brute forcing passwords.

Password cracking techniques are used to guess the user’s password by trying many variations with a computer. Since most companies with substantial numbers of users, or complex application ecosystems end up running a hybrid or federated domain model, an on-prem account and an Office 365 account will have the same credentials and will represent a single weak point around the services accessible by the affected user. Once the attacker has the username and password for the user, they will generally be able to find a way to authenticate and interface with Office 365 as if they were the end user. Brute force attacks work by calculating every possible combination that could make up a password and testing it to see if it is the correct password. As the password’s length increases, the amount of time, on average, to find the correct password increases exponentially. This means short passwords can usually be discovered quite quickly, but longer passwords may take decades. 2 types of attack typically exist, a dictionary attack using a well-known dictionary list of passwords and an exhaustive attack, where combinations are tried sequentially.


Brute Force Password Attack

Once you select the Launch Attack button for this type of attack, as before, a context menu will appear guiding you through the rest of the process.

The first option is entering a friendly name for the attack.

Secondly, we target the users we want to investigate.

Once we have our list of targets, we specify what passwords should be attempted against their usernames.

This gives us two options.

  1. Enter passwords manually
  2. Upload a password list

At this moment in time, even if you upload a password list, you must still manually enter at least one password. To do this, enter the password and then press Enter. The password will be added to the list (indicated by dots replacing the actual text).

If you also wish to add a password list, I would recommend head over to Daniel Miesslers secList github

For this test, I grabbed the file and copied to my workstation, then uploaded to Office 365.

Then, confirm you are happy to proceed with the testing.

The attack can take a couple of minutes to several hours to complete. Once it does, you will be able to click on “Report Available” within the Attack Simulator portal to see if any users were compromised:

This attack is not visible to the users.

Password Spray Attack.

Selecting attack details explains the why for password spraying attacks.

A password spray attack against an organisation is typically used after a bad actor has successfully enumerated a list of valid users from the tenant, utilising their knowledge of common passwords used. They attempt one(1) carefully crafted password against all of the known user accounts (a one to many attack). If the attack is not successful at first they will typically try again utilising a different carefully crafted password, usually waiting longer period between attempts so as to not trigger any policy based account lockout triggers.


Password Spray Attacks

This attack is very similar to the brute force attack however utilises the one-to-many methodology explained earlier.

As with the brute force attack once you select the Launch Attack button you will be given a context menu that guides you through the rest of the process.

First we need to enter a friendly name to remember this attack.


Next we select the users. Remember, this is supposed to be a one-to-many attack so select multiple users.

Next, we enter the password we wish to test against.

If you have a standard new starter password of something like “Welcome1”, this would be a great start to discover if users have changed their passwords since. Passwords like this are the primary focus of attackers when users this type of attack.

As with the other attack types, you must confirm the settings before starting the attack.

As with the brute force attack, users will not see anything that makes them aware that this attack is being carried out.

Once it is complete, you will be able to view the report from the Attack Simulator portal.


It’s worth pointing out that there are a number of very good paid alternatives to the attack simulator which give a lot more options for individual attacks however Microsoft’s integration into Office 365 ensures these features are easy to use and accessible, providing the you meet the licensing requirements!

As always, if you need any help with any of the items discussed here, don’t hesitate to contact us.

Office 365 Secure Score

Here at Complete Cloud Solutions we’ve long been fans of the Office 365 Security and Compliance settings. They offer a great overview of options to investigate and protect assets your company has in the cloud.

Todays blog is to cover an often overlooked aspect of the Security and Compliance page, namely the Office 365 Secure Score.

If you’ve never heard of it, below is Microsoft’s take on Secure Score

Ever wonder how secure your Office 365 organization really is? Time to stop wondering – the Office 365 Secure Score is here to help. Secure Score analyzes your Office 365 organization’s security based on your regular activities and security settings and assigns a score. Think of it as a credit score for security.


Secure Score Introduction

So, what this means in real terms is Microsoft produce a large list of best practice scenarios and aligns how your organisation is doing in terms of these best practices.

When opening Secure Score the first thing you will probably notice is your ‘score’. This is displayed alongside your predetermined maximum  score. It is possible (and in fact probable) that your companies maximum score is different to the one shown below as this score is decided by the security baseline Microsoft align your company too.

Below your score is a sliding bar that allows you to set your companies target, followed by a list of recommendations to assist you to achieve your target. As you slide the target to the left or right, the list of recommendations changes in order to facilitate the best approach to your desired score.

The list of recommendations is ordered by:

  1. Highest is the items that affect the score the most, with limited user impact.
  2. Lowest is the items with least impact on the score, but higher user impact.

The right hand panel has a couple of important items too. 

The first is a Risk Assessment that your organisation faces while at your current score.  Each item displayed as a risk can be selected to allow you to easily understand what problems you are facing.

The second item is a score comparison chart for organisations Office 365 believes are similar to your own. This allows you to track your score against other companies to see whether your security standing is better or worse.

So, after reviewing a single page I now know:

  1. My current security standing is approximately 10% of what it could be
  2. I need to perform 22 actions in order to reach my ‘goal’ of 299
  3. I am doing better than the other companies similar to me, as well as the average Office 365 tenant
  4. I’m currently at risk of Account Breach, Privilege Escalation and Data Ex-filtration

So, not a great start, but not terrible either. So, what exactly does Office want me to, to increase my score and just how hard are these on busy organisations.

Let’s look at the first four, and understand what business impact it will have.

So, this tenant currently has Global Admins that don’t have Multi-Factor Authentication enabled for them. 

This is only complaining about Global Admins at this point, people who have privelages to do anything in Office 365. These are generally dedicated IT accounts (and should not be assigned licences) and only used when changes to the tenant are required. If these are configured correctly, the only impact this has is to the IT user who needs to occasionally (or even regularly) log in to perform one task or another. 

Impact on normal, everyday users. None. Therefore, impact on business should also be none.

And, as the information displayed informs us, this will assist with our two main problems of Account Breach and Privilege Escalation.

OK, so next up is:

Multi-factor authentication for all users. Experience tells me this one is harder for many businesses to stomach however the advantages outweigh any potential user adoption problems. As shown, this also helps with Account Breaches and Privilege Escalation. 

As you will probably see, in the environment I am currently looking at there is 6 user accounts which will increase my secure score by 30 points, meaning 5 points per user. This is also another way to assist you to track the adoption of MFA as this score will increase as each user is activated.

The next one covers the Data Ex-filtration problem:

This one is a little more complicated to understand and implement however usually this would again generally not have any impact on standard users.

What this alert is actually complaining about is the ability for users to create a rule that automatically forwards their emails to external addresses. For example:

  1. Dave works as a finance analyst
  2. Dave receives an email from the CFO with a list of bonuses that people received over the last financial year
  3. As the email comes in, a rule in Dave’s mailbox forwards the email to [email protected] 
  4. Dave is systematically offloading all emails with attachments to a none authorised email address, outside of the company

Usually, there is no reason for users to do this for legitimate purposes and it’s generally regarded as a good idea to automatically prevent it globally, then add exceptions to users that have a valid business requirement.

Enabling this setting will create a transport rule that will stop external messages leaving your Tenant, that are of the type AutoForward, mitigating the use of Client created external mail forwarding rules and malicious Remote Domain entries as a data exfiltration vector.

  1. If The Sender is located ‘Inside the organization’
  2. If The Recipient is located ‘Outside the organization’
  3. If The message type is ‘Auto-Forward’
  4. Reject the message with the explanation ‘External Mail Forwarding via Client Rules is not permitted’

 OK, so, lets look at the last one:

This one seems obvious however is another topic that is often overlooked. Simply by regularly reviewing what are classed as ‘risky logins’ increases your score by 45 points. That’s 1.5 times the average Office 365 score!

These Risky Logins show:

  • Users with leaked credentials
  • Sign-ins from anonymous IP addresses
  • Impossible travel to atypical locations
  • Sign-ins from infected devices
  • Sign-ins from IP addresses with suspicious activity
  • Sign-ins from unfamiliar locations

 Which every organisation should definitely be tracking on at least a weekly basis. I would also recommend enforcing MFA for users that are discovered as ‘risky logins’. This has the possibility to disrupt some users however will give you maximum protection should you not have MFA enabled.

So, enabling these in my test environment took a grand total of ten minutes. Real world will probably take longer however most of the time would be dedicated to change controls and business adoption. 

These four topics should increase the score from 36 to 181, with only MFA being a user affecting item. This is achieved from:

  • Enable MFA for all global admins gave 50 points
  • Enable MFA for all users gave 5 points per user
  • Enable Client Rules Forwarding Block Advanced Action gave 20 points
  • Review signs-ins after multiple failures report weekly gave 45 points

Once they are done , you will the see your score increase after approximately 24 hours.

One thing to note is the score took approximately 5 days to update. You’ll see within the chart the last update time was March 13th, 2018. The previous update time was March 9th. 

The Microsoft documentation says this score will update every 24 hours, however, real world experience is generally a longer than this.

Windows Spectre and Meltdown updates

This blog post gives a brief insight into the problems releasing fixes for the Spectre and Meltdown vulnerabilities and discusses a new approach which has recently been implemented. If you would prefer to jump straight to that part, click here.

As most people will already be aware, both Intel and AMD have had a rough time recently when some independent researchers discovered the Spectre and Meltdown vulnerabilities.

If you haven’t heard of this, have a look at these great articles:

  1. Meltdown Attack
  2. Microsoft Security Advisory
  3. Google Project Zero

Now, after reading them, you will probably have an idea of the scale of the problems faced by modern processor and operating system vendors.

This particular problem is both a hardware and software related problem and requires fixes from both sides of the fence. In future releases I would expect CPU’s to address the problems through hardware changes, however, as the design cycle for a CPU can last several years, I don’t expect this to be fixed in the next hardware releases which are probably already beyond the point of reworking.

So, really, that leaves software to fix the problem. This is again split into two different arenas, microcode and higher level software. Microcode is akin to processor firmware, so certain changes and updates to the way the processor operates can be modified through updating the microcode.

The software and microcode updates have caused some serious headaches for both vendors and end users alike, with Microsoft releasing patches on 15 different days in January as they attempted to fix their side of the vulnerability, and the problems their fixes introduced. This Computer World article has a great breakdown.

Microsoft finally managed to resolve their part last month, with successful patching (and no roll-backs) happening last month and appearing to be stable.

That only leaves Intel and AMD. 

If you have an AMD, you’re probably not in a bad place right now as the Microcode updates released are deemed as optional. The three main variants that have been discovered as ‘exploitable’ were found to be more difficult to manipulate and make use of on AMD processors. More can be read on this AMD security release. This doesn’t mean your machines are completely safe, only that the fixes for this rest more on thesoftware (Operating System) manufacturers than AMD.

So, that leaves Intel. They have been working hard to try and develop microcode fixes for their the following affected processors:

  • 2nd to 8th generation Intel®Core™ processors
  • Intel®Atom™ Processor Z Series
  • Intel®Celeron®Processor J Series
  • Intel®Celeron®Processor N Series
  • Intel®Pentium®Processor J Series
  • Intel®Pentium®Processor N Series

Each processor requiring different changes and modifications, meaning there is no one fix for them all. This has been part of the problem Intel have had as some of the released code has worked for one specific set of chips, but caused problems on another.

Recently Intel withdrew all of it’s Spectre microcode fixes as they caused significant problems when installed on users machines. This is quite scary considering each firmware release goes through the following supply chain:


The guts of the post

So, despite the rigorous testing process that the microcode undertakes end users were still impacted by the release of the ‘fixes’.

Intel have now revised the way they deploy the microcode patches to OEM vendors, preferring to do it by dealing with a single processor family at a time. Although this will increase the time to release it ensures they can concentrate on that family of processor rather than attempting to target them all in one go.

However, as you’ll see from the above process graphic, this still means a considerable amount of time for OEM vendors (be they component manufacturers or machine builders) to test and release the firmware that will actually update the BIOS code.

As an interim solution, last week Microsoft announced it will start to deploy ‘on-the-fly’ microcode changes for Windows creators update (1709) with the following patch installed:

  1. Microsoft KB4090007 article
  2. Update Catalogue link

This update will not be deployed via Windows updates, so organisations and individuals will need to download the update direct from the link provided.  It must be noted that this update is not a replacement for the firmware updates, only an interim solution to allow your machine to run in a protected manner until your vendor releases the firmware for your hardware. It does this by: 

  • Matching your processor against a released microcode version
  • Applying the microcode to the processor at boot up time
  • The microcode remains persistent while the machine is powered on

As you’ll see, this is basically an on-the-fly rewrite of the running code until the machine is powered down. That is why, in the future, you will still need to ensure you update the firmware of the machine. 

This also offers a little bit of hope for older machines who’s hardware parts/vendors are no longer maintaining the products, and so will never receive official firmware.

If you’re still confused about whether or not you need to patch, check out The InSpectre application to understand your current patch status and have it explained in general terms.

As always, if there is anything in this post that you want to know more about, don’t hesitate to get in touch. Contact details in the footer or on the front page.

Password Recycling and the Pwned Password API

As peoples online lives increase, so does the recycling of their passwords. This refers to the act of using the same password over and over again, or common, easy to remember words in an attempt to make their lives easier It has been a problem for many years yet one that has never really been given any direction on what companies should do. 

NIST recently updated their guidelines on “Digital Identities” which now tells organisations what to do. 

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.

NIST Digital Identity Guidelines

Troy Hunt (@troyhunt) announced last week (22nd February) the release of his Have I been Pwned (HIBP) Password Pwned v2 list.

The v2 list has an increase from 320m unique passwords to over 500m unique passwords and has introduced API functionality to allow individuals and companies an opportunity to easily (and securely) test whether a password they use is on the Pwned list.

As stated in his blog post (link at the end) this is the how to NIST’s what.

This is done in the following way:

  • A user or application takes the password input and encrypts it using SHA1. This will give you a hash, similar to B2E98AD6F6EB8508DD6A14CFA704BAD7F05F6FB1
  • The first 5 characters of the hash value are recorded, so in the above instance B2E98
  • You send ONLY the five characters to the API URI – (make a web call to

At this point it is important to highlight that your password has not been sent to, only the first 5 characters of the hashed password. This makes it impossibly for Troy and his team, or anyone eavesdropping on your connection, to know what the actual password was.

Once the API call has been made, the following will happen:

  • The calling application will receive a list of corresponding stored hashes from the database (minus the first 5 characters), and the number of times that particular hash password has been used. Such as
    AA76715E97A5F0632BFA8F09661D1FF6520:2 ACB09FFEF1993313DFA034598AB5D6B31E9:2 ACED17D849FFA981939D10B2B3CBF12D916:12 ACF679BCF5A776B47348AA66EB653F284A9:1 AD6F6EB8508DD6A14CFA704BAD7F05F6FB1:20127
  • If your password is in the Pwned Password list, you will see a matching entry followed by the number of times the password appears in the list. You’ll notice mine is:AD6F6EB8508DD6A14CFA704BAD7F05F6FB1:20127​
  • You then know, without transmitting any sensitive data, the password I used has appeared 20127 times (Password123 is fairly popular)

Real World Applications

The ability to lookup passwords is a great gimmick to show everyone how secure (or insecure) their passwords are but it also has some fantastic real-world applications.

Some of these are:

  • Check Passwords at user sign-up. Thanks to the Cloudflare backend the response of the database is very fast, averaging 15ms returns for cached lookups. This response means you can quickly:
    • SHA1 the user’s input (through Javascript locally on their machine)
    • Query the API to discover if the password is one on the Pwned List
    • Alert the user to the problem and quickly ask them to enter something different
  • Check user passwords at login time. This would again be simple and quick, however, if a password is identified as being on the list, redirect the user to update their password with advice and guidance on picking a better password.

Now, these could easily be handled locally through scripting ensuring that sensitive data is not transmitted over the network. 

Although these examples would work well within a web-based environment, nothing is stopping the API being used within an application that is installed locally ensuring that password recycling is kept to a minimum.

Another thing to note is that the entire database is available for download meaning it is possible to perform these lookups offline and in bulk should you want to. 

The best usage I can see for this would be for organisations trying to justify purchasing a password management system. We all know the companies that still have Excel documents lying around containing the keys to the system. Running it through this process would help IT Managers to justify the additional expense of purchasing a password system!

Testing it for yourself

If you would like to test this for yourself there are several community driven resources to help you out.

  1. HIBP PL PowerShell 
  2. Troy’s Original Blog with a LOT more information
  3. Have I been Pwned

It’s great to see resources like this made freely available on the internet.

If you would like to know any more information on this, or anything else on this blog, don’t hesitate to get in touch.

Crowdstrike’s 2018 Global Threat Report

Earlier this week (Feb 2018) CrowdSrike released their annual report into the state of the global threat environment. 

For those of you that don’t recognise the name, CrowdStrike is an American cyber-security technology company based in Sunnyvale, California. The company provides endpoint security, threat intelligence, and incident response services to customers around the world and has been involved in countermeasure efforts to several high-profile cyber-attacks, including the Sony Pictures hack, the 2016 Democratic National Committee email leak, and the Democratic National Committee cyber attacks.

We’ve put this blog post together to highlight some of the factors we believe our customers would be interested in, covering

If you would like to look at the full report, you can get it here.

The biggest take away from the document, we believe, is the below statement:

There are several factors contributing to this fundamental levelling of the playing field between highly skilled — and typically well funded — nation-state adversaries and their less sophisticated criminal and hacktivist counterparts. One of the biggest contributors is the “trickle-down effect” present in the cyber-threat arena.

George Kurtz

Supply Chain Attacks

What this means is that cyber-criminals, the ones that all business have to consider on a daily basis, are now getting access to bigger, better and more stealth-driven tools as they filter down from state-sponsored groups. 

These leaked tactics, techniques and procedures (TTPs) have been eagerly adopted by cyber-criminals wanting to up their game which has meant ordinary organisations have to ensure they are aware, and protected, against threats they would not have dreamt of a couple of years ago. 

The most notable example of this that most people will recognise is the supply chain attacks that several legitimate software companies succumbed to throughout the year.

Supply chain attacks generally involve the infiltration of your environment through a trusted partner or application that is breached and has access to your system. These types of attacks have been commonly used by nation-state actors however recently, as was seen with the CCleaner malware in September last year, malicious actors have used this technique to infect businesses in a scattershot method. 

This particular attack was initiated by downloading the legitimate version of CCleaner for valid distribution points. The software was digitally signed, and to all intents and purposes, the correct version to use. When the installer was run, it triggered the download of additional code which was the malware. As this runs under the context of the installer, it is challenging to identify.

Given the presence of a valid digitally signed key it is likely that an external attacker compromised a portion of Piriform’s development or build environment and leveraged that access to insert malware into the CCleaner build that was released and hosted by the organisation.

This means they target a wide variety of companies in the hope of focusing on a handful of specific ones. You may consider, at this point, this isn’t something to worry about if you’re not the actual target however your organisation is still infected with malware, which gives you a ticking time bomb. Even if the original orchestrators of the attack don’t utilise that infection, chances are they will sell it on once they are finished with their intended targets.

The report highlights other supply chain attacks in greater detail, such as:

  • M.E.Doc – Initial infections of NotPetya appeared on systems running a legitimate updater for the document management software M.E.Doc. Additional reports indicate that a separate malware family, XData, was also pushed by these software update packages as early as May 2017.
  • NetSarang – a company specialising in connectivity solutions for large corporate networks. A library included in several of the NetSarang software packages was modified to contain malicious shell-code that would enable the adversary to activate an embedded implant dubbed ShadowPad. Further analysis of C2 infrastructure related to this incident revealed a connection to China-based targeted intrusion actors.
  • PyPI Typosquatting – In September 2017, industry researchers discovered that malicious Python packages residing in the Python Package Index (PyPI) were masquerading as popular packages. The names of the malicious packages approximated those of legitimate packages and were delivered to users who mistakenly typed the fake package names. The only functional ity of the malicious packages was to relay basic machine information back to a C2 server and did not allow for downloading of additional malware.
  • ProtonRAT – In 2017, unidentified adversaries attempted to disseminate the MacOS malware called ProtonRAT by spreading it through supply chain attacks on video-processing software, such as Handbrake and Elmedia.


Although this one has been on the rise for the past few years, a number of additional factors have increased the uptake throughout 2017.

The factors that CrowdStrike observe within the document are:


Throughout 2016 early testing versions of TrickBot were set up to target a digital banking platform commonly used by regional banks in the United States. By November 2016, new configurations enabled redirection attacks against four UK banks and server-side injections against numerous Australian financial organisations. Experts say the malware now targets the personal and business banking websites of financial institutions in New Zealand, Canada and Germany.

Early in the existence of this operation, TrickBot capabilities remained unsophisticated but well developed, relying on webinject functionality.

Outside of this core banking Trojan capability, Trickbot developed modules for VirtualNetwork Computing (VNC), a collection of victim machine information, and a mail searcher module. From late July through September, Trickbot developers significantly increased the botnet capability of TrickBot by adding these new modules:

  • wormDLL – SMB spreader
  • outlookDLL – Harvests victim data from MS Outlook
  • importDLL – Information Stealer targetting browsers
  • testWormDLL – Monero cryptocurrency miner
  • shareDLL – Lateral movement around victim network, via shares victim has access to.

With its rapid development and introduction of new features and functionality, Trickbot is quickly beginning to become the go-to malware trojan mechanism for all types of actors.

Other Notable Facts

The report highlights some additional notable facts. These are:


The report finishes up with some very valid recommendations moving forward. Gone are the days when small to medium business can ignore the problems that much bigger businesses face on a daily basis. The filtering down of TTPs effectively means any script kiddie or low-level cyber-criminal can get access to resources that were developed by nation-state sponsored threat actors.

Thankfully, as competition arises within the cyber-crime arena so does it rise in the cyber-security sectors. This means organisations have greater choice and capabilities at lower price points than have previously been seen. Also, due to the open nature of the internet and the fact that many problems are documented in depth when discovered, there is also a lot of ways organisations can prepare for this type of attack without massively affecting their bottom line.

CrowdStrikes recommendations are as follows:

  • Going Beyond Malware: Strengthen Defences Against Modern Attacks.
  • Continually Assess Risk with Real-Time Visibility.
  • Add Threat Hunting to Your Security Portfolio.
  • Integrate Threat Intelligence Into Your Endpoint Security Strategy.
  • Assess Your Readiness to Protect Against Sophisticated Attacks.

For anyone who has subscribed to this site or follows cyber-security news, these recommendations won’t be anything new. However, if you would like to discuss this further, don’t hesitate to get in touch.

The facts about Petya and NotPetya

On June 27, 2017, a ransomware variant titled Petya/NotPetya was reported to be spreading across Europe. Since then, it has spread to at least 65 countries. This new variant exercises unique methods of both infection and propagation. Read on to learn more about this malware and how to protect your data.

  • Trusted software updates were used by Petya/NotPetya to initially infiltrate devices – A legitimate software updater process (EzVit.exe) from M.E.Doc, a Ukrainian company offering tax software, is believed to have been the victim of software update hijacking which was responsible for the initial infections of Petya/NotPetya. These compromised updates were trusted by computers running the relevant software. Therefore, the hidden malicious code was able to slip past most defences when EzVit.exe was downloaded and executed.
  • Petya/NotPetya exhibits worm-like behaviour – After obtaining the current user credentials of infected machines via either the command line, the CredEnumerateW Windows API, or through two executables embedded within Perfc.dat, Petya/NotPetya attempts to spread laterally to other devices on the local network. Petya/NotPetya utilises PsExec or WMI, and the obtained user credentials or token to install its wiper-ware on targeted devices. If these devices have not yet applied the MS17-010 patch, Petya/NotPetya will utilise the EnternalBlue or EternalRomance exploit (depending on the user’s operating system) to compromise the systems.
  • Petya/NotPetya’s encryption was not designed to be reversed – If administrative access was obtained, Petya/NotPetya will overwrite the master boot record (MBR) code. During this process, it schedules a task to reboot the machine and then attempts to encrypt the master file table (MFT). Once the computer has been rebooted, the MFT is removed, preventing the computer from normally booting, even if decryption keys could be received.

Although the initial source of infection was denied by M.E.Doc it has been discovered, through investigative testing of the EzVit update process, that the EzVit.exe process does infact spawn the Petya/NotPetya initial infection, as below:

This can easily be reproduced using the software and analysis tools such as PSTools Process Explorer.

The same update vector was also mentioned by the Ukraine Cyber Police in a public list of indicators of compromise (IOCs) , which includes the MEDoc updater.

Once the ransomware is installed it attempts to move laterally throughout the environment. It does this through one of the following:

  • stealing credentials or re-using existing active sessions
  • using file-shares to transfer the malicious file across machines on the same network
  • using existing legitimate functionalities to execute the payload or abusing SMB vulnerabilities for unpatched machines

Lateral movement through credential theft

This ransomware drops a credential dumping tool (typically as a .tmp file in the %Temp% folder) that shares code similarities with Mimikatz and comes in 32-bit and 64-bit variants.  Because users frequently log in using accounts with local admin privileges and have active sessions opens across multiple machines, stolen credentials are likely to provide the same level of access the user has on other computers.

Once the user’s credentials are compromised, the ransomware then attempts to scan other for other machines in the environment to compromise. It does this by examining its local network to establish valid connections on ports tcp/139 and tcp/445 (both SMB ports). Once a response is received it attempts to copy over infected binaries through standard Windows file copy processes. The ransomware then tries to connect to the remote machine using the stolen credentials, or existing sessions, and execute the malware using either PSEXEC or WMIC tools.

In addition to credential dumping, the malware also tries to steal credentials by using the CredEnumerateW function to get all the other user credentials potentially stored in the credential store. If a credential name starts with “TERMSRV/” and the type is set as 1 (generic), it uses that credential to propagate through the network.

While scanning the remote systems, if the ransomware discovers a domain controller it performs an additional task. The malware attempts to call DhcpEnumSubnets() to enumerate DHCP subnets; for each subnet, it gathers all hosts/clients (using DhcpEnumSubnetClients()) for scanning for tcp/139 and tcp/445 services ensuring that the software has maximum reach throughout the environment.

Ransomware code responsible for accessing remote admin$ shares
Ransomware code owing launch of malware on a remote machine using WMIC

Encryption Mechanism

This ransomware’s encryption behaviour depends on the malware process privilege level and the processes found to be running on the machine.

It runs through the following workflows.

  •  simple XOR-based hashing algorithm on the process names, and checks against the following hash values to use as a behaviour exclusion

  • if 0x6403527E or 0x651B3005 are discovered running on the target machine, then the ransomware does not do SMB exploitation.

  • if 0x2E214B44  is discovered, the ransomware trashes the first 10 sectors of \.PhysicalDrive0, including the MBR

  • This ransomware then writes to the master boot record (MBR) and then sets up the system to reboot. It sets up scheduled tasks to shut down the machine after at least 10 minutes past the current time. The exact time is random (GetTickCount()). For example:schtasks /Create /SC once /TN “” /TR “shutdown.exe /r /f” /ST 14:23 
  • After successfully modifying the MBR, it displays the following fake system message, which notes a supposed error in the drive and shows the fake integrity checking:

  • Followed by the ransomware note

  • Petya/NotPetya then attempts to encrypt all files with the following file name extensions in all folders in all fixed drives, except for C:Windows:

  • Unlike traditional ransomware, Petra/NotPetya replaces the files with an identical extension, rather than creating a new file with an extension that can be blocked. This is an important difference as it prevents detection and blocking through file restriction policies
  • The AES key generated for encryption is per machine, per fixed drive, and gets exported and encrypted using the embedded 2048-bit RSA public key of the attacker.

Lateral movement using EternalBlue and EternalRomance

The Petya/NotPetya ransomware also spreads using the previous document EternalBlue and EternalRomance which was fixed in security update MS17-010 and was also exploited by WannaCrypt and EternalRocks to spread to out-of-date machines. Also, this ransomware also uses a second exploit for CVE-2017-0145 (also known as EternalRomance, and fixed by the same security bulletin).

Machines that are patched against these exploits (with security update MS17-010) or have disabled SMBv1 are not affected by this particular spreading mechanism.

Indicators of Compromise

As with all file based ransomware there are several indicators of compromise.

In environments where command-line logging is available, the following command lines may be searched:

  • Scheduled Reboot Task: Petya schedules a reboot for a random time between 10 and 60 minutes from the current time
  • schtasks /Create /SC once /TN “” /TR “shutdown.exe /r /f” /ST
  • cmd.exe /c schtasks /RU “SYSTEM” /Create /SC once /TN “” /TR “C:Windowssystem32shutdown.exe /r /f” /ST

This may be surfaced by searching for EventId 106 (General Task Registration) which captures tasks registered with the Task Scheduler service.

  • Lateral Movement (Remote WMI)

“process call create ”C:WindowsSystem32rundll32.exe ”C:Windowsperfc.dat” #1

Network indicators

In environments where NetFlow data are available, this ransomware’s subnet-scanning behaviour may be observed by looking for the following:

  • Workstations scanning ports tcp/139 and tcp/445 on their own local (/24) network scope
  • Servers (in particular, domain controllers) scanning ports tcp/139 and tcp/445 across multiple /24 scopes


The recommended steps are dependent on whether you already have a compromised environment or not.

The below steps should be followed if you have not been compromised with Petya/NotPatya:

  • Update supported software with Microsoft’s March 2017 patch (MS17-010) as soon as possible.
  • Make the time to back up all critical data, ideally to devices that are kept offline.
  • Create a disaster recovery plan for backing up and restoring critical data.
  • Close all unnecessary ports and adopt the principle of least privilege. The Petya/NotPetya threat specifically targets ports 139 and 445. Blocking traffic on these ports will prevent further propagation of Petya/NotPetya.
  • Disable legacy protocol such as SMBv1; steps are documented in Microsoft Knowledge Base Article 2696547.
  • Consider application whitelisting and segmentation within your network to reduce the impact of these types of attacks.
  • Send internal alerts to educate employees on the Petya/NotPetya threat and proper response/notification.
  • Deliver security training sessions on threat mitigation tactics; foster a culture of organisational situational awareness.
  • Send external alerts to clientele; proactively address any efforts undertaken to combat the threat.
  • Schedule cadence meetings with your managed service providers and third-party vendors to discuss Petya/NotPetya. Address any/all corresponding security measures they have undertaken to combat it.
  • Share this intelligence and actively collaborate with external stakeholders to manage any potential risk.
  • Enterprises can demand proof of changes from vendors by asking for evidence such as records of change, patches deployed, etc.
  • Review your threat intelligence programs (if there are none, refer to Complete Cloud Solutions for guidance on setting them up) and ensure that they are being consumed and actioned. Timely intelligence can give you a crucial head start against threat actors.
  • Install EPP vendor updates. Ensure endpoint protection solutions incorporate the most recent indicators of compromise and updated signature lists. Adopt machine learning and heuristic-based analysis to monitor threats in real time.
  • Block relevant indicators of compromise, detailed earlier in this post
  • Formalise incident response procedures. Create detailed runbooks that actively address all mitigation and operational procedures in the event that an endpoint is infected. Actively distribute runbooks and collaborate internally so that all security members are aware of the required steps and procedures.

The following checklist should be considered if you have been infected with Petya/NotPetya

  • Shut down and disconnect any infected systems as part of your overall risk mitigation strategy.
  • Isolate the infected host if available.
  • Do not attempt to clean the system or run any AV or malware scans. These processes are done later.
  • Assess your organisational exposure for all internet-facing devices. Determine why open ports are open. Maintain a dynamic and frequently updated listing of active ports.
  • Do not reboot infected devices.
  • Recover any unencrypted data using a live disk/OS.
  • Payment should not be an option. In the case of Petya/NotPetya, paying the ransom will not result in getting files back.
  • Create an inventory of infected devices so you know what must be restored from backup.
  • Report your experience: organisations that have fallen victim to a ransomware attack are encouraged to work with their local law enforcement office.
  • Send internal alerts to educate employees on the Petya/NotPetya threat.
  • If client-facing operations have been impacted, work with your legal or field department to communicate to your customers. Proactively address any efforts undertaken to combat the threat.
  • Google Drive, Dropbox, OneDrive – have you shared the data with someone else using a cloud-based storage service? Even if the data is encrypted, these services will often allow you to revert your files to a previous state.
  • Removable media – did you put the files onto a USB, external hard drive, DVD, or some other removable media to transfer the data? If you find you have copies on removable media, then manually verify the files by restoring to a separate computer. It is essential to verify the files if using physical media, as these can tend to deteriorate.

Once the above steps are completed, consider reviewing Complete Cloud Solutions Next Generation Security to maintain a proactive approach to security.

EternalRocks Malware (Next Generation WannaCrypt)

Following on from the WannaCrypt outbreak that used two of the vulnerabilities that were released by the Shadow Brokers on the 14th of April, 2017. Security researchers have now found a worm which is using seven of the exploits.

The worm was discovered when it hit the honey pot of a security researcher named Miroslav Stampar. Although, as explained later, the worm is currently dormant and does not do any file encryption or data stealing, as it connects to a command and control centre (C&C) this could change rapidly. It is the very fact that it lays dormant that makes this such a serious threat.

After investigation he discovered the following exploits in the worm:

  1. EternalBlue — SMBv1 exploit tool
  2. EternalRomance — SMBv1 exploit tool
  3. EternalChampion — SMBv2 exploit tool
  4. EternalSynergy — SMBv3 exploit tool
  5. SMBTouch — SMB reconnaissance tool
  6. ArchTouch — SMB reconnaissance tool
  7. DoublePulsar — Backdoor Trojan

Apart from the number of exploits in use the main difference discovered between this and WannaCrypt was that the EternalRock malware does not deliver any malicious payload or encrypt files as. There is no ransomware code within this malware. It appears to initially just be taking control of a machine and then propagating to other machines on the network/internet.

As with WannaCrypt once a vulnerable machine is discovered EternalRocks connects to it and the initiates two different stages. These stages are explained below.

Stage 1

  1. Connect to the vulnerable machine
  2. Installs TOR browser on the infected machine
  3. Downloads necessary .NET components (for later stages)
  4. Modified TaskScheduler and SharpZLib are downloaded from the Internet
  5. Drops svchost.exe (e.g. sample) and taskhost.exe and replaces with infected versions
  6. Component svchost.exe is used for downloading, unpacking and running Tor from along with C&C (ubgdgno5eswkhmpy.onion) communication requesting further instructions (e.g. installation of new components).

Stage 2

  1. The malware waits at least 24h before proceeding in what is believed to be an attempt to bypass sandboxing techniques
  2. Downloads a newer modified taskhost.exe from http://ubgdgno5eswkhmpy.onion/updates/download?id=PC and installs it.
  3. Downloads and installs the additional explouts package
  4. Starts a random scan of opened 445 (SMB) ports on Internet
  5. Continues to request regular updates from the C&C

How do we protect ourselves

To understand how to protect against this threat it is important to understand how SMB works. Unlike WannaCrypt that targetting only SMBv1 machines this has the facility to attack all versions, meaning Windows 10, 2012R2 and 2016 are all vulnerable if left unpatched.

The below information details how SMB works and also how the protocol in use is determined. This is simply to help you understand what is happening in the background and why exploits that target vulnerabilities within all three of the SMB protocols is such a problem:

So, when a Windows 7 machine connects to a Server 2012R2 machine it does it via SMBv2.1.

The image below shows the flow of protocol selection.

As with WannaCrypt there are a few things that can be achieved to help prevent the spread of this malware and again this is UPDATE your systems. To check to see if you have a patch which will protect you from the SMB exploits the following script can be used:

[codesyntax lang=”powershell” container=”pre”]

#— Script start
# List of all HotFixes containing the patch
$hotfixes = @(‘KB3205409’, ‘KB3210720’, ‘KB3210721’, ‘KB3212646’, ‘KB3213986’, ‘KB4012212’, ‘KB4012213’, ‘KB4012214’, ‘KB4012215’, ‘KB4012216’, ‘KB4012217’, ‘KB4012218’, ‘KB4012220’, ‘KB4012598’, ‘KB4012606’, ‘KB4013198’, ‘KB4013389’, ‘KB4013429’, ‘KB4015217’, ‘KB4015438’, ‘KB4015546’, ‘KB4015547’, ‘KB4015548’, ‘KB4015549’, ‘KB4015550’, ‘KB4015551’, ‘KB4015552’, ‘KB4015553’, ‘KB4015554’, ‘KB4016635’, ‘KB4019213’, ‘KB4019214’, ‘KB4019215’, ‘KB4019216’, ‘KB4019263’, ‘KB4019264’, ‘KB4019472’, ‘KB4015219’, ‘KB4016636’, ‘KB4019473’)
# Search for the HotFixes
$hotfix = Get-HotFix | Where-Object {$hotfixes -contains $_.HotfixID} | Select-Object -property “HotFixID”
# See if the HotFix was found
if (Get-HotFix | Where-Object {$hotfixes -contains $_.HotfixID})
    write-host “Found hotfix” $_.HotfixID
    write-host “Didn’t find hotfix”
#— Script end


If you don’t patch soon, there might be reason to panic later. One of the things EternalRocks does is that it leaves the DOUBLEPULSAR implant unprotected, which means other threat actors could leverage EternalRocks infected machines for their own intents and purposes.

​If you can’t install the patches for whatever reason the following should be applied:

  1. Limit the attack surface by disabling all none-required SMB versions. If you are pure 2012R2 and Windows 8+ only v3 should be left enabled
  2. Create a rule on your firewall to check for internal to external attempts on port 445. If this is attempted it should be blocked and an alert raised. This will not protect your organisation but will at the very least give you an indication that someone may have been breached.
  3. Disable TOR from the internal network to the external on your firewall

If you need help with this, or any other related topic please don’t hesitate to contact us.

WannaCrypt Ransomware

As most people are by now probably aware this weekend saw the release of a new ransom-ware attack that was first seen attacking the NHS in the United Kingdom.

This attack was initially accidentally stalled by the registration of a domain name ( however it now appears that the original code has been modified to not have a dependence on the domain name. This means the ransomware is once again in full swing.

Unlike many standard ransom-ware attacks this one doesn’t seem to have relied upon users opening booby trapped emails or drive by downloads but instead relies upon the EternalBlue vulnerability that was released as part of the Equation Group Leaks last month. This means that the malware is infecting machines by sending a specially crafted packet to vulnerable SMB shares.

The worm functionality attempts to infect unpatched Windows machines in the local network. At the same time, it also executes massive scanning on Internet IP addresses to find and infect other vulnerable computers. This activity results in large SMB traffic from the infected host.

The Internet scanning routine randomly generates octets to form the IPv4 address. The malware then targets that IP to attempt to exploit CVE-2017-0145. The threat avoids infecting the IPv4 address if the randomly generated value for first octet is 127 or if the value is equal to or greater than 224, in order to skip local loopback interfaces. Once a vulnerable machine is found and infected, it becomes the next hop to infect other machines. The vicious infection cycle continues as the scanning routing discovers unpatched computers.

Once on a machine the malware then searches for the following file types which it then encrypts:

.123, .jpeg , .rb , .602 , .jpg , .rtf , .doc , .js , .sch , .3dm , .jsp , .sh , .3ds , .key , .sldm , .3g2 , .lay , .sldm , .3gp , .lay6 , .sldx , .7z , .ldf , .slk , .accdb , .m3u , .sln , .aes , .m4u , .snt , .ai , .max , .sql , .ARC , .mdb , .sqlite3 , .asc , .mdf , .sqlitedb , .asf , .mid , .stc , .asm , .mkv , .std , .asp , .mml , .sti , .avi , .mov , .stw , .backup , .mp3 , .suo , .bak , .mp4 , .svg , .bat , .mpeg , .swf , .bmp , .mpg , .sxc , .brd , .msg , .sxd , .bz2 , .myd , .sxi , .c , .myi , .sxm , .cgm , .nef , .sxw , .class , .odb , .tar , .cmd , .odg , .tbk , .cpp , .odp , .tgz , .crt , .ods , .tif , .cs , .odt , .tiff , .csr , .onetoc2 , .txt , .csv , .ost , .uop , .db , .otg , .uot , .dbf , .otp , .vb , .dch , .ots , .vbs , .der” , .ott , .vcd , .dif , .p12 , .vdi , .dip , .PAQ , .vmdk , .djvu , .pas , .vmx , .docb , .pdf , .vob , .docm , .pem , .vsd , .docx , .pfx , .vsdx , .dot , .php , .wav , .dotm , .pl , .wb2 , .dotx , .png , .wk1 , .dwg , .pot , .wks , .edb , .potm , .wma , .eml , .potx , .wmv , .fla , .ppam , .xlc , .flv , .pps , .xlm , .frm , .ppsm , .xls , .gif , .ppsx , .xlsb , .gpg , .ppt , .xlsm , .gz , .pptm , .xlsx , .h , .pptx , .xlt , .hwp , .ps1 , .xltm , .ibd , .psd , .xltx , .iso , .pst , .xlw , .jar , .rar , .zip , .java , .raw.

As well as performing the following:

  • The most common variant uses IPC$ shares and SMB resources to propagate.
  • WannaCry installs the DOUBLEPULSAR backdoor. It corrupts shadow volumes to make recovery harder. (Source: Malwarebytes)
  • On the LAN, it scans for all enumerated addresses within its LAN with an open port 445 & 139 (i.e. the SMB port).
  • On the internet, it scans for random IP addresses to see if it has an open port 445. If it finds one with an open port, it scans all devices in the same /24 IP range (i.e. IP addresses that share the first three octets) as the found address.
  • Kills SQL Server, Exchange, MySQL and installs TOR on the endpoint.
  • When the ransom demand-time elapses, the malware writes up to 1GB of free space on host-disk and then deletes the file.
  • Removes volume shadow copies and the windows recovery manager.

How to Protect Yourself

As with all malware attacks the importance of good backups is a great fall back point. This is the same whether your machine is your own or company owned.  However this a very reactive measure and should only be used if you have already suffered from a ransomware attack. Rather than waiting for a strike it is better to take a proactive approach to security and protecting yourself before the worst case scenario becomes a reality.

In this case proactive protection is better than reactive. The SMB exploit was fixed in MS17-010 for all versions of Windows from Vista. However a lot of organisations rely upon delayed patching to ensure deployment of patches has limited business impact. To ensure protection in this case  the following are recommended steps all companies should make:

  • Determine your exposure risk and potential risk implications
  • Backup all critical data to either the cloud or removable media
  • Create a recoverable image of your critical servers and services
  • Close all unnecessary ports (see below for SMBv1)
  • Collaborate with customers, vendors and clients. The vulnerability in use has been patched so awareness is the easiest path to removing this threat
  • Update all endpoint protection
  • Block connections to TOR nodes
  • Formalise incident responses

Disable SMBv1

For customers running Windows Vista and later

  1. Open Powershell and enter:Set-ItemProperty -Path “HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters” SMB1 -Type DWORD -Value 0 -Force

Windows 8.1 or Windows Server 2012 R2 and later

For client operating systems:

  1. Open Control Panel, click Programs, and then click Turn Windows features on or off.
  2. In the Windows Features window, clear the SMB1.0/CIFS File Sharing Support checkbox, and then click OK to close the window.
  3. Restart the system.

For server operating systems:

  1. Open Server Manager and then click the Manage menu and select Remove Roles and Features.
  2. In the Features window, clear the SMB1.0/CIFS File Sharing Support check box, and then click OK to close the window.
  3. Restart the system.

Patch the system for the MS17-010 specifically.

The clever guys over at Kloud Blog have put together a PowerShell script to detect if a hotfix which covers the vulnerability has been installed:

[codesyntax lang=”powershell” container=”pre”]

#— Script start
# List of all HotFixes containing the patch
$hotfixes = @(‘KB3205409’, ‘KB3210720’, ‘KB3210721’, ‘KB3212646’, ‘KB3213986’, ‘KB4012212’, ‘KB4012213’, ‘KB4012214’, ‘KB4012215’, ‘KB4012216’, ‘KB4012217’, ‘KB4012218’, ‘KB4012220’, ‘KB4012598’, ‘KB4012606’, ‘KB4013198’, ‘KB4013389’, ‘KB4013429’, ‘KB4015217’, ‘KB4015438’, ‘KB4015546’, ‘KB4015547’, ‘KB4015548’, ‘KB4015549’, ‘KB4015550’, ‘KB4015551’, ‘KB4015552’, ‘KB4015553’, ‘KB4015554’, ‘KB4016635’, ‘KB4019213’, ‘KB4019214’, ‘KB4019215’, ‘KB4019216’, ‘KB4019263’, ‘KB4019264’, ‘KB4019472’, ‘KB4015219’, ‘KB4016636’, ‘KB4019473’)
# Search for the HotFixes
$hotfix = Get-HotFix | Where-Object {$hotfixes -contains $_.HotfixID} | Select-Object -property “HotFixID”
# See if the HotFix was found
if (Get-HotFix | Where-Object {$hotfixes -contains $_.HotfixID})
    write-host “Found hotfix” $_.HotfixID
    write-host “Didn’t find hotfix”
#— Script end


This should be ran on all windows machines in your environment. If it comes back with “Didn’t find hotfix” for any machine then the machine should be patched immediately using any one of the KB articles listed in the $hotfixes variable.

What to do if we have been infected

If you have been infected it is important not to panic and approach the recovery in a professional and calm manner. Although business units will often be pushing for a quick resolution doing so can lead to things being missed and subsequent re-infection.

Some guidelines to what to do if you are infected below:

  • Shutdown and disconnect any infected machine.
  • Isolate, where possible, infected machines.
  • Close all unnecessary open ports within the environment.
  • Disable SMBv1 via any method possible on the remaining machines.
  • Create an inventory of infected machines.
  • Check all interconnected devices for signs of infection.
    • AV scan the devices after updating EPP
    • Scan for encrypted files
    • Check for spikes in file renames
    • Check the list of known indicators from the Excel document supplied by the US Cert Office
  • Work with the correct business units to communicate the problem to your customers.
  • Send internal communications to raise awareness and also mitigate any user based attack vectors
  • Restore from cloud backups or removable media.

For more information around protecting yourself against this and other Equation Group vulnerabilities, check here.

Good Luck!

EDIT: A decryption tool is now available. Although it offers no guarantees to working if you have been infected it’s definitely worth a try. Pop over to MalwareBytes and download it.