Automatically refreshing EMET GPO’s
If' you’ve tried configuring EMET via GPO’s you’ve probably come to realize that while the GPO’s may process normally and change registry keys locally on the system it does not actually affect the running configuration of EMET. From the user guide for EMET see the following
“Once EMET Group Policies are enabled, they will be written out to the registry at HKLM \SOFTWARE\Policies\Microsoft\EMET. To make them effective in EMET, the following command must be executed:
EMET_Conf –refresh”
So from an architectural standpoint EMET does not have a “service” running as system or something with local admin privileges. It does have a GUI System Tray Icon however this runs in your user mode context. EMET is basically a dll, emet.dll that gets injected into process by means of the application compatibility framework. This app compat framework uses a database file that keeps a list of process names/paths to executables that are affected when they start and what should be loaded within those processes. In order for the app compat database to be updated the emet_conf –refresh command has to be run to pull the GPO Reg key settings and import them into that database as it requires admin privileges (yeah make sure you elevate if you run it manually).
So with that said how I can make sure that my changes to GPO’s get applied on a periodic basis. Group Policy Preferences to the rescue. Basically we will create a task scheduler item with a trigger on Application Event ID 1704 source SceCli. So every time we see GPO’s refresh (more specifically security policy been applied successfully) this will trigger the command emet_conf –refresh.
Keep in mind that XP/2003/Vista requires the GPO Preferences CSE to be installed on your client systems to utilize GPP.
First start off by editing your existing GPO that you are utilizing to configure settings for your EMET clients. Instead of the normal EMET location we want to go under Computer Configuration>Preferences>Control Panel Settings>Scheduled Tasks
Right click in the open area on the right and create a new Scheduled Task (At least Windows 7). Give the Task a great name like “EMET CONFIG REFRESH”, assign a user account to run as "NTAUTHORITY\SYSTEM” may need to check the “Run with highest privileges” if UAC is enabled.
Next tab over to the Triggers tab and click New, we want to select trigger “On an event”, Application event log, source SceCli, event id 1704 and then click ok.
The next step is to add an Action on the Action tab. Click New on there and set the action as “Start a program” browse to where the emet_conf resides and select it, add the argument –refresh (it’s 2 dashes autocorrect keeps “fixing mine to a long line 
)
And that should be it. Click Ok/Apply out of everything and on next GPO refresh you should have a new eventid triggered task that updates EMET configuration based on last GPO processing 
.
Thanks and Good luck hopefully this helps you out let me know if I messed anything up on here.
Comments
- Anonymous
January 01, 2003
create 2 task scheduler items via group policy preferences.. use item level targeting on each one.. set one to target x86 systems and the other to target x64.. based on the targeting it either runs from program files or program files (x86). - Anonymous
January 01, 2003
Yes it is required for the actual EMET Mitigations... emet_conf ---list_system just shows system level mitigations and you are right for those.. emet_conf --refresh is not required for system level settings DEP/SEHOP/ASLR - Anonymous
January 01, 2003
Agreed you can "know" what you are configuring from a GPO perspective and capture the event id that you ran emet_conf --refresh and that in turn should give you the assurance that your configured settings are in place. The more complicated way to check would be to run something like http://blogs.msdn.com/b/heaths/archive/2007/11/02/sdb2xml.aspx against the appcompat db's and parse them out to see the configuration but that would require a lot of code/work vs checking to see when the last refresh ran as I'm fairly sure we log an event id in the app event log when we do that. - Anonymous
January 01, 2003
Great question!! had to do some research.. I basically ran Procmon and filtered on the emet_conf.exe process and ran emet_conf --list and then took at look at what it touched/read from... from what I can tell it does not ever access the c:windowsapppatchcustom directories or read the .sdb files there. I renamed the custom .sdb files as a test and then ran --list again and it still shows same list of protections. Also I kicked off excel and looked at in the emet GUI and it is not protected at that point.. so --list is showing what it believes to be configured from the registry keys from what I can tell. - Anonymous
January 01, 2003
Thanks for that clarification. Does emet_conf --list pull data from the app compat database (what is really being mitigated) or from the registry? - Anonymous
January 01, 2003
Thanks again Kurt! So it sounds like there is no easy way to audit what is actually being mitigated when using a GPO deployment. We just need to be sure and run --refresh and probably capture the results for audit purposes. - Anonymous
January 01, 2003
No.. and that's a good point as new installs of emet are typically in new folders which would mean you need new/modified GPO/task scheduler item - Anonymous
January 01, 2003
Is EMET_Conf --refresh required for EMET 4.1? I tested by deploying EMET via GPO with settings, then exporting EMET_Conf --list_system on a target. Then I changed the system settings in the GPO and ran gpupdate /force on the target; then exported EMET_Conf --list_system again and the GPO changes were reflected. I never used EMET_Conf --refresh. - Anonymous
January 01, 2003
The comment has been removed - Anonymous
April 23, 2014
Kurt, can the GPP recognize regex for the path to emet? Like in C:Program FilesEMET* - Anonymous
April 28, 2014
Hello Kurt, how would I go about setting the --refresh in the GPO if we are in a mixed environment please??? We have both x86 and x64 Win 7 computers and in the Scheduled Tasks, there is only the option for 1 "Program/script". Any ideas or suggestions please??? Thanking you in advance, Lee - Anonymous
April 29, 2014
Thank you so much, Kurt. We just applied the Task Scheduler and all looks well. You are the man :-) - Anonymous
April 29, 2014
If you have deployed EMET in an enterprise setting you have probably realized there are basically - Anonymous
May 15, 2014
Just brilliant, this works like a clock. Thanks - Anonymous
February 06, 2015
Kurt, sorry to bump an old post but wanted to ask -- it seems like EMET 5.1, having the EMET service, processes GPO updates without the need to run emet_conf. Is that correct? Also, is the team working on a way to allow enabling EAF+ and ASR through GPOs?
Finally, would it work to say, use GPOs to manage most settings but deploy a script to import EAF+ and ASR config for a few apps? If so, can we continue to manage the other mitigation through GPO?
Thank you! - Anonymous
February 06, 2015
Awesome, that's very helpful info to have. Thank you for the super fast response!