Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

Security Research & Defense

  • Security Advisory 2953095: recommendation to stay protected and for detections

    Today, Microsoft released Security Advisory 2953095 to notify customers of a vulnerability in Microsoft Word. At this time, we are aware of limited, targeted attacks directed at Microsoft Word 2010.

    This blog will discuss mitigations and temporary defensive strategies that will help customers to protect themselves while we are working on a security update. This blog also provides some preliminary details of the exploit code observed in the wild.


    Mitigations and Workaround

    The in the wild exploit takes advantage of an unspecified RTF parsing vulnerability combined with an ASLR bypass, which depends by a module loaded at predictable memory address.

    First, our tests showed that EMET default configuration can block the exploits seen in the wild. In this case, EMET’s mitigations such as “Mandatory ASLR” and anti-ROP features effectively stop the exploit. You can find more information about EMET at The exploit code seems to target Word 2010 and it deeply relies on the specific ASLR bypass mentioned. We were glad to see in our tests that this exploit fails (resulting in a crash) on machines running Word 2013, due to the ASLR enforcement introduced for this product.

    In addition to EMET mitigations, users may consider to apply stronger protections by blocking the root cause of the issue with one of the following suggested workarounds:

    • disable opening of RTF files;

    • enforce Word to open RTF files always in Protected View in Trust Center settings.

    To facilitate deployment of the first workaround, we are providing a Fix it automated tool. The Fix it uses Office’s file block feature and adds few registry keys to prevent opening of RTF files in all Word versions. After the Fix it is installed, opening RTF file will result in the following message:


    If blocking RTF files is not an option, enterprise could enforce “Open selected file types in Protected View” instead of “Do not open selected file types” in Trust Center settings. The “Protected View” mode in Office 2010/2013 does not allow ActiveX controls to load. This will mitigate the attack we observed. Once the workaround is enabled, Word will prompt the Protected View gold bar, but will still allow the preview of the document.

    Enterprise admins may also consider to make their own custom protection using Trust Center features of Office instead of the Fix it, since these settings can be managed and deployed through GPO. For more details, please refer to:



    Theoretical Outlook attack vector

    There is a theoretical Outlook attack vector for RTF vulnerabilities through the preview pane. The reduced functionality of the preview pane makes this attack vector extremely hard to carry, and to date we have never seen exploits leveraging this mechanism.


    Technical details of the exploit

    The attack detected in the wild is limited and very targeted in nature. The malicious document is designed to trigger a memory corruption vulnerability in the RTF parsing code. The attacker embedded a secondary component in order to bypass ASLR, and leveraged return-oriented-programming techniques using native RTF encoding schemes to craft ROP gadgets. The structure of the malicious document and the individual blocks is described in the picture below.

    When the memory corruption vulnerability is triggered, the exploit gains initial code execution and in order to bypass DEP and ASLR, it tries to execute the ROP chain that allocates a large chunk of executable memory and transfers the control to the first piece of the shellcode (egghunter). This code then searches for the main shellcode placed at the end of the RTF document to execute it.

    One peculiar aspect of the main shellcode is the fact that it employs multiple consecutive layers of decryption and well-known anti-debugging tricks, such as test of debugging flags an, RDTSC timing checks and jump-hops over hooks, possibly to defeat automated sandbox, analysis tools and researchers. The shellcode has also been programmed with a special date-based deactivation logic. In fact, it parses the content of “C:\Windows\SoftwareDistribution\ReportingEvents.log” file and it scans all the available Microsoft updates installed on the machine. The shellcode will not perform any additional malicious action if there are updates installed after April, 8 2014. This means that even after a successful exploitation with reliable code execution, after this date the shellcode may decide to not drop the secondary backdoor payload and simply abort the execution. When the activation logic detects the correct condition to trigger, the exploit drops in the temporary folder a backdoor file named ‘svchost.exe’ and runs it. The dropped backdoor is a generic malware written in Visual Basic 6 which communicates over HTTPS and relies on execution of multiple windows scripts via WScript.Shell and it can install/run additional MSI components.


    Detection and indicators for defenders

    We are providing a good list of IOCs (Indicator of Compromise) hoping to facilitate defensive efforts and to help security vendors and professionals to stay protected from this specific attack. The remote C&C server used by the current backdoor in the file uses encrypted SSL traffic with a static self-signed certificate that can be easily detected.



    rule SA2953095_RTF
         description = "MS Security Advisory 2953095"

        $badHdr   = "{\\rt{"
        $ocxTag   = "\\objocx\\"
        $mscomctl = "MSComctlLib."
        $rop      = "?\\u-554"

        filesize > 100KB and filesize < 500KB
        and $badHdr and $ocxTag and $mscomctl and #rop>8


    Filename: %TEMP%\svchost.exe

    MD5: af63f1dc3bb37e54209139bd7a3680b1
    SHA1: 77ec5d22e64c17473290fb05ec5125b7a7e02828


    C&C Server:
    h**ps:// Port: 443

    NOTE: on port 80 the C&C host serves a webpage mimicking the content of “” website

    GET request example:

    User-Agent string:
    “Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64;2*Uuhgco}%7)1”


        O=My Company Ltd
     NotBefore: 1/1/2013 3:33 AM
     NotAfter: 1/1/2014 3:33 AM

    Public Key Length: 1024 bits
    Public Key: UnusedBits = 0

        0000  30 81 89 02 81 81 00 dc  72 fc af 8f 51 de 2d 27
        0010  3e de ad 21 ae 25 11 b6  b0 6e ce 6d 79 e4 d3 81
        0020  4e 73 11 44 51 63 09 3b  1c e7 79 1f 85 82 94 c1
        0030  e1 f1 83 b3 1c 6d 53 58  28 07 b5 80 86 30 51 2d
        0040  78 c0 48 e8 b2 8d fb 84  e1 d1 59 ff d5 4e 1f 8f
        0050  ff 60 44 56 6b 7b 4d 72  42 d6 da 6a 4c d4 6b 7d
        0060  f1 68 4d 2c 62 58 53 e7  cd cc a1 a4 a2 7a 29 7d
        0070  63 eb 42 30 af 24 eb 20  4c 86 f5 9e 6f 48 1c bd
        0080  28 aa 47 13 4b cc 53 02  03 01 00 01

    Cert Hash(md5): f0 82 aa f8 16 0e 83 8c 20 d7 95 f0 9d d2 01 57
    Cert Hash(sha1): df 72 40 fb 9b cd 53 12 eb a5 f9 c2 dd e7 a2 9a 1d c8 f3 55


    Faulting application name: WINWORD.EXE,
    version: 14.0.7113.5001, time stamp: 0x52866c04
    Faulting module name: unknown,
    version:, time stamp: 0x00000000
    Exception code: 0xc0000005
    Fault offset: 0x40002???
    Faulting process id: n/a
    Faulting application start time: n/a
    Faulting application path: C:\Program Files\Microsoft Office\Office14\WINWORD.EXE
    Faulting module path: unknown 



    Registry key added:
    HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\Windows Startup Helper=”%windir%\system32\wscript.exe %TEMP%\[malicious.vbs]”

    Service name (possibly) created:


    - Chengyun Chu and Elia Florio, MSRC Engineering


  • MS14-019 – Fixing a binary hijacking via .cmd or .bat file

    Command (.cmd) and batch (.bat) files can be directly provided as input to the CreateProcess as if it is an executable. CreateProcess uses the cmd.exe automatically to run the input .cmd or .bat.


    Today, with the bulletin MS14-019 we are fixing a vulnerability, where in particular scenario it is possible to hijack the cmd.exe with a copy present in the attacker controlled current working directory (CWD) of an affected application.


    The typical attack vector for this vulnerability is same as the DLL hijacking, i.e., via opening an application specific file in a WebDav/SMB share invoking the targeted application automatically because of file association. The targeted application will be vulnerable only if they ever do CreateProcess on .cmd or .bat file irrespective of where the file is located. That means attacker need not control the .cmd or .bat file. Another important thing for exploiting this vulnerability, is that the application should set the directory from where the associated file was opened as its CWD.


    As such we are not aware of any application that is affected by this vulnerability. But we understand the security issue this vulnerability can pose to some of the applications, so we are addressing this as an important severity bulletin.


    The way we are fixing this issue is to always invoke the system version of the cmd.exe for the input .cmd or .bat file during process creation. This fix could affect applications which does CreateProcess on .bat or .cmd file directly and depend on a different version of the cmd.exe other than the one present in Sytem directory by copying them in either application directory or CWD. Such applications should pass fully qualified path to the version of cmd.exe as input while performing CreateProcess, and pass .cmd or .bat as input parameters.


    Applications passing just cmd.exe to the CreateProcess to run the .cmd or .bat as input could also be vulnerable for similar binary hijacking. This bulletin is not to address such vulnerable usage since it is application specific problem as they are not passing fully qualified system path to cmd.exe. Such application should fixed to pass fully qualified cmd.exe path or just passing .cmd or .bat file as input.


    - Swamy Shivaganga Nagaraju, MSRC engineering team

  • When ASLR makes the difference

    We wrote several times in this blog about the importance of enabling Address Space Layout Randomization mitigation (ASLR) in modern software because it’s a very important defense mechanism that can increase the cost of writing exploits for attackers and in some cases prevent reliable exploitation. In today’s blog, we’ll go through ASLR one more time to show in practice how it can be valuable to mitigate two real exploits seen in the wild and to suggest solutions for programs not equipped with ASLR yet.


    Born with ASLR

    ASLR mitigation adds a significant component in exploit development, but we realized that sometimes a single module without ASLR loaded in a program can be enough to compromise all the benefits at once. For this reason recent versions of most popular Microsoft programs were natively developed to enforce ASLR automatically for every module loaded into the process space. In fact Internet Explorer 10/11 and Microsoft Office 2013 are designed to run with full benefits of this mitigation and they enforce ASLR randomization natively without any additional setting on Win7 and above, even for those DLLs not originally compiled with /DYNAMICBASE flag. So, customers using these programs have already a good native protection and they need to take care only of other programs potentially targeted by exploits not using ASLR.


    ASLR effectiveness in action

    Given the importance of ASLR, we are taking additional efforts to close gaps when ASLR bypasses arise in security conferences from time to time or when they are found in-the-wild used in targeted attacks. The outcome of this effort is to strength protection also for previous versions of Microsoft OS and browser not able to enforce ASLR natively as IE 10/11 and Office 2013 can do. Some examples of recent updates designed to break well-known ASLR bypasses are showed in the following table.







    Reported in Pwn2Own 2013, works only for Win7 x64 


    HXDS.DLL (Office 2007/2010)


    Seen used in-the-wild with IE/Flash exploits
    (CVE-2013-3893, CVE-2013-1347,
    CVE-2012-4969, CVE-2012-4792)




    Seen used in-the-wild with IE exploits

    We were glad to see the return of these recent ASLR updates in two recent attacks: the Flash exploit found in February (CVE-2014-0502) in some
    targeted attacks and a privately reported bug for IE8 (CVE-2014-0324) just patched today. As showed from the code snippets below, the two exploits would not have been effective against fully patched machines with MS13-106 update installed running Vista or above.



    Exploit code for CVE-2014-0502 (Flash)

    Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106.

    NOTE: the code attempts also a second ASLR bypass based on Java 1.6.x


    Exploit code for CVE-2014-0324 (IE8)

    Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106.

    Solutions for non-ASLR modules

    The two exploit codes above shows another important lesson: even if Microsoft libraries are compiled natively with ASLR and even if we work hard to fix known ASLR gaps for our products, there are still opportunities for attackers in using third-party DLLs to tamper the ASLR ecosystem. The example of Java 1.6.x is a well-known case: due to the popularity of this software suite and due to the fact that it loads an old non-ASLR library into the browser (MSVCR71.DLL), it became a very popular vector used in exploits to bypass ASLR. In fact, security researchers are frequently scanning for popular 3rd party libraries not compiled with /DYNAMICBASE that can allow a bypass; the following list is just an example of few common ones.




    Java 1.6.x (MSVCR71.DLL)

     Very common ASLR bypass used in-the-wild for multiple CVEs

     NOTE: Java 1.7.x uses MSVCR100.DLL which supports ASLR

    DivX Player 10.0.2

    Yahoo Messenger

    AOL Instant Messenger

     (not seen in real attacks)




     (not seen in real attacks)





     Ref: KISA report

     (seen in-the-wild with CVE-2013-3893)



    As noted at beginning of this blog, Internet Explorer 10/11 and Office 2013 are not affected by ASLR bypasses introduced by 3rd party modules and plugins. Instead, customers still running older version of Internet Explorer and Office can take advantage of two effective tools that can be used to enforce ASLR mitigation for any module:


    ASLR bypasses do not represent vulnerabilities, since they have to be combined with a real memory corruption vulnerability in order to allow attackers to create an exploit, however it's nice to see that closing ASLR bypasses can negatively impact the reliability of certain targeted attacks. We encourage all customers to proactively test and deploy the suggested tools when possible, especially for old programs commonly targeted by memory corruption exploits. We expect that attackers will continue increasing their focus and research on more sophisticated ASLR bypasses which rely on disclosure of memory address rather than non-ASLR libraries.


    - Elia Florio, MSRC Engineering


  • Assessing risk for the April 2014 security updates

    Today we released four security bulletins addressing 11 unique CVE’s.  Two bulletins have a maximum severity rating of Critical while the other two have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.


    Bulletin Most likely attack vector Max Bulletin Severity Max exploitability Likely first 30 days impact Platform mitigations and key notes



    Victim opens a malicious RTF or DOC/DOCX file. Critical 1 Likely to continue to see RTF and DOC based exploits for CVE-2014-1761. Addresses vulnerability described by Security Advisory 2953095, an issue under targeted attack.


    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days.



    Victim opens malicious Publisher (.PUB) file. Important 1 While we may see reliable exploits developed within the next 30 days, unlikely to see widespread exploitation due to limited deployment of Publisher.


    (Windows File Handling)

    Attacker places malicious .bat and/or .cmd file on a network share from which a victim launches an application that calls CreateProcess in an unsafe manner.  Similar attack vector as DLL preloading. Important 1 While this is an exploitable vulnerability, we have historically not seen widespread exploitation of this type of vulnerability. More details about this vulnerability in this SRD blog post today.


    - Jonathan Ness, MSRC engineering team

  • More Details about Security Advisory 2963983 IE 0day

    Today we released Security Advisory 2963983 regarding a potential vulnerability in Internet Explorer reported by FireEye and currently under investigation.

    We are working closely with FireEye to investigate this report of a vulnerability which was found used in very limited targeted attack:

    -          the vulnerability is a “use-after-free” memory corruption and the exploit observed seems to target IE9, IE10 and IE11;

    -          while the vulnerability affects Internet Explorer, the exploit relies deeply on two other components to successfully trigger code execution and in particular it requires presence VML and Flash components;

    Our partner FireEye posted an analysis with some details and confirmed that the exploit wasn’t able to run successfully when EMET protection is added for Internet Explorer. The following EMET configuration can help to mitigate this specific exploit seen in the wild:

    -          EMET 4.0 / 4.1: all mitigations enabled, deephooks/antidetour enabled

    -          EMET 5.0TP: all mitigations enabled (including ASR/EAF+), deephooks/antidetour enabled 

    Also, given the current details shared by FireEye, we believe that the exploit can be also mitigated by:

    -          Disable VML in IE.

    -          Run Internet Explorer in “Enhanced Protected Mode” configuration and 64-bit process mode, which is available for IE10 and IE11 in the Internet Options settings:

    Cristian Craioveanu, Elia Florio and Chengyun Chu, MSRC Engineering


  • Additional information about CVE-2014-6324

    Today Microsoft released update MS14-068 to address CVE-2014-6324, a Windows Kerberos implementation elevation of privilege vulnerability that is being exploited in-the-wild in limited, targeted attacks. The goal of this blog post is to provide additional information about the vulnerability, update priority, and detection guidance for defenders. Microsoft recommends customers apply this update to their domain controllers as quickly as possible.

    Vulnerability Details

    CVE-2014-6324 allows remote elevation of privilege in domains running Windows domain controllers. An attacker with the credentials of any domain user can elevate their privileges to that of any other account on the domain (including domain administrator accounts).

    The exploit found in-the-wild targeted a vulnerable code path in domain controllers running on Windows Server 2008R2 and below. Microsoft has determined that domain controllers running 2012 and above are vulnerable to a related attack, but it would be significantly more difficult to exploit. Non-domain controllers running all versions of Windows are receiving a “defense in depth” update but are not vulnerable to this issue.

    Before talking about the specific vulnerability, it will be useful to have a basic understanding of how Kerberos works.


    One point not illustrated in the diagram above is that both the TGT and Service Ticket contain a blob of data called the PAC (Privilege Attribute Certificate). A PAC contains (among other things):

    • The user’s domain SID
    • The security groups the user is a member of


    When a user first requests a TGT from the KDC, the KDC puts a PAC (containing the user’s security information) into the TGT. The KDC signs the PAC so it cannot be tampered with. When the user requests a Service Ticket, they use their TGT to authenticate to the KDC. The KDC validates the signature of the PAC contained in the TGT and copies the PAC into the Service Ticket being created.

    When the user authenticates to a service, the service validates the signature of the PAC and uses the data in the PAC to create a logon token for the user. As an example, if the PAC has a valid signature and indicates that “Sue” is a member of the “Domain Admins” security group, the logon token created for “Sue” will be a member of the “Domain Admins” group.

    CVE-2014-6324 fixes an issue in the way Windows Kerberos validates the PAC in Kerberos tickets. Prior to the update it was possible for an attacker to forge a PAC that the Kerberos KDC would incorrectly validate. This allows an attacker to remotely elevate their privilege against remote servers from an unprivileged authenticated user to a domain administrator.


    Update Priority

    1. Domain controllers running Windows Server 2008R2 and below
    2. Domain controllers running Windows Server 2012 and higher
    3. All other systems running any version of Windows


    Detection Guidance

    Companies currently collecting event logs from their domain controllers may be able to detect signs of exploitation pre-update. Please note that this logging will only catch known exploits; there are known methods to write exploits that will bypass this logging.


    The key piece of information to note in this log entry is that the “Security ID” and “Account Name” fields do not match even though they should. In the screenshot above, the user account “nonadmin” used this exploit to elevate privileges to “TESTLAB\Administrator”.

    After installing the update, for Windows 2008R2 and above, the 4769 Kerberos Service Ticket Operation event log can be used to detect attackers attempting to exploit this vulnerability. This is a high volume event, so it is advisable to only log failures (this will significantly reduce the number of events generated).


    After installing the update, exploitation attempts will result in the “Failure Code” of “0xf” being logged. Note that this error code can also be logged in other extremely rare circumstances. So, while there is a chance that this event log could be generated in non-malicious scenarios, there is a high probability that an exploitation attempt is the cause of the event.



    The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately.


    Additional Notes

    Azure Active Directory does not expose Kerberos over any external interface and is therefore not affected by this vulnerability.


    Joe Bialek, MSRC Engineering

  • Announcing EMET 5.0 Technical Preview

    Today, we are thrilled to announce a preview release of the next version of the Enhanced Mitigation Experience Toolkit, better known as EMET. You can download EMET 5.0 Technical Preview here. This Technical Preview introduces new features and enhancements that we expect to be key components of the final EMET 5.0 release. We are releasing this technical preview to gather customer feedback about the new features and enhancements. Your feedback will affect the final EMET 5.0 technical implementation. We encourage you to download this Technical Preview, try it out in a test environment, and let us know how you would like these features and enhancements to show up in the final version. If you are in San Francisco, California, for the RSA Conference USA 2014, please join us at the Microsoft booth (number 3005) for a demo of EMET 5.0 Technical Preview and give us feedback directly in person.  Several members of the EMET team will be demonstrating at the Microsoft booth for the entire Conference.

    As mentioned, this Technical Preview release implements new features to disrupt and block the attacks that we have detected and analyzed over the past several months. The techniques used in these attacks have inspired us with new mitigation ideas to disrupt exploitation and raise the cost to write reliable exploits. The EMET 5.0 Technical Preview also implements additional defensive mechanisms to reduce exposure from attacks.

    The two new features introduced in EMET 5.0 Technical Preview are the Attack Surface Reduction (ASR) and the Export Address Table Filtering Plus (EAF+). Similar to what we have done with EMET 3.5 Technical Preview, where we introduced a new set of mitigations to counter Return Oriented Programming (ROP), we are introducing these two new mitigations and ask for your feedback on how they can be improved. Of course, they are a “work in progress.” Our goal is to have them polished for the final version of EMET 5.0.

    Let’s see in detail what these two new mitigations do, and the reasoning that led us to their implementation.

    Attack Surface Reduction

    In mid-2013, we published a Fix it solution to disable the Oracle Java plug-in in Internet Explorer. We received a lot of positive feedback and a number of suggestions on how we could improve the Fix it. The most recurring suggestion we received was to allow the Oracle Java plug-in on intranet websites, which commonly run Line-of-Business applications written in Java, while blocking it on Internet Zone websites. In addition to that Java-related customer feedback, we have also seen a number of exploits targeting the Adobe Flash Player plug-in. For example, the RSA breach was enabled by an Adobe Flash Player exploit embedded inside a Microsoft Excel file and a number of targeted attacks have been carried out by Adobe Flash Player exploits embedded in Microsoft Word documents, as described by Citizen Lab. We decided to design a new feature that can be used to mitigate similar situations and to help to reduce the attack surface of applications. We call this feature Attack Surface Reduction (ASR), and it can be used as a mechanism to block the usage of a specific modules or plug-ins within an application. For example, you can configure EMET to prevent Microsoft Word from loading the Adobe Flash Player plug-in, or, with the support of security zones, you can use EMET to prevent Internet Explorer from loading the Java plug-in on an Internet Zone website while continuing to allow Java on Intranet Zone websites.

    The example below shows ASR in action, preventing Microsoft Word from launching an Adobe Flash Player file embedded in the document. By default, EMET 5.0 Technical Preview comes pre-configured to block certain plug-ins from being loaded by Internet Explorer, Microsoft Word and Microsoft Excel. The feature is fully configurable by changing two registry keys that list the names of the plug-ins to block, and, if supported, the security zones that allow exceptions. For more details on how to configure ASR please refer to the EMET 5.0 Technical Preview user guide.


    We also added new capabilities to the existing Export Address Table Filtering (EAF). EAF+ consolidates protection of lower-level modules and prevents certain exploitation techniques used to build dynamic ROP gadgets in memory from export tables. EAF+ can be enabled through the “Mitigation Settings” ribbon. When EAF+ is enabled, it will add the following additional safeguards over-and-above the existing EAF checks:

    • Add protection for KERNELBASE exports in addition to the existing NTDLL.DLL and KERNEL32.DLL

    • Perform additional integrity checks on stack registers and stack limits when export tables are read from certain lower-level modules

    • Prevent memory read operations on protected export tables when they originate from suspicious modules that may reveal memory corruption bugs used as “read primitives” for memory probing

    For example, the third protection mechanism in the list above mitigates the exploitation technique developed in Adobe Flash Player used in some recent Internet Explorer exploits (CVE-2013-3163 and CVE-2014-0322), where the attacker attempted to build ROP gadgets by scanning the memory and parsing DLL exports using ActionScript code. Exploits for these vulnerabilities are already blocked by other EMET mitigations. EAF+ provides another way to disrupt and defeat advanced attacks. The screenshot below shows the exploit for CVE-2014-0322 in action on Internet Explorer protected by EMET 5.0 Technical Preview with only EAF+ enabled.

    Other improvements

    This Technical Preview enables the “Deep Hooks” mitigation setting. We have been working with third-party software vendors whose products do not run properly with Deep Hooks enabled. We believe these vendors have resolved the application compatibility issues that previously existed with Deep Hooks enabled. We enable Deep Hooks in the Technical Preview to evaluate the possibility of having this setting turned on by default in the final EMET 5.0 release because it has proven to be effective against certain advanced exploits using ROP gadgets with lower level APIs. We have also introduced some additional hardening to protect EMET’s configuration when loaded in memory, and fixed several application compatibility issues including a common one that involves Adobe Reader and the “MemProt” mitigation.


    We’d like to thank Spencer J. McIntyre from SecureState, Jared DeMott from Bromium Labs, along with Peleus Uhley and Ashutosh Mehra from the Adobe Security team for their collaboration on the EMET 5.0 Technical Preview.

    We are excited for this Technical Preview and we hope that the additions are as valuable for our customers as they are for us. We invite you to install and give EMET 5.0 Technical Preview a try; we look forward to hearing your feedback and suggestions on how to enhance the new features that we have introduced. We would also welcome any suggestions for additional new features you’d like to see included in the final version of EMET 5.0. We greatly value the feedback we receive, and we want to build a product that not only provides additional protection to systems but is also easy to use and configure. We then invite you all to download EMET 5.0 Technical Preview and drop us a line!

    • The EMET Team

  • Continuing with Our Community Driven, Customer Focused Approach for EMET

    The Enhanced Mitigation Experience Toolkit, best known as EMET, helps raise the bar against attackers gaining access to computer systems. Since the first release of EMET in 2009, our customers and the security community have adopted EMET and provided us with valuable feedback. Feedback both in forums and through Microsoft Premier Support Services, which provides enterprise support for EMET, has helped shape the new EMET capabilities to further expand the range of scenarios it addresses.

    Today, we will be talking about how we are taking our community driven and customer focused approach even further. We will cover both the present version (4.1) as well as the future versions (5.0 Technical Preview and beyond) in detail next.

    What you are about to read is the outcome of our work over the past couple of months listening to customer and community feedback. Keep in mind that we are always working on new things, so… stay tuned! :) As always, please let us know what you think.

    - The EMET Team

    EMET 5.0 Technical Preview available on Microsoft Connect

    The release of EMET 5.0 Technical Preview in late February had a tremendous response from customers and the industry. We have received a lot of feedback on the new features and how they can be further improved. We believe EMET is and should continue to be customer-driven, where the feedback we receive is an integral part of our development process. In order to facilitate and streamline the communication between you (our beloved customers) and us (the EMET team), we have decided to create a project on Microsoft Connect for EMET 5.0 Technical Preview. Simply access the Microsoft Connect tool to download packages – which will be released periodically and frequently – and have a taste of what is coming up for EMET 5.0. What is great about this new tool is that, you will able to provide direct feedback, respond to surveys, and find all the new additions.

    The first download package for EMET 5.0 Technical Preview is already available, and it includes fixes for many items reported to us. Please subscribe to the Microsoft Connect for EMET 5.0 Technical Preview (you will need a Microsoft Account for that), download the installation package and continue to send your great ideas to us.

    EMET 4.1 Update 1

    Today, we are releasing EMET 4.1 Update 1, which contains improvements and bug-fixes. More details on the list of the introduced improvements are available at this KB article. These improvements are the outcome of the feedback you have given us and the forward thinking work we continue to do. We recommend all EMET 4.1 customers download this new version and install it, since the benefits of all these improvements are noticeable. The upgrade experience is seamless, as all the current settings can be kept as-is by choosing “Keep Existing Settings” option during the install process. We also recommend all EMET 3.0 and 4.0 customers to upgrade to EMET 4.1 Update 1 (remember EMET 3.0 will go out of support next June!).

    Certificate Trust default rules update

    With EMET 4.0, we introduced the Certificate Trust, which is a feature that detects Man in the Middle attacks that leverage maliciously-issued SSL/TLS certificates. The feature works through a configurable certificate-pinning mechanism, which binds the certificate for a specified website to a trusted Root Certificate Authority (Root CA). This feature comes pre-configured with a set of rules related to authentication portals for Microsoft services and other third-party services. These default rules used in Certificate Trust don’t require frequent updates. It can happen, however, that an organization decides to renew its SSL/TLS certificate, for different reasons (e.g. natural aging of the certificate, change in their PKI infrastructure, response to a security incident, etc.). When a change like this occurs, the renewed SSL/TLS certificate may be issued under a different Root CA not included in the default Certificate Trust configuration, resulting in EMET detecting the new certificate as malicious.

    Since several SSL/TLS certificates for many popular third-party websites were recently updated, we are releasing an easy to install Fix it solution that will update the default Certificate Trust rules, while maintaining the ones that you have manually added. The Fix it can be either installed on a standalone machine by just double-clicking it, or it can be silently deployed throughout a network with your favorite deployment mechanism. If you have just downloaded and installed EMET 4.1 Update 1 you don’t need to apply this Fix it solution as the new rules are already included. You can use the link below to download this solution:

    Microsoft Fix it 51012

    Fix this problem
    Microsoft Fix it 51012

  • Fix it tool available to block Internet Explorer attacks leveraging CVE-2014-0322

    Today, we released Security Advisory 2934088 to provide guidance to customers concerned about a new vulnerability found in Internet Explorer versions 9 and 10. This vulnerability has been exploited in limited, targeted attacks against Internet Explorer 10 users browsing to and We will cover the following topics in this blog post:

    • Platforms affected
    • Steps you can take to stay safe
    • More details about the vulnerability
    • More details about the Fix It tool

    Platforms Affected

    As described in Security Advisory 2934088, both Internet Explorer 9 and Internet Explorer 10 contain the vulnerable code. However, we have not seen any exploit code capable of triggering the vulnerability on Internet Explorer 9. The chart below may help explain the risk by platform:

      Windows XP
    Server 2003
    Windows Vista
    Server 2008
    Windows 7
    Server 2008 R2
    Windows 8
    Server 2012
    Windows 8.1
    Server 2012 R2
    Internet Explorer 6 Not vulnerable n/a n/a n/a n/a
    Internet Explorer 7 Not vulnerable Not vulnerable n/a n/a n/a
    Internet Explorer 8 Not vulnerable Not vulnerable Not vulnerable n/a n/a
    Internet Explorer 9 n/a Vulnerable,
    not under attack
    not under attack
    n/a n/a
    Internet Explorer 10 n/a n/a Under attack Under attack n/a
    Internet Explorer 11 n/a n/a Not vulnerable n/a Not vulnerable

    Steps you can take to stay safe

    Any of the following three protection mechanisms will protect you from exploits we have seen that leverage this vulnerability for code execution:

    1 – Upgrade to Internet Explorer 11

    2 – Install the Enhanced Mitigation Experience Toolkit (EMET)

    3 – Install the Fix it workaround tool

    Upgrading to Internet Explorer 11 is the best way to stay safe from exploit attempts targeting this vulnerability.

    The Enhanced Mitigation Experience Toolkit (EMET) is also an effective way to block the targeted attacks we have analyzed. This particular exploit explicitly checks for EMET and refuses to run on any system where EMET is installed. However, even with the exploit’s EMET check removed, the default configuration of EMET blocks the attack. In this particular case, EMET’s EAF and Anti-Detour features block the exploit in the default EMET configuration. With EMET’s “Deep Hooks” feature enabled, the MemProt, StackPivot, and CallerCheck features each independently are capable of blocking this exploit. We are pleased to see EMET continuing to provide protection for a significant portion of memory corruption exploits today. On that note, we found that in the second half of 2013, all in-the-wild exploits that we encountered that have leveraging memory corruption for code execution were blocked by EMET! We recommend that all customers install this tool. Watch next week for an announcement at the RSA Conference about the future of EMET.

    The third, and likely easiest way to protect yourself from attempts to exploit the vulnerability, is to install the Fix it workaround tool released in today’s advisory. You can refer to Knowledge Base Article 2934088 for complete details but simply clicking through the “Fix It” installer from the following link will protect your system from attempts to exploit the vulnerability:

    Installing the Fix it does not require a reboot but administrative privileges on the system are required. The Fix it installation will be effective on any Internet Explorer 9 or Internet Explorer 10 system where the most recently-released security update (MS14-010) has already been installed. More specifically, the appcompat shim is enabled for the Internet Explorer process where mshtml.dll is one of the following four versions: 9.0.8112.16533, 9.0.8112.20644, 10.0.9200.16798, or 10.0.9200.20916. The eventual security update that addresses this vulnerability will ship with an incremented mshtml.dll version number, thereby automatically obsoleting this Fix it.

    You can read more about previous instances of this temporary workaround technique at Fix its have been a popular mitigation technique with our customers to cover the gap between the time when an exploit appears and the time when a final, comprehensive, fully-tested security update is available for wide distribution. The last instance of a Fix It tool to address an Internet Explorer vulnerability (addressed by MS13-080) was installed on 23 million computers. The most recent security-related Fix it solution mitigated an Office vulnerability that was subsequently addressed by MS13-096. That Fix It solution was installed on 57 million computers. We mention these numbers with the hope of giving you confidence that a number of your IT Pro peers are using Fix it solutions to protect their enterprise network.

    More details about the vulnerability and exploit

    CVE-2014-0322 describes an mshtml.dll use-after-free vulnerability involving the CMarkup object being accessed after it has been freed. As described above, this vulnerability is present in both Internet Explorer 9 and Internet Explorer 10 but exploits we have seen target only 32-bit Internet Explorer 10. The exploit was explained in greater detail on the FireEye security blog. To recap, it uses Javascript to trigger the use-after-free condition and then uses Flash to convert a write primitive into a read/write primitive that enables DEP and ASLR to be bypassed. The primitive conversion happens by redirecting a write based on a freed object’s data (which has now been reallocated by the attacker) to corrupt a size field inside a Flash object. The corrupted size field in the Flash object is used to read and write outside of the object’s boundary, allowing discovery of module addresses in Internet Explorer’s Address Space. We are not aware of any elevation of privilege or sandbox escape vulnerability being used to “break out” of the Internet Explorer Protected Mode sandbox. Therefore, even after the exploit gains code execution, it still needs a non-trivial element to result in a persistent compromise of the computer.

    More details about the Fix it tool

    The Fix it redirects execution of two functions, mshtml!CMarkup::InsertElementInternal and mshtml!CMarkup::InsertTextInternal, to the code introduced by the appcompat shim. Similar changes are made in both functions. Let’s take a closer look at mshtml!CMarkup::InsertElementInternal:

    0:020> u mshtml!Cmarkup::InsertElementInternal
    e9d3d2a500      jmp     MSHTML!SZ_HTMLNAMESPACE+0xf (66bb43c7) // we redirect execution
    0:020> u 66bb43c7
    60              pushad	//save registers
    8bc8            mov     ecx,eax	//move the this* pointer to ecx
    e818468bff      call    MSHTML!CMarkup::CLock::CLock+0x2 (664689e7)	//call into the code where we AddRef() on this CMarkup object
    61              popad	//restore our registers
    55              push    ebp  //execute the code we overwrote in the jump to this shim
    8bec            mov     ebp,esp
    e91c2d5aff      jmp     MSHTML!CMarkup::InsertElementInternal+0x5 (661570f4)	//jump back to the next instruction after the our redirection point

    Similar to the Fix it solution for CVE-2013-3893, the shim leverages slack space near the end of the mshtml.dll’s .text section. Astute readers may notice that the appcompat shim does not introduce any code to reduce the reference count on the CMarkup object. Said another way, the appcompat shim introduces a memory leak.  The memory is restored when an IE tab (process) is terminated. This minor side effect of the workaround tool is harmless and of course it won’t be present in the final comprehensive security update for this vulnerability.


    Thanks to Richard Van Eeden, Axel Souchet, Chengyun Chu, and Elia Florio for the help triaging this vulnerability and help building the Fix it workaround tool.


    Please let us know if you have any questions about the risk posed by this vulnerability, the exploits we have seen leveraging the vulnerability for code execution, or mitigation opportunities available to protect your systems. You can email us at with [SRD] in subject line. Or if you plan to attend the RSA Conference in San Francisco, CA next week, feel free to stop by the Microsoft Booth #3005 to talk to us in person. We’re looking forward to announcing EMET news on Tuesday morning.

    - Neil Sikka, MSRC Engineering (@neilsikka)

  • Protection strategies for the Security Advisory 2963983 IE 0day

    We’ve received a number of customer inquiries about the workaround steps documented in Security Advisory 2963983 published on Saturday evening. We hope this blog post answers those questions.

    Steps you can take to stay safe

    The security advisory lists several options customers can take to stay safe. Those options are (in summary):

      • Deploy the Enhanced Mitigation Experience Toolkit (EMET)
      • Block access to VGX.DLL
      • Enable Enhanced Protected Mode
      • Use built-in Internet Explorer configuration options to disable active scripting

    We’ll address the questions we have heard from customers in relation to each of those options.

    Update on Enhanced Mitigation Experience Toolkit (EMET) protections

    The original security advisory and the SRD blog post from this past week both listed EMET 4.1 as effective in helping to block attacks. In our deeper analysis of the two exploit samples we have, we found that EMET 4.0 is also effective in helping to block attacks. The advisory and blog have both been updated to point out that both EMET 4.0 and EMET 4.1 are effective. Our technical preview of EMET version 5.0 also is effective in this regard; however, we do not recommend a technical preview for production deployment. Several customers asked which specific EMET mitigations were effective in helping to block attacks. We’ve prepared the following table to answer those questions:

    EMET 4.0 / EMET 4.1 EMET 5 Tech Preview
    Heapspray Protection Effective Effective
    StackPivot ROP Mitigation Effective with Deep Hooks enabled Effective
    Caller ROP Mitigation Effective with Deep Hooks enabled Effective
    MemProt ROP Mitigation Effective with Deep Hooks enabled Effective
    EAF+ Not present. EMET 4.x EAF does not block this attack. Effective
    Attack Surface Reduction Not present Effective because it blocks VGX.DLL and FLASH.ocx in Internet Zone

    As you can see, three of the four EMET 4.x mitigations capable of blocking this attack required the Deep Hooks feature to be enabled. The attackers in this case leveraged ZwProtectVirtualMemory which is not protected unless Deep Hooks is enabled. Deep Hooks is not enabled in the default configuration for EMET 4.0 or EMET 4.1. The default EMET 4.x install was effective in helping to block attacks due to the Heapspray mitigation alone; however, the ROP mitigations are more robust and less likely to be bypassed than the Heapspray mitigation so we recommend enabling Deep Hooks to get the full protection of the ROP mitigations.

    We have a planned update for EMET 4.1 scheduled for release on the Microsoft Download Center today. EMET 4.1 Update 1 was primarily released to address minor bug fixes. However, the update also will be enabling Deep Hooks for EMET 4.1 by default. We will post an additional SRD blog post when the EMET 4.1 Update 1 bits are live with a link to the KB describing the new release.

    Clarifying the VGX.DLL workaround

    The exploits we have seen have relied on Vector Markup Language (VML) to trigger the use-after-free vulnerability. As we analyzed different ways to trigger this vulnerability, we concluded that additional attacker research would be required to develop an exploit that did not rely on the presence of VML. Therefore, we recommended in the original security advisory that customers disable VGX.dll, the library that provides VML functionality. Customers can choose to either ACL the file or unregister the DLL. Unregistering the DLL can be accomplished with a single command line, silently, with no user interaction, and may be scripted to run via Microsoft System Center Configuration Manager or other infrastructure management solutions. VML is not natively supported by most web browsers today, so this remediation option may have the least impact on enterprise web app compatibility.

    However, we’d like to clarify that VGX.DLL does not contain the vulnerable code leveraged in this exploit. Disabling VGX.DLL is an exploit-specific workaround that provides an immediate, effective workaround to help block known attacks.

    Clarifying the IE Enhanced Protected Mode workaround

    We also received questions about the Internet Explorer Enhanced Protected Mode workaround. Enhanced Protected Mode will help protect 64-bit Internet Explorer users from this attack. There is a difference between Internet Explorer 10 and Internet Explorer 11 that led to some confusion. Internet Explorer 10 has one setting to enable and Internet Explorer 11 has two settings to enable. The 64-bit aspect of Internet Explorer is a key element of this workaround as the heap spray attack is not effective in 64-bit address space, leading to a failed exploit. Enhanced Protected Mode alone on 32-bit Internet Explorer 11 is not effective in blocking the attack. The screenshots below illustrate the Internet Explorer 10 versus Internet Explorer 11 “checkbox” differences:

    IE10 64bit EPM (one setting to mitigate) IE11 64bit EPM (two settings to mitigate)

    Choosing the best workaround for your environment

    The security advisory provides several different recommended workarounds because each customer environment is different and there might be a different “best” workaround for different customers. Each workaround has different pros and cons, described below.

    • Option 1: Deploy the Enhanced Mitigation Experience Toolkit
      • Pro: As described above, helps block exploits leveraging this vulnerability by adding several different hardening mechanisms to Windows.
      • Pro: Even after the eventual security update is applied, continues providing protection against other potential security vulnerabilities in Microsoft’s and third party products.
      • Con: Microsoft recommends testing before deploying widely across enterprise network as previous versions of EMET have introduced application compatibility issues.
    • Option 2: Block access to VGX.dll
      • Pro: Very simple workaround. Easy and quick to deploy across enterprise network.
      • Con: May not protect against future or new exploits that may emerge to exploit this vulnerability.
    • Option 3: Enable Enhanced Protected Mode on 64-bit Internet Explorer
      • Pro: Helps block exploits leveraging this vulnerability and potentially other vulnerabilities that may be discovered in the future.
      • Con: Requires 64-bit Windows and requires running 64-bit version of Internet Explorer.

    In general, for customers that already have EMET 4.x deployed, enabling Deep Hooks is likely to be the best workaround option. For customers who have not yet deployed EMET 4.x, the priority should be on immediate, quick protection which is likely to be blocking access to VGX.dll. Deploying EMET is the best long-term protection but doing so without first testing in your environment is unlikely to be the best option. As always, we recommend staying up-to-date with the latest version of Internet Explorer for improved security features such as Enhanced Protected Mode, better backward compatibility through Enterprise Mode, increased performance, and support for the modern web standards that run today’s websites and services.


    We hope that this blog post helps guide you in choosing the best mitigation strategy for your environment. The Internet Explorer team is hard at work preparing a security update that will be released as soon as it is ready for broad deployment. Stay tuned to the Microsoft Security Response Center (MSRC) blog [link] for any news about the availability of an update.

    - Elia Florio and Jonathan Ness, MSRC Engineering