Security Research & Defense

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

May, 2014

  • MS14-025: An Update for Group Policy Preferences

    Today, we released an update to address a vulnerability in Group Policy Preferences (MS14-025). Group Policy Preferences was an addition made to Group Policy to extend its capabilities. Among other things, Group Policy Preferences allows an administrator to configure:

    • Local administrator accounts (name of the account, account password, etc)
    • Configure a service or scheduled task (allowed to specify alternate credentials to run as)
    • Mount network drives when a user logs in (allowed to specify alternate credentials to connect with)

    Group Policy Preferences are distributed just like normal group policy: An XML file containing the settings is written to the SYSVOL share of the domain controllers, and computers periodically query the SYSVOL share (authenticating to it using their computer account) for updates to the group policy.

    Several of the Group Policy Preferences allow credentials to be specified. When this option is used, the password is symmetrically encrypted using a static key and written to the XML file along with the rest of the settings. What is this key you ask? It turns out, we document it on MSDN:

    If an attacker is able to get access to the SYSVOL share (which is open to all authenticated users, so a malicious or spear phished employee will have access to it) and obtain the AES encryption key used to encrypt/decrypt passwords set with GPP (which we document on MSDN), the attacker will be able to obtain the credentials set with GPP.

    Microsoft has observed that Group Policy Preferences abuse is one of the most common tactics used by attackers to elevate permissions in a domain. Multiple toolkits used by attackers such as Metasploit ( and PowerSploit ( provide easy to use methods for retrieving and decrypting GPP passwords. In the worst case scenario, companies use Domain Administrator credentials in their Group Policy Preference accounts, resulting in a full domain compromise as soon as the attacker is able to access with SYSVOL share (and decrypt the passwords using the documented key).

    Microsoft has released an update to change the behavior for this issue, but companies using GPP need to take action. Microsoft has removed the ability to create or modify any Group Policy which contains a Group Policy Preference that specifies account credentials. The only action that can be performed on such a Group Policy is “delete”. Note that Microsoft is not automatically disabling these Group Policies because we do not want to disrupt existing environments which rely on this feature. You can see in the picture below that when attempting to create a local account the “username” and “password” fields are disabled. If you attempt to create a user, an error dialog will be displayed.

    In addition to the change in behavior, Microsoft is providing customers with two PowerShell scripts. The first script, Enum-SettingsWithCpassword, will search existing GPO’s for use of the account password functionality. We urge companies to immediately run this script and delete vulnerable GPO’s detected.

    The second script, Invoke-PasswordRoll, can be used to set local administrator passwords on remote systems (something that Group Policy Preferences is commonly used for). The script takes a list of usernames and computers, and uses PowerShell remoting to connect to each computer and change each specified usernames password to a randomized password. The username/password combinations will be written recorded in a file on disk (which is encrypted, but optionally can be stored in clear-text). Note that the script enforces randomized passwords to ensure the local accounts cannot be used in pass-the-hash attacks.

    You can find both scripts at

    - Joe Bialek, MSRC engineering team

  • Load Library Safely

    Dynamically loading libraries in an application can lead to vulnerabilities if not secured properly. In this blog post we talk about loading a library using LoadLibraryEx() API and make use of options to make it safe.

    Know the defaults:

    • The library file name passed to LoadLibrary() / LoadLibraryEx() call need not contain an extension. If one is not specified, then the default library file extension, .DLL, is used. As a result of this feature, if a null is passed as library name it tries to load ".DLL" which could be exploited by placing a ".DLL" in the path searched.
    • The library file name passed to LoadLibrary() / LoadLibraryEx() call need not specify a directory path. If one is specified, library is loaded only from the specified path. Otherwise, following default DLL search order is used:
    1. The current process image file directory, application directory.
    2. The system directory.
    3. The 16 bit system directory.
    4. The windows directory.
    5. The current working directory.
    6. The directories listed in the PATH environment variable.
    • Windows maintain a list known DLLs, which are basically a set of system DLLs, that are always guaranteed to load from the system directory when absolute name is specified.
    • DllMain() function within the loaded library is called after loading the library into memory.

    Control the DLL search order:

    There are various option to modify the order in which the loading library is searched other than the default search order when absolute name is provided.

    Some of the APIs that can influence the DLL search order/path by the LoadLibraryEx() are as below:

    LoadLibraryEx() provide many flags that can be used to alter the default search order. Below table lists most of the flags and also depicts the DLL search order that is followed for each of them. Some of the options even consider the paths set with above mentioned APIs.

    Table 1: Depicting different options to the LoadLibraryEx and how it affects the DLL search order.

    Loading library as non-executable:
    It is not always required to load a library as an executable image. LoadLibraryEx() makes it possible to load a library as a data file, or an image resource, for example. For this purpose, it supports following different options:


    These options helps in treating a file as a normal data file rather as an executable module. Loading with this option doesn't call DLLMain() and none of the memory space of the loaded DLL data is marked as executable.

    Blocking the library from loading:
    Sometimes it might be required to block a library or block an illegitimate library from loading into an application. Check out following facilities to aid that:

      • AppLocker is a policy based mechanism to block DLLs from loading into applications. These policies can be pushed via group policy. AppLocker can control executables, scripts and installers.
      • When a new DLL loads, a notification is sent to AppLocker to verify that the DLL is allowed to load. AppLocker calls the Application Identity component to calculate the file attributes. It duplicates the existing process token and replaces those Application Identity attributes in the duplicated token with attributes of the loaded DLL. AppLocker then evaluates the policy for this DLL, and the duplicated token is discarded. Depending on the result of this check, the system either continues to load the DLL or stops the process.
      • AppLocker can block the DLL based on path, publisher or file hash.
      • Microsoft Authenticode technology can be used to sign the DLL, which is to attach digital signatures to the DLL to guarantee its authenticity and integrity.

    To summarize our discussion:

    To ensure secure loading of libraries

    • Use proper DLL search order.
    • Always specify the fully qualified path when the library location is constant.
    • Load as data file when required.
    • Make use of code signing infrastructure or AppLocker.

    Some common attack vectors we see:

    • Application directory attacks, especially from the temporary internet or download folder perspective. Particularly when the application is an installer, it is a common thing for people to download the installer into default directory and execute from there. Considering attacker can drop malicious file in the default directory can make use of application directory to load the DLLs. Manifest and .local redirection can also be used in this scenario.
    • Loading DLL from memory and also Powershell DLL injection. Which can be used by malwares to keep the loading of a malicious DLL from getting detected.
    • TOCTOU attacks when loading library from remote location.

    - Swamy Shivaganga Nagaraju, MSRC engineering team

  • Assessing risk for the May 2014 security updates

    Today we released eight security bulletins addressing 13 unique CVE’s. Two bulletins have a maximum severity rating of Critical while the other six have a maximum severity rating of Important. The table is designed to help you prioritize the deployment of 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)

    Victim browses to a malicious webpage. Critical 1 Likely to continue to see exploits leveraging CVE-2014-1815. This update includes the fix for CVE-2014-1776, first addressed by the MS14-021 out-of-band security update on May 1. However, MS14-029 is not a cumulative security update. Please first install the last cumulative security update for Internet Explorer before applying this update.

    (Common Controls - MSCOMCTL)

    Victim opens malicious RTF document Important n/a Security Feature Bypass only. Not likely to be exploited directly for code execution. This vulnerability has been leveraged as the ASLR bypass for in-the-wild exploits leveraging the following CVE’s:
    • CVE-2012-0158
    • CVE-2012-1856
    • CVE-2013-3906
    • CVE-2014-1761

    Installing this update will prevent this control from being used as an ASLR bypass in any potential future exploits.


    (Group Policy Preferences)

    Attacker having already compromised a domain-joined workstation leverages that access to query Group Policy Preferences to potentially discover obfuscated domain account credentials. Important 1 Likely to continue seeing attackers use this “post-exploitation” technique to move laterally across enterprise network. Security update prevents the feature from being used in the future but requires administrators to take action to remove passwords previously stored and still available. This issue and the methods for preventing its abuse are described in more detail at this SRD blog post.


    Attacker already running code on a machine as low privilege user takes advantage of elevated/high privileged process calling ShellExecute to elevate the low privileged process. Important 1 Discovered in use by limited number of commodity malware samples. Likely to continue seeing malware attempt to leverage this vulnerability to escalate from low privilege to higher privilege. Observed in the following malware families, each of which is already blocked by Microsoft anti-malware products:




    Attacker able to upload arbitrary content to SharePoint server could potentially run code in the context of the SharePoint service account. Critical 1 Likely to see reliable exploit emerge in next 30 days. Attacker must be granted access to upload content to SharePoint server to trigger vulnerability. We haven’t typically seen this type of vulnerability widely exploited, despite its exploitable nature.


    Attacker tricks victim into authenticating to Microsoft online service in such a way that authentication token can be captured and replayed by attacker. Important 1 Likely to see reliable exploit emerge in next 30 days. In addition to token replay vulnerability, this update also addresses a DLL preloading issue involving the Chinese grammar checker DLL. We’ve recently developed and posted updated documentation covering the best way to protect applications from this type of attack. You find that guidance in this blog post.

    (.NET Framework)

    Custom application developed leveraging the .NET Remoting feature could grant attack code execution access in response to specially crafted data. Important 1 Likely to see reliable exploit emerge in next 30 days. .NET Remoting feature used very rarely, and primarily only with applications written based on .NET Framework version 2.


    Attacker able to reach iSCSI endpoint can potential cause persistent resource exhaustion denial-of-service attack on Windows host. Important 3 Denial of service only. No chance for direct code execution.  

    - Jonathan Ness, MSRC engineering team