Implement the Enhanced Mitigation Experience Toolkit (EMET) enterprise-wide

EMET 4.0 has been released.
Note that this post was written originally for EMET 3.5, but might still be as relevant.

Please take a look at a rudimentary performance analysis of EMET’s affect on RAM I/O speed.

Also, this post covers use of the command line tool emet_conf.

Keep an eye on the Securing your network project, specifically the Patch Management section. As of January 14th, 2012, I have no links present on the pages, so traverse the top menu links.


Lately, a new Java exploit that affects IE7/8 on Windows XP, and Java in IE 7/8/9 in Windows Vista, 7 has made a lot of news kerfuffle.

I’m not sure if others had previously, but Brian Krebs wrote about how implementing EMET will reduce the ability for the exploit technique to function (source). I think he was just waiting for the right time to plant to the seeds of EMET with the great unwashed and this was it. Well good on him (no, I’m not British, I just like that saying), so let’s go ahead and mold EMET into being easily deployable and manageable using the Windows tool that manages settings on distributed Windows systems, Group Policy.

EMET is a tool that stops some major memory exploits from being allowed to execute. It does some very cool things like “emulates” ASLR for processes that don’t have support for it.

Configure an administrative deploy point:
In order to deploy the EMET MSI, you must create a shared folder where the domain computer objects will have read access rights, and the user you will be executing msiexec.exe (in the next step) with will have write access. In this example, the accessible share and folder will be \\FILESERVER\install$\EMET.

Download and install EMET to the administrative deploy point:
1) Download EMET 3.0 (latest stable as of September 19th, 2012).
2) Start the installation to the administrative deploy point from the command line:

msiexec /a "EMET Setup.msi"

3) On the Network Location screen, type ‘\\FILESERVER\install$\EMET\’ (no quotes) and continue with the installation.

Configure a group policy to install EMET on target OUs:
1) Create a group policy with gpmc.msc and link it to a target OU. In this example, the group policy will be called “Workstation Packages” and the target OU will be “Test Workstations”.
2) Edit the GPO and traverse the tree to “Computer Configuration\Policies\Software Settings\Software installation”
3) On the Action menu, go to New> Package then type in “\\FILESERVER\install$\EMET\EMET Setup.msi”
4) Leaving “Assigned” bulleted click OK.
5) If you’d like to test (and you know you do)… refresh the group policy on the test workstation with “gpupdate /force” then reboot the machine for it to receive the package when prompted. The policy will take a bit more time to apply upon reboot and the EMET package will be installed, both synchronously.

Configure EMET policies via GPO:
Now that EMET is installed on your workstations, you can configure settings via Group Policy. The EMET network install copies ADMX and ADML Administrative Templates out of MSI. No Windows 2008 server? hmm… I don’t have time to deal with this now, you’ll have to write your own ADM.

1) Create an Administrative Template central store (if you don’t already have one) on your closest DC so that the templates replicate and copy the ADMX and ADML files into them (this will affect GPOs created under Windows 2003):

mkdir "%logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions"
mkdir "%logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions\en-us"
copy "\\FILESERVER\install$\EMET\Deployment\Group Policy Files\EMET.admx" "%logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions"
copy "\\FILESERVER\install$\EMET\Deployment\Group Policy Files\EMET.adml" "%logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions\en-us"

2) Create a group policy within gpmc.msc and link it to the “Test Workstations” OU. This group policy will be called “EMET Policy”.
3) Edit the GPO and traverse the tree to “Computer Configuration\Policies\Administrative Templates\Windows Components\EMET” (worried? read the note below)
4) Here you can configure EMET. The MSFT engineers were kind enough to test some existing versions of software for us and included them within “Default Protections for other popular software”. It’s important that you absolutely test software before protecting it with EMET to see if the software reacts badly to the various regulation provided by EMET.

Here’s some example entries for the “Application Settings” policy:

java.exe
skype.exe -EAF
YahooWidgets.exe
PGPserv.exe
PGPtray.exe
httpd.exe
mysqld.exe

After the policy pushes down the list of processes, you must reboot one in order for the processes to be monitored by EMET.

Note on ADM support and central stores:
If on a mixed environment, and you want to keep your GPOs as they were previously (loading ADMs, etc); once the EMET settings GPO is configured, you can change the name of the central store folder to anything but ‘%logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions” such as “%logonserver%\sysvol\%userdnsdomain%\Policies\ADMXPolicyDefinitions”

EMET registry keys:
All EMET related values are stored under HKLM\SOFTWARE\Policies\Microsoft\EMET\ (and HKU…)

The application specific policies are stored as… (where N is a number)

HKLM\SOFTWARE\Policies\Microsoft\EMET\AppSettings\
reg_sz:APPN="java.exe"

System wide policies on ASLR, DEp and SEHOP requirements are stored under:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EMET\SysSettings

Client-side config versus GPO config:
After some testing it became clear that a GUID and a different key structure is presented when using the EMET client application to configure policies for a process. The registry values are as follows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\process.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\process.exe reg_sz:"[full path to executable]"={GUID chosen at random} 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\_settings_
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\_settings_\{GUID}\
./reg_dword:"BottomUpASLR"=0x1 or 0x0
./reg_dword:"DEP"=0x1 or 0x0
./reg_dword:"EAF"=0x1 or 0x0
./reg_dword:"HeapSpray"=0x1 or 0x0
./reg_dword:"NullPage"=0x1 or 0x0
./reg_dword:"SEHOP"=0x1 or 0x0
./reg_sz:"heap_pages"=[13 memory address entries chosen at random]

After rebooting twice, EMET receives the configuration via GPO, but does not populate these keys.

With reference:

  1. Jola
    September 21, 2012 at 7:54 pm

    Nice tutorial.
    Just to let you know that the GPO is under Computer Configuration\Policies\Administrative Templates\Windows Components\EMET
    One level deeper than described above.

    • September 21, 2012 at 11:13 pm

      Thanks for the compliment!

      I’ll correct that.

  2. October 1, 2012 at 4:43 pm

    Thank you for the useful article on using Group Policy in the enterprise to roll out and configure EMET. It saved me loads of time!

    As far as the administrative templates provided with EMET, you can manage EMET through Group Policy Management on Windows 7 with RSAT installed – you do NOT need to write your own ADM for Win2003. See http://angrytechnician.wordpress.com/2009/11/05/the-angry-technicians-guide-to-managing-windows-7-you-idiots/

    • October 1, 2012 at 6:42 pm

      Thanks for the compliment.

      Thanks for adding this information!

  1. November 30, 2015 at 6:00 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: