Over the past couple of days we’ve received some additional questions regarding the ASP.NET vulnerability. In this post we will answer some of the most common ones.

Is My ASP.NET Site Affected By This Issue?

Yes, all sites that use ASP.NET are affected by this vulnerability. You should follow the recommendations outlined in the advisory. The advisory includes a workaround that can help harden a server against attack. In our previous blog post we provided a script that can help you identify ASP.NET sites that could benefit from this hardening.

Has My Site Been Attacked?

The publicly disclosed exploit would cause the web server to generate thousands (or tens of thousands) of HTTP 500 and 404 error responses to requests from a malicious client. You can use stateful filters in your firewall or intrusion detection systems on your network to detect such patterns and block potential attackers. The Dynamic IP Restrictions module supported by IIS 7 can also be used to block these types of attacks.

Additionally, if your site has been attacked, you should see warnings in the application event log similar to:

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/11/1111 11:11:11 AM
Event time (UTC): 11/11/1111 11:11:11 AM
Event ID: 28e71767f3484d1faa90026f0947e945
Event sequence: 133482
Event occurrence: 44273
Event detail code: 0

Application information:
Application domain: c1db5830-1-129291000036654651
Trust level: Full
Application Virtual Path: /
Application Path: C:\foo\TargetWebApplication\
Machine name: FOO

Process information:
Process ID: 3784
Process name: WebDev.WebServer40.exe
Account name: foo

Exception information:
Exception type: CryptographicException
Exception message: Padding is invalid and cannot be removed.

The highlighted exception detail is the most important piece of information in the event log entry to look for. It is possible to hit this error while developing new ASP.NET website code, and it can happen in certain production environments. However, if it did not appear on your production servers until recently, it is possible that it indicates an attack. Verifying that the time of these exceptions corresponds to the large number of requests described above would increase the confidence that this entry was caused by an attack.

-Kevin Brown, MSRC Engineering

Our recent advisory describes an ASP.NET vulnerability which was recently publicly disclosed. This blog post will give you more information about the vulnerability and the workaround. It will also provide a script which will help you detect ASP.NET applications on your server that are in a vulnerable configuration.

The Impact of the Vulnerability

ASP.Net uses encryption to hide sensitive data and protect it from tampering by the client. However, a vulnerability in the ASP.Net encryption implementation can allow an attacker to decrypt and tamper with this data.

But what can the attacker do with this capability? Part of the answer depends on the ASP.Net application being attacked. For example, if the ASP.Net application stores sensitive information, such as passwords or database connection strings, in the ViewState object this data could be compromised. The ViewState object is encrypted and sent to the client in a hidden form variable, so it is a possible target of this attack.

If the ASP.Net application is using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application. The public disclosure demonstrated using this technique to retrieve the contents of web.config. Any file in the ASP.Net application which the worker process has access to will be returned to the attacker.

How the Vulnerability Works

To understand how this vulnerability works, you need to know about cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. In this case, there is a vulnerability in ASP.Net which acts as a padding oracle. This allows an attacker to send chosen cipher text to the server and learn if it was decrypted properly by examining which error code was returned by the server.

By making many requests the attacker can learn enough to successfully decrypt the rest of the cipher text. The attacker can then alter the plain text and re-encrypt it as well.

The Workaround - Silencing the Oracle

The workaround for this vulnerability is to use the customErrors feature of ASP.NET to configure applications to return the same error page regardless of the error encountered on the server.

By following the steps in the advisory to map all error messages to a single error page, you make it difficult for the attacker to distinguish between the different types of errors, effectively limiting access to the oracle.

How to Detect Vulnerable ASP.Net Applications

Some ASP.Net applications may already be configured to return the same error page for all server errors. To detect ASP.Net applications that are not configured this way and need to have the workaround applied to them, use the following script:

Note: After installing the MS10-070 security update, the workaround is no longer necessary and there is no need to run this script.

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'  DetectCustomErrorsDisabled.vbs Script
'  Version 3.1
'  
'  This script will help detect vulnerable configuration for the Padding Oracle 
'  ASP.Net vulnerability documented in MS advisory 2416728.
'  
'  http://www.microsoft.com/technet/security/advisory/2416728.mspx
'  
'  Usage: 
'      cscript DetectCustomErrorsDisabled.vbs [RemoteServerName] 
'
'  NOTE: THIS SCRIPT USES THE FILESYSTEM AND SHELL OBJECT AND SHOULD BE
'       RUN AS AN ADMINISTRATOR
'
'  The script works by enumerating all web.config and assessing if the 
'  side-channel leak for the padding oracle vulnerability is mitigated by the 
'  use of homogenizing custom error responses from ASP.Net applications. 
'  
'  Note: On IIS 7 servers, this script requires IIS6 compatibility mode to be
'  installed.
'  
'  More information on: http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx
'  
'  Version History:
'  1.0 - Initial version
'  2.0 - Added additional checks for app/site root config
'  3.0 - Added error validation for XML parsing and path checks
'  3.1 - Added check for missing root web.config
' 
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
OPTION EXPLICIT
ON ERROR RESUME NEXT
DIM strServer
DIM objWebService, objWebServer, objDir, objFileSys
DIM physicalPath, dir, xmlDoc, nodeList, node, ret
DIM configFile, configFilePath, configLine
DIM childNodes, ErrPage500, ErrPage404, errFound
DIM index, errCount

strServer = "localhost"


' Parse command line input
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
IF WScript.Arguments.Length=1 THEN
    strServer = WScript.Arguments( 0 )
END IF

IF WScript.Arguments.Length>1 THEN
    WScript.Echo "Illegal number of arguments"
    WScript.Echo "Usage: cscript.exe DetectCustomErrorsDisabled.vbs [RemoteServerName]"
    WScript.Quit( 1 )
END IF

' Initializations
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SET objFileSys = CreateObject("Scripting.FileSystemObject")
SET objWebService = GetObject( "IIS://" & strServer & "/W3SVC" )
IF Err <> 0 THEN
    WScript.Echo "Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compatibility installed."
    WScript.Quit (1)
END IF
SET xmlDoc = CreateObject("Microsoft.XMLDOM")

IF IsNull(objFileSys) THEN
    WScript.Echo "Failed to create FileSystemObject. Please run script as Admin."
    WScript.Quit (1)
END IF

IF IsNull(objWebService) THEN
    WScript.Echo "Failed to connect to IIS ADSI provider. Make sure you have IIS6 "_
    + "management compatibility role service installed."
    WScript.Quit (1)
END IF

WScript.Echo("Enumerating possible paths with ASP.Net configuration that have" _
    +" custom errors turned off.")    
WScript.Echo ("")    


' Search web server for unsafe configuration
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
FindASPNetConfig(objWebService)


' Search all paths on web server for possible web.config  files.
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SUB FindASPNetConfig(WebService)

    FOR EACH objWebServer IN WebService
        IF objWebserver.Class = "IIsWebServer" THEN
            EnumDirectories(objWebServer)
        END IF
    NEXT
    
END SUB

' Recursively go through vdirs and webdirs
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SUB EnumDirectories(objDir)
    
    DIM objSubDir
    ' The first call to this is from IIsWebServer, so we can skip that
    FOR EACH objSubDir IN objDir
        IF (objSubDir.Class = "IIsWebVirtualDir") THEN
            GetPhysicalPaths(objSubDir)            
            EnumDirectories(objSubDir)          
        END IF
    NEXT	
    
END SUB


' Get physical paths for web and virtual directories
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SUB GetPhysicalPaths(objDir)
    
    physicalPath = objDir.Path
    CALL EnumWebConfig(physicalPath,1)

END SUB


' Recursively search for web.config files.
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SUB EnumWebConfig(Path,IsRoot)

    IF NOT objFileSys.FolderExists(Path) THEN 
        IF IsRoot THEN
            ' WScript.Echo Path & ": Site's disk path is incorrect and root web.config does not exist"
            WScript.Echo Path & ": ** Vulnerable configuration found **"
        END IF
        EXIT SUB
    END IF

    configFilePath = Path & "\web.config"
    IF objFileSys.FileExists(configFilePath) THEN 
        CALL ProcessWebConfig(configFilePath,IsRoot)
    ELSEIF IsRoot = 1 THEN
        ' WScript.Echo Path & ": Site or app root web.config does not exist"
         WScript.Echo Path & ": ** Vulnerable configuration found **"
    END IF
    
    FOR EACH dir IN objFileSys.GetFolder(Path).SubFolders
        CALL EnumWebConfig(dir.Path,0)
    NEXT

END SUB

' Skip known identities that will have Write access by default
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SUB ProcessWebConfig(Path,IsRoot)
    xmlDoc.async="false"
    xmlDoc.load(Path)
    errFound = 0
    SET nodeList = xmlDoc.getElementsByTagName("customErrors")

    IF IsRoot = 1 AND nodeList.length = 0 THEN
        ' Root web.config does not set defaultRedirect, so this config should 
        ' have a customErrors section present with customErrors turned on and a 
        ' defaultRedirect present. Else this is a vulnerable configuration.
	
        ' WScript.Echo path & ": Root web.config must have customErrors with defaultRedirect defined"

        errFound = errFound + 1

    ELSEIF IsRoot = 1 THEN
        ret = CheckRootCustomErrorsSection(nodeList, Path)
        errFound = errFound + ret
    END IF

    DIM count

    FOR count=0 TO nodeList.length-1
        ret = CheckCustomErrorsDisabled(nodeList.Item(count), Path)
	    errFound = errFound + ret
        ret = CheckCustomErrorsAreHomogenous(nodeList.Item(count), Path)
	    errFound = errFound + ret
    NEXT
            
    IF errFound > 0 THEN
        WScript.Echo Path & ": ** Vulnerable configuration found **"
    ELSE
        WScript.Echo Path & ": ok"
    END IF
END SUB


FUNCTION CheckRootCustomErrorsSection(xmlnodelist, path)

    errCount = 0
    FOR index=0 TO xmlnodeList.length-1
        ret = CheckRootCustomErrorsDisabled(nodeList.Item(index), Path)
	    errCount = errCount + ret
    NEXT

    CheckRootCustomErrorsSection = errCount
END FUNCTION


FUNCTION CheckRootCustomErrorsDisabled(xmlnode, path)
    
    IF StrComp (LCase(xmlnode.getAttribute("mode")), "off") = 0 THEN
        ' WScript.Echo path & ": Custom Error disabled: " & xmlnode.xml
        CheckRootCustomErrorsDisabled = 1
        EXIT FUNCTION
    ELSEIF IsNull(xmlnode.getAttribute("defaultRedirect")) THEN
        ' WScript.Echo path & ": defaultRedirect not set: " & xmlnode.xml
        CheckRootCustomErrorsDisabled = 1
        EXIT FUNCTION
    ELSE
        CheckRootCustomErrorsDisabled = 0
    END IF
    
END FUNCTION


FUNCTION CheckCustomErrorsDisabled(xmlnode, path)
    IF StrComp (LCase(xmlnode.getAttribute("mode")), "off") = 0 THEN
        ' Unsafe config
        ' WScript.Echo path & ": Custom Error disabled: " & xmlnode.xml
        CheckCustomErrorsDisabled = 1
    ELSE
        CheckCustomErrorsDisabled = 0
    END IF
    
END FUNCTION

