Security Research & Defense

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

May, 2013

  • Java: A Fix it for when you cannot let go

    There is much to say about the use of Java in both consumer and enterprise environments. Like any other platforms, it has both devoted supporters and fervent critics. But for most, Java is a requirement, a means to an end.

    In the past few years, Java as a platform has been the target of numerous malware attacks, which exploit a number of Java runtime vulnerabilities on the target machines. The rise in Java exploitation has been attributed largely to unpatched software, although 0-day issues do creep in occasionally.

    Fortunately, there are steps that can be taken to mitigate some of these issues. Oracle is providing a series of measures to prevent unauthorized Java Applets and Web Start Applications from running by requiring them to be signed with a trusted certificate. This is a great start. However, not everybody runs an up-to-date version of Java runtime. For a long time, Java updates used to install side-by-side with older versions. That’s no longer the case, but the problem of unpatched software persists. In addition, there are legacy apps that require an older platform to run. 

    What can be done about this? If you need to run Java inside a browser, not much -- keep your software up to date and visit only trusted websites. If you only care about running Java desktop apps, there are a few mitigation steps that allow the customer to disable Java support inside your browser, leaving desktop functionality intact. These steps will remove a prevalent remote exploit vector, but at the same time keep Java installed for local applications. This subject has been covered elsewhere; for instance, here.

    Our customers tell us that the most effective mitigation tactics are both complete (covering all software versions, past and current) and friendly to enterprises, which face complex deployment issues. In order to address these concerns, we have issued an update to KB2751647 – How to disable Java web plugin in Internet Explorer. We are making available a “Microsoft Fix it” solution to block all Java web-attack vectors through Internet Explorer. The solution will work for all versions of Java (tested 5 and above) and all supported versions of Internet Explorer (32-bit or 64-bit):

    Apply Fix it

    Uninstall Fix it

    Microsoft Fix it 50994
      Microsoft Fix it 50994

    Microsoft Fix it 50995
      Microsoft Fix it 50995 

    The Fix it solution consists of two parts. The first makes use of Windows Application Compatibility Toolkit, changing the behavior of Internet Explorer at runtime so that it will prevent the load of Oracle’s Java Web plugins. This is achieved by hooking all LoadLibrary* functions so that they return NULL (last error ERROR_FILE_NOT_FOUND) when attempting to load all Java ActiveX dlls (npjpi*.dll, jp2iexp.dll). The second part prevents Internet Explorer from automatically opening JNLP files. It does this by clearing the ACL (access control list) of the JNLP protocol handler registry location (HKCR\JNLPFile), thus preventing all user apps from reading its contents.

    This solution covers current and past versions of Java, as well as foreseeable future versions. It does not interfere with Java’s update mechanism either. In fact, the Fix it works as expected even if installed prior to any installation of Java. It can also be easily deployed making use of the non-interactive options of msiexec.

    A mitigation.
    When you cannot let go, block
    Java in IE

    - Cristian Craioveanu, MSRC Engineering, with help and support from Elia Florio and Gerardo Di Giacomo (thank you!)


  • A few more days before EMET 4

    On May 8th, we announced that EMET 4 would have been released today, May 28th. Since that day, we had additional feedback and we are working on a few things that are requiring a little bit more time than expected.

    This considered, we are not releasing EMET 4 today, and we will take a few more days to have everything prepared for the final release. We are sure that you will not be disappointed by the additions we are working on before the final release.

    Also, at this point we don’t want to give a new release date yet, but expect to see EMET 4 in the next few days.

    Stay tuned!

    -          The EMET Team.

  • MS13-037 addressing Pwn2own vulnerabilities

    MS13-037 addresses a number of vulnerabilities in Internet Explorer, several of which were reported to us by the TippingPoint Zero Day Initiative (ZDI) program. We’ve gotten questions from customers about the specific vulnerabilities purchased by ZDI from the CanSecWest pwn2own contest. We’d like to use this blog post to provide more background on the set of vulnerabilities required for an attacker to exploit modern-day browsers and the state of fixes for those specific vulnerabilities.

    Exploiting recent versions of Internet Explorer

    Several years ago, a single memory corruption style vulnerability in the browser could be directly leveraged to compromise a system, could be used to run code in the context of the browsing user. Microsoft has invested heavily in platform-level mitigations for client-side applications such as browsers to the extent that today multiple different vulnerabilities must now be discovered and chained together in an exploit to compromise a system. A single memory corruption style vulnerability is just the start of an attacker’s discovery process. Typically, the attacker would need to also need to bypass ASLR and discover a way out of the IE Protected Mode limited code execution environment.

    Pwn2own 2013

    ZDI reported five separate vulnerabilities to Microsoft as a result of the contest:

    • VUPEN’s IE10 exploit
      • IE10 memory corruption style remote code execution vulnerability (CVE-2013-2551)
      • IE post-exploitation Low Integrity -> Medium Integrity escalation (CVE-2013-2552)
    • MWR Labs (Jon Butler and Nils) Chrome exploit
      • Windows kernel elevation of privilege to escape sandbox (CVE-2013-2553)
    • VUPEN's FireFox exploit
      • Windows LDRHotpatch ASLR/DEP bypass (CVE-2013-2554)
    • VUPEN's Adobe Flash exploit
      • IE9 broker issue used in the exploit for Adobe Flash (CVE-2013-2556)

    Status of security updates

    MS13-037 addresses the two Internet Explorer vulnerabilities used in the VUPEN exploit. The Windows vulnerabilities and the IE9 broker issue will be addressed in a future security update cycle. Here’s a chart that describes the state of fixes and level of exposure for these vulnerabilities provided to us by the ZDI.

      CVE-2013-2551 CVE-2013-2553 CVE-2013-2552 CVE-2013-2554 CVE-2013-2556
    IE10 Fixed


    Not Affected Fixed


    Not Affected Not Affected
    IE9 Fixed


    Not Affected Fixed


    Not Affected Update Pending
    Windows 8 Not affected Update Pending Not Affected Not Affected Not Affected
    Windows 7 Not affected Update Pending Not Affected Update Pending Not Affected

    As you can see, MS13-037 addresses the primary or initial code execution vulnerabilities but we still are working on the updates to address other vulnerabilities used as part of the exploit chains to win pwn2own. Thankfully, ZDI reported those vulnerabilities directly to us and we don’t have any reason to believe that ZDI or the researchers who discovered these vulnerabilities have disclosed the vulnerability details to any third party. So we typically treat the pwn2own vulnerabilities as any other vulnerability report received as part of the coordinated vulnerability discovery process. It’s super interesting for us as security researchers ourselves to see the ingenuity displayed during the contest to exploit the hardest targets out there (!!) but its the severity of the vulnerabilities (not necessarily their debut as part of the contest) that guides our prioritization of fixes.

    Each bulletin lists our “official” acknowledgement and thanks to the researchers and third parties involved in discovering and reporting these vulnerabilities to Microsoft. But today from everyone on the SRD team, we want to also pass along our thanks and a hat tip to the pwners out there – really impressive job on these vulns, guys. Thanks for helping us make the platform stronger.

    - Jonathan Ness, MSRC Engineering and William Peteroy, MSRC

  • Assessing risk for the May 2013 security updates

    Today we released ten security bulletins addressing 33 CVE’s. Two of the bulletins have a maximum severity rating of Critical, and eight 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 Exploit-ability Likely first 30 days impact Platform mitigations and key notes

    (Internet Explorer 8)

    Victim browses to a malicious webpage. Critical 1 CVE-2013-1347 currently being exploited in active attacks. Addresses the issue that was first discovered as an exploit on the US Department of Labor website. Includes the IE8 mshtml.dll from MS13-037 + one additional fix for CVE-2013-1347.

    Vulnerable code is also present in IE9 but not vulnerable in same way. Update for IE9 is included as defense-in-depth measure.


    (Internet Explorer)

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


    Attacker sends malicious HTTP request to victim IIS server, creating a resource exhaustion denial-of-service. Important 1 Likely to see reliable exploits developed for denial-of-service within next 30 days. Most likely target would be Windows Server 2012 web servers. Windows Server 2003, 2008, 2008 R2 not affected.


    Victim opens malicious .PUB file Important 1 Likely to see reliable exploits developed for denial-of-service within next 30 days. 11 CVE’s affecting primarily Publisher 2003. One affects Publisher 2007 and Publisher 2010. None affect Publisher 2013.

    (Kernel mode drivers, win32k.sys and dxgkrnl.sys)

    Attacker who is already running code on a machine uses one of these vulnerabilities to elevate from low-privileged account to SYSTEM. Important 1 Difficult to build reliable exploit code for this vulnerability.  

    (Word 2003)

    Victim opens malicious .doc file Important 2 Difficult to build reliable exploit code for this vulnerability. Does not affect Word 2007, Word 2010, Word 2013, Word Web Apps, or Office for Mac.


    Victim accepts an incoming Lync chat invitation and then agrees to view a shared program or shared content presented by the attacker. Important 2 Difficult to build reliable exploit code for this vulnerability. Cannot be exploited via regular Lync chat. Requires victim agreeing to view shared content.


    Victim opens malicious SVG image on system where Visio is installed. Through a sequence of events, Visio can be tricked into automatically sending the contents of a local file to a remote server. Important 3 No direct code execution. This is an information disclosure vulnerability only.  

    (Windows Writer)

    Victim clicks on a malicious wlw:// URL, opening Windows Writer (blogging software) and causing it to potentially overwrite local files writable by the logged-in user. Important 3 No direct code execution. After clicking on the prompt, user prompted to open Windows Writer. Vulnerability can only be triggered after user agrees to open Windows Writer.

    (.NET Framework)

    .NET Framework’s process to verify digital signature of XML can potentially be tricked into accepting unsigned XML as signed when first presented with signed XML. Important 3 No direct code execution. This is a spoofing threat.  

    - Jonathan Ness, MSRC Engineering

  • Microsoft "Fix it" available to mitigate Internet Explorer 8 vulnerability

    Today, we are making available a “Microsoft Fix it” solution to block attacks leveraging the Internet Explorer 8 (IE8) vulnerability described in Security Advisory 2847140. This code-signed, easily downloadable and install-able Fix it package uses the Windows application compatibility toolkit to make a small change at runtime to mshtml.dll every time IE is loaded. Here are the links to both apply and uninstall the Fix it solution: 

    Apply Fix itUninstall Fix it

    In this blog post, we’d like to describe the following:

    • More information about the progress toward a comprehensive security update
    • More information about workaround options to disrupt exploits leveraging this vulnerability
    • More information about how the Fix it solution works

    Comprehensive update in testing now

    We have built a comprehensive security update that addresses this vulnerability and it is currently being tested around-the-clock. We will release it as soon as testing confirms it is ready for broad release to all customers.  Tomorrow, please visit our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle.

    Workaround options

    As listed in Security Advisory 2847140 and confirmed externally, Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is a good workaround option for the in-the-wild attacks and public pentest framework that we have seen. The exploit version in the pentest framework that target Windows Vista and Windows 7 leverages a DLL module installed by Java 6 to bypass ASLR. EMET’s Mandatory ASLR feature blocks this exploit by enforcing ASLR randomization for this DLL when it gets loaded by IE8. At the moment, we are aware of a limited number of attacks in the wild and they target IE8 on Windows XP only. These exploits currently used by attackers are also blocked both by EMET’s EAF mitigation and by the EMET 3.5 TP and 4.0 Beta anti-ROP mitigations. The first ROP stage triggers EMET’s StackPointer, CallerCheck and SimExecFlow checks.  Enterprises already using EMET can anlyze their machine logs to investigate possible exploitation events for this exploit reported by EMET mitigations.

    For a stronger level of protection, we recommend installing the Fix it solution until the comprehensive security update is available. The Fix it applies changes to the mshtml loaded binary, similar to the changes applied by the IE team’s comprehensive security update.  More information about the vulnerability, and how it is blocked by the Fix it, can be found in the next section.

    How the Fix it “fixes” the vulnerable code

    The vulnerability is exposed due to a page layout issue, triggered when Internet Explorer 8 is trying to calculate layout information for nodes no longer in the DOM tree. The issue is caused by layout structures that are not properly cleaned up and contain dangling pointers to page elements. When the layout is updated, the browser crashes due to accessing the freed memory. The code that cleans up the dead links already exists, but it runs after the layout structures are accessed. The solution is to move the cleanup logic before the layout structure access.

    The appcompat shim-based “Fix it” protection tool does the exact same thing as the fix provided by the Internet Explorer team. This is still a workaround, but more surgical as compared to other workarounds because it blocks the root cause of the vulnerability. The shim modifies in memory the mshtml!CBlockContainerBlock::BuildBlockContainer function in order to force the code flow change that results in the layout structures being properly cleaned up before access:

          InjectLoopHere:            CODE XREF: CBlockContainerBlock::BuildBlockContainer+103
    match:74CC08DC 8B 45 08          mov     eax, [ebp+arg_0]     Inject code here!!
    match:74CC08DF 8B 40 08          mov     eax, [eax+8]
    patch:74CC08DC E9 ?? ?? ?? ??    jmp     WhilepNextExistingBlock2
    patch:74CC08E1 90                nop
    .text:74CC08E2 C1 E8 0A          shr     eax, 0Ah
    .text:74CC08E5 A8 01             test    al, 1
    .text:74CC08E7 0F 85 FB 8E FD FF jnz     loc_74C997E8
          WhilepNextExistingBlock:   CODE XREF: CBlockContainerBlock::BuildBlockContainer-6C6CE
    .text:74CC094E 39 7D F4          cmp     [ebp+pNextExistingBlock], edi 
    .text:74CC0951 0F 85 38 36 F9 FF jnz     LoopToRelocate
          LoopToRelocate:            CODE XREF: CBlockContainerBlock::BuildBlockContainer+2DF
    .text:74C53F8F FF 75 F4          push    [ebp+pNextExistingBlock]
    .text:74C53F92 8B 4D 0C          mov     ecx, [ebp+arg_4]
    .text:74C53F95 FF 75 08          push    [ebp+arg_0]
    .text:74C53F98 8D 55 F4          lea     edx, [ebp+pNextExistingBlock]
    .text:74C53F9B E8 2B 64 0A 00    call    CLayoutBlock::RemoveChild ; layout structure cleanup
    .text:74C53FA0 8B F0             mov     esi, eax
    .text:74C53FA2 3B F7             cmp     esi, edi
    match:74C53FA4 0F 8D A4 C9 06 00 jge     WhilepNextExistingBlock
    patch:74C53FA4 E9 ?? ?? ?? ??    jmp     CLOBBER_NOPS_PATCH_BYTES
    patch:74C53FA9 90                nop
    .text:74C53FAA E9 25 58 04 00    jmp     CHK_FAIL
    .text:74C53FAA                   END OF FUNCTION CHUNK CBlockContainerBlock::BuildBlockContainer
    patch:???????? 7D 07             jge     WhilepNextExistingBlock3
    patch:???????? E9 ?? ?? ?? ??    jmp     CHK_FAIL
    patch:???????? 33 FF             xor     edi, edi
    patch:???????? 39 7D F4          cmp     [ebp+pNextExistingBlock], edi  
    patch:???????? 0F 85 ?? ?? ?? ?? jnz     LoopToRelocate
    patch:???????? 8B 45 08          mov     eax, [ebp+arg_0]  
    patch:???????? 8B 40 08          mov     eax, [eax+8]
    patch:???????? E9 ?? ?? ?? ??    jmp     ResumeExecution

    The “Fix it” solution will apply only for the x86 versions of Internet Explorer 8 that have applied MS13-028: Cumulative Security Update for Internet Explorer: April 9, 2013. Applying this workaround will not interfere with the installation of the final security update that will address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, after you apply the yet-to-be-released final security update, you should uninstall the Fix it workaround as it will no longer be needed.


    We want to reiterate that only IE8 is vulnerable to this issue and we currently see only limited attacks. We are hard at work developing a comprehensive security update. Tomorrow, please review our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle. In the meantime, feel free to reach out to us with any questions on the above. You can contact us at or

    Special thanks to Elia Florio for his work analyzing exploits for this vulnerability.

    - Cristian Craioveanu and Jonathan Ness, MSRC Engineering

  • EMET 4.0's Certificate Trust Feature

    Three weeks ago, we released a beta version of EMET 4.0 to get feedback on the new EMET features and to get more real-world testing before the official release. We have been amazed and so grateful for the thousands of downloads and hundreds of emails with feature suggestions, bug reports, questions about the new features, and kind words cheering us on. Thank you (!!) to those of you who are helping us make EMET 4.0 a great release. Seeing how much the community of defenders cares about this product drives and motivates us to make it awesome! With this blog post, we want to give you an update on the EMET schedule and walk through the steps to leverage EMET 4.0’s new Certificate Trust feature.

    Official release delayed two weeks to May 28, 2013

    We have acted on and addressed a number of bug reports and points of feedback already. One of the most important was a vulnerability first reported by TK of NSFocus where having EMET loaded made exploitation of system vulnerabilities easier – that is fixed. We also received the “Agent not running” bug report several times and that is addressed for the final release of EMET 4.0. We are fixing several application compatibility issues reported that we otherwise would be unlikely to have discovered on our own pre-release. Your feedback is making EMET 4.0 a better product – thank you!

    We want to make product changes to address more of the feedback before we release EMET 4.0 to the world. So we decided to postpone the release of final version of EMET 4.0 by two weeks, to May 28th, 2013. We are sorry if this decision may interfere with your future plans of deploying EMET, but we prefer to take some extra time to work on all the feedback received and to release a product as reliable and safe as possible.

    EMET and certificate pinning

    As you may know EMET 4.0 implements a new protection feature known also as “certificate pinning” which in its simplest form could be described as a method of associating an X509 certificate (and its public key) to a specific Certification Authority (root or leaf).

    Certificate pinning and certificate cross-validation became two very popular topic in recent years because of the major incidents and fault happened in the PKI space; in fact the current PKI and Certification Authorities model has demonstrated some limits and shown critical issues when scaled to a globalized and fully interconnected world where it’s not entirely safe to assume that every CA in the world is immune from breach, errors or poor practices as clearly showed by the table below which summarizes the most significant PKI issues seen so far. On the other hand the reason why users should care about certificate pinning is the fact that the numbers of CA across the world and located in multiple countries has grown significantly in recent years and the entire PKI model works with the assumption that all these CA will always operate with the same level of trust and confidence.

    Mar 2011 KB2524375 nine fraudulent digital certificates issued by Comodo
    Aug 2011 KB2607712 […] at least one fraudulent digital certificate issued by DigiNotar
    Nov 2011 KB2641690 DigiCert Sdn. Bhd, a Malaysian subordinate certification authority (CA) […] has issued 22 certificates with weak 512 bit keys
    Jan 2013 KB2798897 one fraudulent digital certificate issued by TURKTRUST Inc.

    For this reason EMET 4.0 decided to take a little step far from the traditional exploit mitigation area and introduces a new feature called Certificate Trust to allow anyone to create pinning rules for any SSL/TLS website certificate, giving the ability to detect Man-In-The-Middle attacks leveraging untrusted certificates. EMET 4.0 comes with Certificate Trust enabled by default, including a set of pre-configured websites for the most common domains used by Microsoft online services; nevertheless, since we believe that certificate pinning is a useful tool to detect MITM attacks targeting any domain and not just Microsoft services, we designed Certificate Trust totally configurable, in order to allow any user to configure custom pinning rules that will be enforced when browsing the web with Internet Explorer.

    Since we received a lot of feedback about this new feature and a lot of users sent inquiries on how to properly use it, we are publishing this blog to explain how to configure and test Certificate Trust.

    Introducing the Certificate Trust feature

    EMET 4.0 has a main switch button in the system mitigation panel that can be used to activate or de-activate Certificate Trust. Once enabled, users have to specify which certificates and Root Certificate Authorities to trust. Users can verify that the Certificate Trust feature is activated from the EMET GUI by checking that the system status of this mitigation is “Enabled” and that Internet Explorer process (iexplore.exe) is in the list of configured apps (with or without memory mitigations enabled). This configuration allows EMET to inject into the protected process a new small module (EMET_CE.DLL) that will operate only within Internet Explorer to enforce the certificate pinning protection.

    EMET pinning model is based on two simple types of metadata: Pinning Rules and Protected Websites. Users can define custom “pin” relationships between subject name(s) seen in SSL certificates and a set of trusted Root Certification Authorities. EMET supports the creation of “one-to-one” pinning rules (one domain pinned to one specific RootCA) or “one-to-many” (one domain pinned to a set of specific RootCAs), and gives the ability to define minor exceptions for each rule.

    For example, let’s consider the domain “”, which is configured and protected by default by EMET 4.0 Beta. EMET has a specific pin rule for the subject name of “” which is linked to two RootCAs. One of these RootCAs is VeriSign RootCA, which is visible when manually inspecting the certificate for that domain. Any certificate seen by Internet Explorer for “” and originated from a RootCA different than the two configured in EMET will be detected and reported as suspicious.

    Configuring Certificate Trust: an example

    In order to understand the exact steps required to create a custom pinning rule, we are providing a step-by-step configuration guide for Twitter. This guide can be used as reference to configure any other online service (e.g. webmail, social networks, file sharing, online banking, etc.) or any corporate portal that uses SSL/TLS connections (e.g.,, etc.), and take advantage of EMET’s Certificate Trust feature.

    • From a clean computer using a trusted internet connection download and inspect the SSL/TLS certificate for the domain that has to be protected with EMET (e.g. and find the correct subject name that will be used in the “Protected Websites” tab (e.g. “”)

    • Lookup the RootCA for “” in the “Certification Path” and make note of some significant details related to this RootCA certificate (name, thumbprint, validity, serial number, etc.). For example the current RootCA of “” has a VeriSign certificate with the following details:
      • CN = VeriSign Class 3 Public Primary Certification Authority - G5
      • Thumbprint = 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5
      • Validity = From: November ‎7, ‎2006; To: ‎July ‎16, ‎2036

    • Open EMET_GUI and click on “Configure”->”Certificate Trust”. In the “Pinning Rules” tab add a new rule (e.g. TwitterCAs) which will be used to import the specific VeriSign RootCA acquired earlier for (double check you’re importing the correct VeriSign CA). This pinning rule will be used to create a “one-to-one” pinning, but anytime it is possible to add more RootCA certificates into this rule to create “one-to-many” pinning.

    • Go to the “Protected Websites” tab and add a pin that links “” to the just created rule “TwitterCAs”.

    • Click “OK” to save the settings and restart the browser if needed.

    The Certificate Trust configuration can be exported as XML file and later imported on a different machine or distributed to a corporate environment to be imported using the EMET_conf command line utility. For the Twitter example used in this blog, the exported XML configuration file is shown below:

    <EMET Version="4.0.4854.22469">
                <Issuer>CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US</Issuer>
            <Expiration>5/10/2014 4:00:00 PM</Expiration>

    Notes about Certificate Trust configuration

    After evaluating the initial feedback received and some questions from users regarding the Certificate Trust feature, we think it’s also important to share some additional notes and guidelines for users dealing for the first time with certificates and pinning rules:

    • Some websites may use different portal as entry-point for authentication; it’s always good to carefully check the correct domain name to add into the “Protected Websites” tab (e.g. “” service is accessed via the “” authentication service);
    • Each pinning rule has an expiration date that delimits for how long a rule is effective; after the specified date, the rule will no longer be used to check certificates; expiration date can be usually aligned with the expiration date of the certificate included in a pinning configuration;
    • Domains cannot be added in the “Protected Websites” tab by using wildcard characters (e.g. * is not allowed); also, the domain name added into this tab is not the domain name in the URL bar of the browser, but it’s one subject name of the SSL certificate;
    • To avoid false positives and to configure less restrictive rules, it is possible to add exceptions on each pinning rule based on three properties of the RootCA certificate: key size, country, and signature hashing algorithm; when a RootCA is not present in the defined trusted set for a specific domain, EMET may allow an exception of the pinning rule if explicitly configured (for example: allows an exception if the RootCA certificate does not use MD5, has a minimum key size of 4096 bits, and is located in USA);
    • When EMET detects a suspicious certificate it will be reported with a visible message from EMET Agent, while the important details of the certificates are logged into the Window Events Log; a warning message is a good pointer to examine carefully what’s happening for a SSL/TLS certificate but doesn’t necessary mean that the detected certificate is malicious, few times changes of RootCAs happen also for legitimate reasons;
    • The quickest way to test that the Certificate Trust feature is working is to configure a wrong pinning rule that will fail for a test domain; for example, if for we configure a different RootCA than the specific VeriSign CA identified earlier, EMET will display the following warning message when browsing with Internet Explorer on “”:


    We hope you are as excited about using the final release of EMET 4.0 as we are about releasing it. If you have any questions about EMET 4.0, specifically about the Certificate Trust feature detailed in this blog post, please email us at And if you haven’t yet tested EMET 4.0 beta, download it here and try it out!

    - Elia Florio, MSRC Engineering