Asked by:

Enterprise Deployment of EMET

General discussion

There have been a number of requests to make enterprise deployment of EMET easier.This is something we are actively working on.We expect to be able to offer this along with the ability to configure and monitor EMET across an enterprise in the future.Until this is ready, there are a few options for rolling out EMET across an enterprise.Please note that these options are only relevant for the application specific mitigations and not the system policy for mitigations.

Option 1: Deploy from a common share

The first step for this is to place all the binaries on a common share (with the appropriate ACLS to prevent undesirable tampering).Next, EMET_conf.exe should be run with the --add parameter from each of the machines that are to be protected.This can be done with tools such as SCCM, startup scripts etc.When EMET_conf.exe runs, it will copy the necessary files to c:\windows\apppatch and will also make the necessary registry key changes.

To remove EMET from one of these machines, you can follow the same steps, but use either the --remove or --remove_all parameter with EMET_conf.exe.This will leave the files on the system, but will deactivate the EMET functionality.

This option involves rolling out the “EMET Setup.msi” to all of the target machines utilizing any number of package deployment options (including Group
Policy).Later, a script can be run that uses EMET_conf.exe –add to configure the appropriate target applications.

Option 3: Create a wrapper msi

Another approach you can take is to create a new msi that includes the “EMET Setup.msi” file.When the wrapper msi is installed, it can be set up to install the “EMET Setup.msi” file and then run EMET_conf.exe --add to configure the desired settings.It can also be configured to uninstall “EMET Setup.msi” if it is later uninstalled.

Thanks for the information. I am currently testing deployment using option 2. We are using SCCM packages to install the software and run a configuration batch file. I came up with this script so we could run it on both 32-bit and 64-bit
machines. It will add the programs it finds based on the paths. I would like to see the community develop a more complete list if this approach is efficient. Thanks.

This is a nice list, however, I would recommend using a script to search the machine for each of the file names that you would like to have protected. Patches tend to leave behind older versions of applications and these should also be protected.

With that being said, anyone have any other items to add to this great list that p2zilla started?

Thanks. Right now, the list just tries to add the program at that path. If it isn't there it just moves on. I would like to add more inteligence to it especially in the case of programs like Google Chrome which install in the user's profile
or a program is not installed to the default directory. I'm considering using PowerShell to create a more robust process of identifying if certain programs are on the computer. Any insights or examples into managing the configuration of this
program using tools like PowerShell would be appreciated. Thanks.

Deploy EMET using the MSI package to the clients.
Create an ADM template that puts the settings you want in the registry. Utilize a VBScript to read those settings and then use the registry location HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\(FileYouAreProtecting).exe to determine the path of the EXE you want to protect and execute EMET_conf.exe --set for the application. Schedule the script to run at varying times, or on logon, etc...

"I would not recommend mass-deployment of EMET to non-technical users. Some of the mitigations are very non-compatible and could potentially break applications for hundreds of thousands of users. The real value of EMET is with protecting legacy applications
running on legacy operating systems."

What kind of errors are you getting? (I'm not an SCCM expert but I can try to assist from the EMET perspective) I did have a case with EMET/SCCM where we needed to add the sdbhelper.dll into the SCCM configuration package if this has to do with creating/running
a package that runs the emet_conf --import command? Also it's usually better to start a new thread with an issue vs replying to a 2 year old dead thread as you probably won't get as much attention this way.

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.