FUNCTION CheckCustomErrorsAreHomogenous(xmlnode, path)
    IF xmlnode.childNodes.length=0 AND len(xmlNode.getAttribute("defaultRedirect"))>0 THEN
	    CheckCustomErrorsAreHomogenous = 0
        EXIT FUNCTION
    END IF

    SET childNodes = xmlnode.childNodes

    ErrPage404 = ""
    ErrPage500 = ""

    DIM count
    FOR count=0 TO childNodes.length-1
        CALL GetErrorPage(childNodes.Item(count))
    NEXT

    IF StrComp(ErrPage404,"") = 0 AND StrComp(ErrPage500,"") = 0 AND IsNull(xmlNode.getAttribute("defaultRedirect")) THEN
        ' Missing defaultRedirect in this case will cause config to be vulnerable
        'WScript.Echo path & ": missing defaulRedirect URL: " & xmlnode.xml
        CheckCustomErrorsAreHomogenous = 1
        EXIT FUNCTION
    ELSEIF StrComp(ErrPage404,"") = 0 AND StrComp(ErrPage500,"") <> 0 AND StrComp(ErrPage500, xmlNode.getAttribute("defaultRedirect")) <> 0 THEN
        'WScript.Echo path & ": 500 and default error pages differ: " & xmlnode.xml
        CheckCustomErrorsAreHomogenous = 1
        EXIT FUNCTION
    ELSEIF StrComp(ErrPage500,"") = 0 AND StrComp(ErrPage404,"") <> 0 AND StrComp(ErrPage404, xmlNode.getAttribute("defaultRedirect")) <> 0 THEN
        'WScript.Echo path & ": 404 and default error pages differ: " & xmlnode.xml
        CheckCustomErrorsAreHomogenous = 1
        EXIT FUNCTION
    ELSEIF StrComp(ErrPage404, ErrPage500) <> 0 THEN
        'WScript.Echo path & ": 404 and 500 error pages differ: " & xmlnode.xml
        CheckCustomErrorsAreHomogenous = 1
        EXIT FUNCTION
    ELSE 
        CheckCustomErrorsAreHomogenous = 0 
    END IF

END FUNCTION

SUB GetErrorPage(xmlnode)
    IF xmlnode.nodeType <> 1 THEN
        EXIT SUB
    ELSEIF IsNull(xmlnode.getAttribute("statusCode")) THEN
        'Do nothing.
    ELSEIF StrComp(xmlnode.getAttribute("statusCode"), "500") = 0 THEN
        ErrPage500 = xmlnode.getAttribute("redirect")
    ELSEIF StrComp(xmlnode.getAttribute("statusCode"), "404") = 0 THEN
        ErrPage404 = xmlnode.getAttribute("redirect")
    END IF

END SUB

Acknowledgements

Many thanks to Levi Broderick, Nazim Lala, and Stefan Schackow for their contributions to this post.

-Kevin Brown, MSRC Engineering

Updated September 18, 2010

Made several improvements to the included script to catch additional corner cases and provide additional error handling. Clarified that an attacker can only retrieve files from within the ASP.Net application.

Updated September 21, 2010

Updated the script to add a check for missing root web.config files, and attached a zip of the script to the post so it can be downloaded directly.

Updated September 29, 2010

Added a note clarifying that the workaround and the detection script are no longer necessary once the security update has been installed. The security update is now available - please see MS10-070 for more information.

Today we released nine security bulletins. Four have a maximum severity rating of Critical with the other five having a maximum severity rating of Important. Furthermore, six of the nine bulletins either do not affect the latest version of our products or affect them with reduced severity. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

Thanks to the whole MSRC Engineering for their work on this month’s cases.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

This morning we released security bulletin MS10-061 to address an issue in the Windows print spooler. In this blog post, we’d like to provide additional detail about the specific configurations of Windows that are vulnerable to this issue and more background on its connection to the Stuxnet malware.

Vulnerable configurations

Depending on the configuration, the vulnerability allows a local or remote user to write arbitrary files to %SYSTEM%. This is happens because the spooler does not properly impersonate the user under certain conditions. Fortunately, only a subset of Windows machines are remotely vulnerable, as demonstrated in the chart below.

The list of these older printers can be found in KB 2347290.

Password-based sharing is enabled by default on Windows 7, Vista, Windows Server 2008 R2 and Windows Server 2008 and later platforms, making the default scenario not vulnerable on those platforms. The “Users” group is also not a member of the local “Guests” group by default on these platforms.

A local user can also exploit this vulnerability to gain SYSTEM privilege. In order to do this, the user would need to be able to add a printer; on Vista+, normal users can add printers by default.

In the wild?

This particular vulnerability is one of several used by the Stuxnet malware to escalate privilege and/or propagate across the network. When Stuxnet starts up, it enumerates all printer shares on the network and tries to connect to them using the “Guest” account; if it is successful, it will call various APIs to copy itself to the remote systems and execute it.

- Mark Wodrich and Bruce Dang, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

This month, Microsoft released an update for IIS that addresses three vulnerabilities. The blog post focuses on one of these: the Request Header Buffer Overflow Vulnerability (CVE-2010-2730), which affects IIS version 7.5 and has a maximum security impact of Remote Code Execution (RCE). Below we provide more details on the vulnerability and the potential for reliable remote code execution, to assist with assessing risk and prioritizing deployment of the update. We also aim to allay fears of malware utilizing this vulnerability to spread across networks.

Vulnerability details

CVE-2010-2730 affects Windows servers running IIS with a non-default configuration. If the FastCGI handler is enabled (e.g. to support 3rd-party server-side scripting languages), the system could be vulnerable to a heap buffer overrun when handling HTTP request headers.

A successful exploit would allow a remote attacker to execute code in the context of the IIS worker process.

For more details, refer to Security Bulletin MS10-065.

Exploitability details

While a successful exploit leading to RCE is possible in theory, there are some technical factors that make it less likely. In practice it is more likely that attacks will lead to a crash of the IIS worker process and a denial-of-service (DoS) condition when the service reaches its restart limit. Let’s look into the factors that hamper exploitation:

The vulnerable code processes HTTP request headers from the client - these are under the attacker’s full control. An initial buffer is allocated on the heap and used to store the request header names and values, and is re-sized as needed, until all the client’s headers have been processed.

At this point, no buffer overrun has occurred. The code then proceeds to copy pre-defined parameters to the buffer, assuming that enough space has been reserved by the earlier code. In some cases this will lead to a buffer overrun. The data written to the buffer is of the following format:

Name : string pointer
NameLen : integer
Value : string pointer
ValueLen : integer

At the point the buffer overrun occurs, only the Name and NameLen fields are populated (non-zero) – the code will retrieve values for each of these parameters once they have been appended to the buffer.

The important thing to note is that none of the data that is written beyond the end of the buffer is under the attacker’s control. The Name fields will point to string data in the IIS worker process. The pointer values will be unpredictable due to ASLR. The NameLen fields will be predictable low-value integers, but will not be of much use to an attacker.

Once the values for these parameters have been filled in, the Value field will point to string data and ValueLen will also be a low-value integer. (The contents of the strings may be attacker-controlled).

Conclusion

In order to obtain a reliable RCE exploit, the attacker would need to be able to predict or control the values outlined above, and also control the layout of the heap buffers to some extent. Due to the lack of control or predictability of the data written beyond the end of the buffer, this vulnerability will be tricky to impossible to exploit reliably.

For this reason, attempts to exploit this vulnerability are more likely to result in a DoS than RCE.

I would like to thank Nazim Lala, Bruce Dang and Charles Weidner for their work on this issue.

- Mark Wodrich, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Background on the exploit

As you probably know there is a new exploit in the wild for Adobe Reader and Acrobat. This particular exploit is using the Return Oriented Programming (ROP) exploit technique in order to bypass Data Execution Prevention (DEP).

Normally Address Space Layout Randomization (ASLR) would help prevent successful exploitation.  However, this product ships with a DLL (icucnv36.dll) that doesn’t have ASLR turned on.  Without ASLR, this DLL is always going to be loaded at a predictable address and can be leverage by an exploit.  In the below screenshot we use Process Explorer to show what this looks like.

Find more information on the importance of enabling ASLR in your products at http://msdn.microsoft.com/en-us/library/bb430720.aspx.

How EMET 2.0 blocks the exploit

The good news is that if you have the Enhanced Mitigation Experience Toolkit 2.0 (EMET) enabled for AcroRd32.exe, it blocks this exploit.  This is happens thanks to two different mitigations:

Mandatory ASLR: On Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008 this mitigation will force the relocation of non ASLR-aware DLLs. The exploit will then fail to use ROP successfully since it is expecting the DLL to be at a predictable location.  Take a look at the below screenshot from Process Explorer to see what this looks like.

Export Address Table Access Filtering (EAF): The exploit is also blocked by the EAF mitigation.  This is important for Windows XP and Windows Server 2003 because they do not support mandatory ASLR. With this mitigation in place EMET will detect the shellcode accessing the EAT of Kernel32.dll trying to resolve some APIs (e.g. LoadLibraryA). EMET will then raise a STATUS_STACK_BUFFER_OVERRUN unhandled exception and the program will be terminated before the shellcode does anything bad.

How to enable EMET for Adobe Reader

In order to enable EMET for Adobe Reader and Acrobat you have to install EMET and run the following simple command line as an Administrator. Please note the path to the Adobe Reader and Acrobat could be different in your system (especially if you are not using a 64 bit system).

C:\Program Files (x86)\EMET>emet_conf.exe --add "c:\program files (x86)\Adobe\Reader 9.0\Reader\acrord32.exe"

The changes you have made may require restarting one or more applications

We have been working closely with the Adobe Secure Software Engineering Team (ASSET) on recommending EMET as a mitigation option. Due to the time-sensitive nature of this issue, we have only been able to perform a cursory look at the functional compatibility of this mitigation. Keep in mind, Adobe Reader and Acrobat support broad feature sets, which require extensive testing to fully cover all functionality. Therefore, we recommend that you also test the mitigation in your environment to minimize any impact on your workflows.  Please refer to Adobe's guidance regarding EMET under the Mitigations section of their Security Advisory.

New updates to EMET 2.0

Also, last week we made available version 2.0 of EMET on this blog post. We would like to thank all the people that gave it a try it and sent us feedback. Today we are releasing an updated version of EMET (2.0.0.1) with some bug fixes.  The download for the old version has been replaced with the new version and can be obtained here.

The following are the changes you can find in the new version:

• The DEP mitigation is now enabled with the ATL thunk emulation for better compatibility.
• The GUI does a better job of handling situations where a process tries to block it from determining if DEP enabled or disabled for that process. Previously, the GUI crashed in certain scenarios with programs such as Antivirus and Intrusion Prevention Systems.
• EMET now correctly protects applications launched with 8.3 filenames.
• Enhancements have been made to EMET running on Windows XP to support more 3^rd party applications. Previously, there where situations where the protections could fail to protect certain applications.

As always, we welcome your feedback and would like to hear more about your experiences with EMET.  Please feel free to e-mail us at switech@microsoft.com

- Fermin J. Serna and Andrew Roths

Updated September 14, 2010 - In certain Windows XP configurations, users have encountered problems where several applications configured for use with EMET do not get protected by EMET.  When this happens you will see that the process does not have a check mark under the "Running EMET" column of the main application.  If you have encountered this issue, please download the latest version of the tool which addresses this problem.

Today we are pleased to announce the availability of the Enhanced Mitigation Experience Toolkit (EMET) version 2.0.  Users can click here to download the tool free of charge. 

For those who may be unfamiliar with the tool, EMET provides users with the ability to deploy security mitigation technologies to arbitrary applications.  This helps prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited.  By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products.  In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor.

Below is a screenshot of the tool, which features a brand new interface as part of this release.

The installation package for EMET v2.0 includes a detailed user guide.  A copy can also be found at the bottom of this post.  It gives an overview of the tool, instructions on how to use it, answers to frequently asked questions, and caveats about the mitigations that users should be aware of.  Please be sure to read the guide before using the tool.

Additionally, the BlueHat team has helped us put together a training video on EMET v2.0.  The video gives an even more in-depth look at some of the security mitigations offered by the tool.  You can watch the video online here.

To get more information on how this FREE tool can help you take advantage of the protections it offers please refer to our previous blog post announcing the upcoming release.  That post also gives a rundown of all the changes that are new with the 2.0 version.

As always, we welcome your feedback and would like to hear more about your experiences with EMET.  Please feel free to e-mail us at switech@microsoft.com

- Andrew Roths and Fermin J. Serna