But then someone points out to you that hey we have an enterprise script that runs on machines and well we can't fix it right now but it has some passwords hardcoded in there and they are popping in event logs on client looking like this…

And… all users of the system can view these events.

Unfortunately unlike say the Security event log of a system the PowerShell log security descriptor does allow all users of the system to view the content in that event log. There are some situations like the above where this isn't beneficial to your organization. With Windows 10 we introduced Protected Event Logging which you can read about at https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/ which will basically use certs to encrypt the events locally on a system and allow you to unencrypt them with the private key either on the same system or say an event forwarding server where you have collected them all with a PowerShell cmdlet. There are a couple of downfalls to this though in that this does not address Win7 and also I don't know of any SIEM that would know what to do with these events without doing some interesting custom integration work to decode all of these events either at ingest time or query time.

So for a more temporary solution I would recommend locking down the security descriptor on your PowerShell event logs to be more like the Security Event log. Since the PowerShell Operational Log is an Applications and Services event channel there isn't a traditional GPO setting to control this option. The blog article at https://www.frickelsoft.net/blog/?p=267 which covers setting a custom size on these logs gives the starting point at how to go about managing settings for these types of event logs. When you browse to the registry key that controls the settings for the PowerShell operational log at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PowerShell/Operational you can see the REG_SZ string value 'ChannelAccess' which on my system has the security descriptor in SDDL listed below:

O:BAG:SYD:(A;;0x2;;;S-1-15-2-1)(A;;0x2;;;S-1-15-3-1024-3153509613-960666767-3724611135-2725662640-12138253-543910227-1950414635-4190290187)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)

I also dumped the Security Descriptor for my Security event log as I estimate that's pretty much what I want to mirror by running wevtutil gl security which produces the following SD:

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

As you can tell the PowerShell log has quite a bit more ACE's in it including the one ending in IU = Interactive User i.e. anyone logged on the box pretty much.

I won't walk through all the steps here but basically you can use the steps at https://www.frickelsoft.net/blog/?p=267 and use Group Policy Preferences to set the ChannelAccess registry value to the same security descriptor that's used against the Security Log. From my testing this seems to have no adverse effects, PowerShell data is still logged for admins/non admins etc and still correctly viewable by Admins when viewing the event log however you are now denying access for non-admins on the system as seen below:

Thanks for your time and happy defending

So the first thing to make note of with regards to __PSLockDownPolicy is that this setting is completely undocumented from a Microsoft perspective. Yes, I'm a Microsoft employee and No this is not official documentation as to how this works from a Product Group but just my observations on how it seems to work from testing. Considering that this is undocumented this typically means unsupported as well so my guess is if you called up / opened a ticket online with CSS odds are you would probably hit a brick wall at some point with regards to doing something not officially supported by us.

When I was first looking at this setting the initial thing I was told was that it was pointless as User Environment variables override System Environment Variables i.e. all the attacking process would need to do was run a set __PSLockDownPolicy= to configure this variable to something else more conducive to that user and start a PowerShell session post setting the User Environment variable to a wanted value and they would be able to do whatever they wanted to anyway with Full Language mode again. Well… once I started testing I quickly found this not to be the case. I've tested trying to use this as a User Environment variable and it doesn't even seem to read it, I've tried the User Environment variable as a possible method of overriding the System Environment variable and that does not work either. I decided to ProcMon it and the procmon logs show that when PoSH starts it always reads in the system environment variable from the reg key HKLM\System\CurrentControlSet\Control\SESSION MANAGER\Environment\__PSLockdownPolicy that defines it and never queries for a User Environment variable with this name. So the end story here is that this absolutely works and that it cannot be overridden easily by an attacking piece of code in user mode space.

So with this thought in mind the next question is how feasible is this in the enterprise. Well since we can't set this into the users environment the first thing you need to recognize is that this is going to be on/off for computers as a whole. There is not going to be an easy method to say this machine is sometimes used by dev x vs sales person y and one has different requirements than others. If you don't have this sort of transient work force per computer account then this 'might' be a usable setting in your environment. One of the other questions I had is if I turn this on how do I know when this is breaking things in my environment? Fortunately this is actually handled fairly well in that whenever a script does not run due to Constrained Language mode we do actually throw a nice event in the PowerShell Operational Event log that specifically says a script was blocked due to Contrained Language mode. These could be collected via WEF/SIEM etc and reported/alerted on both for detection of bad things as well as detection of possible enterprise scripts which are being blocked due to this new setting.

The one last thing with regards to testing this setting that I found interesting was how many security principals that this setting applies to on a system. When using AppLocker w/ Scripts in Enforced mode and PoSH 5+ it's fairly easy to know which users this applies to and also to not apply this to local Administrators on a system as they obviously can turn this off if they desired. It's also quite expected that AppLocker doesn't apply to in the box security principals i.e. System/Network Service etc. So I figured I would test this as well and also observed that when using __PSLockDownPolicy it also affects the built in security principals, i.e. setting task scheduler to run as System and running a script that used Full Language elements was blocked, I also tested this via psexec as well to verify. This is a little more concerning from an enterprise perspective as from what I've seen our internal IT department uses a lot of scripts which run under SCCM etc against my system that would quickly be broken on my system if I were to enforce this.

For grins I also wanted to know what possibly using other settings for this value would reveal ie. whether I could set Language mode to None or anything else. The list below is what I came up with testing with the following and starting new sessions for each iteration.

gc Env:__PSLockdownPolicy
$ExecutionContext.SessionState.LanguageMode

0 = Full Language
1 = Full Language
2 = Full Language
3 = Full Language
4 = Constrained Language Mode
5 = Constrained Language Mode
6 = Constrained Language Mode
7 = Constrained Language Mode
8 = Full Language

So short story the values just seem to either do Full or Constrained I stopped after 8 J if you are bored and want to script some way to test this with more values feel free J.

So my ending thoughts are this is still useful but you need to be aware of usage of undocumented / possibly unsupported settings, be aware of the lack of a method to differentiate based on a user on a system and be aware that this affects system accounts as well on your systems.

Thanks and hopefully this is helpful to someone J Please correct me if you have found differently

Too many times dealing with customers I find that audit settings are either poorly configured or not configured at all.  The funny thing is this is not industry dependent etc. some of the customers who you would think have the best audit configurations due to various regulations and specific guidelines for auditing in many cases have some of the worst auditing setups.  You tend to find workstations that either don’t have any audit configured or have something like both legacy auditing and advanced audit policies half applied which puts them in a broken place when they have a setting they wanted in the old settings but the equivalent thing not set in the advanced audit policies.  I also tend to see a lot of .. well we delegate out GPO management to sub-OU managers either based on org hierarchy or geographical location management etc which typically results in new GPO’s for all these various sub-OU’s where each sub-OU manager does their own thing for audit which widely varies based on knowledge experience etc.  In my perfect world there would be 3 GPO’s linked at the root of each domain that controlled all audit for all systems.. one for Servers, one for DC’s (Ok yeah link it at the DC OU level ), and one for Workstations. Since this perfect world rarely happens I put together a script that will query all systems throughout a forest and dump current effective audit settings via auditpol along with a number of other audit settings that I would consider key but aren’t part of the normal ‘Advanced Audit Policies’.

I’ve called the set of scripts Get-AuditPol and they can be downloaded at https://github.com/kurtfalde/Get-Auditpol/

You will also need the PoshRSJobs module which you can get at https://github.com/proxb/PoshRSJob

The scripts are setup as follows:

Get-AuditPol.ps1

This is the main script which enumerates collections of DC’s, Servers and Workstations and then pipes them into runspaces using PoshRSJob (Great module for multithreading by Boe Prox).

Modify the $RunspaceThreads to control how many simultaneous threads are running .. there are 6 runspace pools kicked off so technically there are 6 x whatever this value is.

This is hardcoded to run from a c:\get-auditpol by default.. change to something else if you are using a different directory structure,  the output data will be dropped into a .\data folder

DC/Server/WorkstationAuditPolScriptblock.ps1

These 3 scripts are the script blocks for the ‘AuditPol’ runspaces.  The runspaces use WMI (can’t rely on psremoting being enabled on systems) to remotely kick off auditpol /backup on the remote systems and dump the results to c:\windows\SystemName-Auditpol.csv on the remote system.  As I didn’t know a good way to check on whether this process had completed I cheated and just threw a sleep command in for a few seconds to wait on this to complete following running the command.  Once the wait completes we remotely import-csv on the content to an object and then append that content to a local .csv with the aggregate results of auditpol for all systems in the runspace.  I am using a mutex per runspace to marshal connections to the aggregate .csv file to ensure we don’t lose data as much as possible by preventing file being locked for writing errors.

DC/Server/WorkstationScriptblock.ps1

These 3 scripts are the script blocks for the various other Audit settings of interest on the remote systems.  This script is using remote registry calls via dotnet to query various key’s existence/values and appending to an aggregate .csv locally on the collector system for the runspace group. The data that we are gathering includes the following:

• Is the force Advanced Audit Policies reg key set
• Is CMD line auditing enabled for Process Creation Events – see https://technet.microsoft.com/en-us/library/dn535776.aspx for more info
• Is AppLocker logging enabled (either Enforced or in Audit mode … this is not about AppLocker and how it’s configured but rather if it is providing forensically valuable artifacts on the system)
• Is PowerShell Script Block Logging enabled
• Is PowerShell Transcription Logging enabled
• Is the Special Groups Auditing registry key configured with anything – see https://blogs.technet.microsoft.com/askds/2008/03/11/special-groups-auditing-via-group-policy-preferences/ (oh you didn’t know you actually had to configure something extra for that audit setting???? )
• Machine Name, OS version, OU location/DN

For now this is all I currently have however once I can actually get a good data set that’s not the 4 or so machines in my lab I plan on taking this data and throwing into a PowerBI desktop file and creating some visualizations around this to show where variances are and how well systems conform to recommended Microsoft Security Baselines.  Let me know if this helps you at all and if you have a dataset that you can share that I could use to create visualizations please let me know.

Thanks

Kurt

https://psasync.codeplex.com/ – psasync runspaces multi-threading PowerShell module

https://github.com/kurtfalde/DNS-Debug – the DNS Debug scripts

I’ve been bugged recently (@jepayneMSFT) to post some scripts I put together quite a while back so here they are.  These were written due to an onsite visit with a customer where we knew various DNS names that were of interest that were being used as C2 hosts and we wanted to track down specifically which clients were making calls to these host names.  Like many IT things there are other ways of doing this including proxy/firewall logs etc but in this case seeing I’m a MSFT resource we will be looking at the DNS debug logs on MSFT Windows Servers.

I am making use of a psasync module https://newsqlblog.com/2012/12/17/psasync-module-multithreaded-powershell/ written by Jon Boulineau in this case which allows multithreading via runspaces in PowerShell.  I tend to use Boe Prox’s poshrsjob module https://github.com/proxb/PoshRSJob usually now for runspaces but in general they both work fine, it’s just a .net runspaces thing in the background and these modules make it easier to use them.

The solution is composed of the following 3 scripts:

Enable-DNSDebugAsync.ps1

Retrieve-DNSDebugAsync.ps1

Search-DNSDebugLogs.ps1

These were designed unfortunately for a customer where they were still running 2003 DC’s at the time (yes it was fully after support had ended for 2003) and the script is focused around not needing the activedirectory PowerShell module. 

Enable-DNSDebugAsync.ps1 uses system.directoryservices to get all DC’s in the forest and then uses the dnscmd command line tool to enable the proper amount of dns debug logging across all DC’s in the forest.  You will need RPC access to all DC/DNS servers in the environment from the system you run this from.  It will set the log file to be 500Mb and be placed in c:\windows\system32\dns\dns.log.

Retrieve-DNSDebugAsync.ps1 (maybe I should have used Get- instead to be more powershelly) basically uses multithreading to reach out to all DC’s and copy these DNS debug logs back to the system you are running the scripts from.  This does not use PSRemoting as that was not available so instead uses WMI for some process that I call remotely such as copying the dns.log file to a server-date-dns.log file.  It also then makes use of the makecab.exe utility to basically zip/cab up that log file (500Mb of just text compresses really well and helps with transferring across wan links).  Once zipped up it moves that file back to the collector system.  This is only using 10 runspaces currently but you can change that to whatever works for your collector system/environment.

Search-DNSDebugLogs.ps1 allows you to fill out the $BadThings array with terms that you might be interested in such as domain names of interest and then it will search through the dns debug logs that have been gathered to the collector system.  This isn’t as efficient as it could be as it uses get-content which I personally find incredibly slow when you start to get 100’s of MB’s or 10’s of Gb’s worth of log files but I never rewrote this one using streamreader.  Also technically it would probably be great to parse these / aggregate into a single file and load into PowerBI which would allow quickly searching/filtering as well.

Anyhow it’s any interesting tactical piece of code, I would expect if you started to do this proactively instead you would probably be looking more at using Azure OMS / Log Analytics / Splunk and automatically gathering the dns.log file via an agent into a SIEM solution and write up queries/alerts there instead.  Hopefully this is helpful and interesting to someone let me know if you have any questions.

I’ve seen various questions recently around the use of EMET and DEP for protecting processes.  Prior to launching into this I highly recommend reading Rob Hensing’s old but good articles on this at https://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx and https://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-2.aspx .

Getting first things out of the way DEP is an OS/System Mitigation.  EMET does not have a mitigation called DEP it merely makes it easier to configure DEP for the OS as a whole as well as the ability to opt-in applications that were not compiled with DEP configured or the ability to opt-out applications if the OS is set to DEP always-on.

This is the issue I’ve typically seen with EMET + DEP + process:

• System is set to DEP Opt-In (i.e. processes don’t run with DEP enabled unless compiled that way for x86 apps x64 is a different story as they are always DEP)
• application.exe is either an x86 or x64 application that is compiled as a DEP aware application
• EMET also is protecting application.exe and has the DEP box checked for application.exe

So demonstrating a lab setup I have three applications shown in the pic below that are exactly what the app names state

• x64AppCompiledWDEP.exe = x64 application with DEP enabled
• x86AppCompiledWDEP.exe = x86 application compiled with DEP enabled
• x86AppCompiledWODEP.exe = x86 application compiled with DEP not enabled or the NXCOMPAT linker option set to NO (see https://msdn.microsoft.com/en-us/library/ms235442.aspx)

So at times (I unfortunately can’t repro this in my lab) having this setup for the x86AppCompiledWDEP.exe application will cause application crashes with whatever that application is (have seen it happen to IE and Office applications among others).  The proper way usually to fix this is to ensure that EMET does not try to opt-in this process to DEP as it is already using DEP in most cases.  In you EMET configuration find the application with the issues and uncheck the DEP box.  The big push back I typically get here is that you are turning off mitigations this is not good etc and this is absolutely not the case if this is already a DEP aware application. The next slide shows the same applications with the DEP box unchecked for each of the applications that previously had it checked on a system that has DEP set to OPT-IN.

Notice in the Task manager section (btw I right clicked on the columns and added the Data Execution Prevention / DEP column) that DEP is still enable for both the x64 application as well as the x86 application that was compiled as DEP aware.  It is not however enabled any more for the x86 application that was not compiled with DEP which means in the first screenshot that EMET was actually working quite well and opting my non-DEP application into the OS DEP mitigation at process startup.

So the point of this article is basically if you are seeing crashes for an application and it turns out to be because EMET is attempting to opt-in an application to DEP,  unchecking the DEP box for that application may fix the problem. Also if the application is a recent version of IE/Office etc that is already using DEP (use task manager to check on that) you will not be lowering or changing your security posture in any way.

Thanks

Kurt

With that said lets break it out into the following portions:

• Ensuring you are auditing LAPS Password Retrievals
• Forwarding those audit events to a central system
• Parsing out those events and visualizing them via PowerBI

I’ve put all the scripts etc for this on GitHub at https://github.com/kurtfalde/LAPS-Reporting, you will also need the EventLogWatcher.psm1 module from https://pseventlogwatcher.codeplex.com/ as well.

Configuring auditing for LAPS

• The first step is to ensure that you place the right SACL / audit entry on the OU’s / Computer objects that you wish to audit access to.  The step to do this is found in the LAPS_OperationsGuide.docx and basically calls out using the PowerShell cmdlet that comes with the product:

Set-AdmPwdAuditing –OrgUnit: <name of OU on which you want to setup the auditing> -AuditedPrincipals: :<identification of users/groups whose access to password shall be audited>

 

• The next step is to ensure that your Domain Controllers have the right audit policy applied to them.  In this case the specific audit policy setting we are looking for is under Advanced Audit Policies > DS Access > Audit Directory Service Access as seen below.

Forwarding the Audit Events for LAPS

• I’m going to kind of skip over verifying you are getting audit events I’m hoping you test with the LAPSUI and with Active Directory Users and Computers and verify you are actually seeing the audit events in your DC logs.  While testing make sure you are testing reading against a specific DC and checking that DC’s logs to make your life easier.
• Since we are forwarding events from the Security Event log we need to ensure the Network Service account has ‘read’ rights to this log (by default it does not).  The quickest way to do this is to add the Network Service group to the Event Log Readers group in the domain you are gathering events from.  You could also modify the SDDL on the security log channel via GPO but that’s a bigger change and I’m not a fan of doing it that way.
• Create a GPO for your DC’s or modify an existing one that touches your DC’s to have them point to your WEF (Windows Event Forwarding) server.  You need to modify the setting Computer>Policies>Admin Templates>Windows Components>Event Forwarding>Subscription Manager

• At this point we need to go to the WEF server and copy all of the content from the GitHub link above to a folder c:\laps on this server.
• We also need to download the EventLogWatcher.psm1 module from codeplex at https://pseventlogwatcher.codeplex.com/ and place in the c:\laps directory
• Make sure to ‘unblock’ the two ps1 files in the folder as they were downloaded from the Internet and PS will throw an error regarding them on initial runs.
• Edit the LAPSServerSetup.ps1 script in the PowerShell ISE

• Modify the $DCTOQUERY value to point to the DC you have created test laps audit events on

• Run the LAPSServerSetup.ps1 script… IF this works properly you should get the following:

• A task scheduler item called LAPS Parsing Task that runs the parsing script automatically on reboot of the system
• An Event Forwarding Subscription called “LAPS Audit Events” which has the proper XPath filter for laps audit events and is set to get data from DC’s in your domain.
• The script also does a number of other things such as ensuring WinRM and Windows Event Collection service are setup and running properly as well

• Since DC’s refresh policy every 5 min by default we should start seeing ‘Source Computers’ for the subscription in rather quick order.  Also if they have any LAPS audit events those should start showing up quickly in the Forwarded Events log as the subscription is configured to grab any pre-existing events from the client logs.

Parsing the events and visualization via PowerBi

• At this point if there are events in the Forwarded Events log then go to Task Scheduler and start the LAPS Parsing Task that was created.  This should in turn start parsing those events and outputting the results to a c:\laps\laps.csv file on the system.
• Install the PowerBI Desktop client on your WEF server, this can be obtained from https://powerbi.microsoft.com/en-us/desktop for FREE!!
• Use the PowerBI Desktop client to open the ‘LAPS Audit Dashboard.pbix’ file.  The data in the file by default is stale data from my lab so utilize the “Refresh’ button from the top ribbon to have the laps.csv file from your environment parsed into the data model in PowerBI. 
• At this point you should see some graphics showing Users that have queried for LAPS passwords along with which computers have been queried for on the first page and a second page with the raw data in pivot slicers.  Sorry not the best dashboard as I didn’t spend much time on this piece yet but may again soon and if so I will update the GitHub with a newer .pbix file.

• That is pretty much the end of this story if you are going to use this locally.  If however you subscribe to the PowerBI service either via an individual subscription 12$ /month or have PowerBI via your O365 subscription then I would highly recommend installing the Personal Gateway on your WEF server and the .pbix file up in the PowerBI service and configuring the gateway to sync your data up to the cloud instead.  This gives you a nice(r) web portal and also the ability to use IOS/Android/Windows apps to view the dashboard.

Hopefully this works for you and if not please provide comments and I’ll do my best to fix.  Thanks for reading.

So I frequently get customers that ask how do I know what EMET is actually doing out there.  Unfortunately like a number of our products EMET is basically the client.  We do have GPO’s to manage it but there is no included System Center reporting console or the like.

If your organization is fortunate enough to have some type of SIEM / SCOM etc that has agents on all clients then you can use that to gather the appropriate source EMET Event ID 1,2 (Maybe 42 for SSL Pinning) events from the Application Event Log to determine when mitigations are being triggered in your environment.  More commonly I see customers that either don’t have a SIEM or if they do have one they rarely put the agent across all of their desktops.

In the scenario with no agents on the clients then typically what we see and recommend is the use of Windows Event Forwarding to centralize the events of interest.  In some cases forwarding is used to drop them all in a centralized location then you utilize the SIEM agent on that central location and just consume the specific events from that central location and this tends to work out well in many environments.

For the customers that don’t have a SIEM or would just like to have some tools to help with piloting/deployment etc I present the following set of scripts/solution:

The basic premise of the solution looks like this (sorry my visio skills= bad )

• GPO tells client to talk to WEF Subscription Server WEFSERVER1
• Client contacts WEFSERVER1 for subscription which says to send EMET 1,2
• Client subsequently forwards EMET Event ID 1,2 any time they occur
• Script EMETReporting.ps1 on the WEF server triggers anytime new event comes in and parses out interesting data fields to a c:\emet\emet.csv file
• PowerBI Desktop dashboard file consumes emet.csv and shows visualizations of the data
• Optional you put that PowerBI file up in the PowerBI service and use the PowerBI Personal Data Gateway client to sync it to the cloud and get a web based dashboard that also has IOS/Android/Windows apps available to it.

I’ve placed all the files at https://github.com/kurtfalde/EMET-Reporting except for an event log watcher module from https://pseventlogwatcher.codeplex.com/ which you will also need. Start off by downloading the entire contents of both locations and place them in a c:\EMET folder on the server which you are planning to utilize for a WEF (Windows Event Forwarding) Subscription Server.

Once copied there you should have a folder that pretty much has the following content

The first thing to run is the EMETWEFServerSetup.ps1 script as this will configure the following:

• Set WinRM service to start automatically
• Run WinRM quickconfig to ensure that WinRM is listening and the correct firewall inbound rules are enabled
• Increases the size of the Forwarded Events log to 500Mb
• Runs wecutl qc –quiet to configure the Windows Event Collection service to be able to create/manage WEF Subscriptions
• Imports a preconfigured EMETSubscription.xml that collects EMET Event ID 1,2 for “Domain Computers”
• Imports and creates a Task Scheduler item that runs the EMETReporting.ps1 script in the background anytime the computer restarts

(FYI you may need to right click and “unblock” the .ps1 and .psm1 files as PS execution policies don’t like running things from the Internet)

Once you run the EMETWEFServerSetup.ps1 script spot check and verify that the task scheduler item is in place and that the Event Subscription is in place.

EMET Parsing Task (In Task Scheduler)

EMET Audit Events (In Event Viewer)

Go ahead and start the task scheduler item so the script registers that it’s watching for events incoming and parsing them.  It should restart automatically if you reboot the system at any point.

At this point we need to ensure clients are talking to this server which we will do via a GPO.  Create or modify an existing GPO that is assigned to your EMET clients and configure the Policy>Computer Configuration>Administrative Templates>Windows Components>Event Forwarding>Target Subscription Manager setting to point to the WEF server you just configured.

Once this has been completed test some clients to ensure they picked up the setting and are talking to the WEF server and pulling the subscription properly. After running a GPupdate on the clients the best place to look is in Event Viewer>Applications and Services Logs>Microsoft>Windows>Eventlog-ForwardingPlugin>Operational Event log.  A good event is 100  which says that the Subscription EMET Audit Events was created successfully (if you have others you are probably going to have to do some troubleshooting if you have nothing make sure you have the WinRM service set to automatic on your clients).  Event should look like this.

You can also check the subscription on the WEF server and look at how many clients it has in the Event Viewer as well.

At this point if everything is working properly you should hopefully see that the script begins parsing events as they come in.  The subscription is set to gather an existing EMET Event ID 1,2 on the clients event logs so if you have had any triggering that hasn’t rolled off your application event logs you may well start getting data immediately.  If not you could always test by loading Java in IE and testing the ASR mitigation by browsing to a site that attempts to load Java.

Provided all of the other items worked properly and a EMET.csv is now being created in the c:\emet\emet.csv you can now open that with the included PowerBI Desktop Dashboard file.  You will need to download and install the PowerBI Desktop Client from https://powerbi.microsoft.com/en-us/desktop (it’s free), once installed open the “EMET Dashboard.pbix” file in the c:\emet folder.  It will initially have junk test lab data in it and not your environment yet, you wan to click the ‘Refresh’ button at the top which will cause it to import the c:\emet\emet.csv file and display actual data from your environment.

You can either just use this as a local dashboard or if you want to put it in the cloud/sync it then consider using the PowerBI service (can either be purchased individually or part of o365 subscriptions) to host this.  I’m not going to go through the steps for this here but you can basically import the .pbix file to PowerBI, download the PowerBI Personal Gateway Client and configure it on the server and then set your data model that you uploaded to sync automatically through the client.  This in turn will give you a web based dashboard which also has IOS/Android/Windows apps available to it. 

Hopefully some of you take the time and try this out I would really appreciate feedback.  Thanks

Over time I have had enough hassles creating xpath filters for Event Log Filtering / WEF setups that I finally decided I would automate some of this to make it easier on myself.  The following code lets you put in the Event Record ID from an Event which you want to find again.

If this works properly and that’s a big if It should parse through every node and attribute that has a value and create an output line which you can use in an Event Log / WEF Xpath filter.. So here’s the code:

<#
Script written to parse Event Log Entries to make usable Windows Event log filtering xpath for Windows Event Filters and Windows Eventlog Forwarding
Finds all Nodes and Attributes that are not empty and not null and then recurses 3 levels up to find the 'Event' node and writes out the correct xpath
This includes replacing tabs and carriage returns in the #text of the node which do not transport properly to an event filter via copy/paste
Written 5/22/2015 - Kurt Falde
#>

$EventRecordIDToParse = "3139115"
$xpath =  "*[System[EventRecordID=($EventRecordIDtoparse)]]"
$EventToParse = Get-WinEvent -LogName 'Security' -FilterXPath "$xpath"
[xml]$EventToParsexml = $EventToParse.ToXml()
$nodes = $EventToParsexml | Select-Xml -XPath './/*'
Foreach ($node in $nodes){

#Parse Nodes that are not empty, not null and do not have attributes
if (($node.node.IsEmpty -eq $false) -and ($node.node.'#text' -ne $null) -and ($node.node.HasAttributes -eq $false)){
   
    $Ntext = $node.Node.'#text'
    #write-Host $Ntext
    $Ntext = $Ntext.Replace("`n", "&#xD;&#xA;").Replace("`t", "&#x09;")
    #write-host $Ntext
    $Nname = $node.Node.Name
    #write-host $Nname
    if($node.node.Parentnode.ParentNode.Name -eq "Event"){
    write-host "*[$($node.node.Parentnode.name)[($Nname=$Ntext)]]"}
    if($node.node.Parentnode.ParentNode.ParentNode.Name -eq "Event"){
    write-host "*[$($node.node.ParentNode.Parentnode.name)[$($node.node.parentnode.name)[($Nname=$Ntext)]]]"}
    if($node.node.Parentnode.ParentNode.ParentNode.Parentnode.Name -eq "Event"){
    write-host "*[$($node.node.ParentNode.Parentnode.Parentnode.name)[$($node.node.ParentNode.Parentnode.name)[$($node.node.parentnode.name)[($Nname=$Ntext)]]]]"}
  }

#Parses nodes that are not empty, not null and have attributes
if (($node.node.IsEmpty -eq $false) -and ($node.node.'#text' -ne $null) -and ($node.node.HasAttributes -eq $true)){
    $Ntext = $node.Node.'#text'
    #write-Host $Ntext
    $Ntext = $Ntext.Replace("`n", "&#xD;&#xA;").Replace("`t", "&#x09;")
    #write-host $Ntext
    $Nname = $node.Node.Name
    #write-host $Nname
    # *[EventData[Data[@Name='Properties'] and (Data='%%7688&#x
    if($node.node.Parentnode.ParentNode.Name -eq "Event"){
    write-host "*[$($node.node.Parentnode.name)[$($node.node.LocalName)[@Name='$Nname'] and ($($node.node.LocalName)='$Ntext')]]"}
    if($node.node.Parentnode.ParentNode.ParentNode.Name -eq "Event"){
    write-host "*[$($node.node.ParentNode.Parentnode.name)[$($node.node.parentnode.name)[($Nname=$Ntext)]]]"}
    if($node.node.Parentnode.ParentNode.ParentNode.Parentnode.Name -eq "Event"){
    write-host "*[$($node.node.ParentNode.Parentnode.Parentnode.name)[$($node.node.ParentNode.Parentnode.name)[$($node.node.parentnode.name)[($Nname=$Ntext)]]]]"}
    }

#Parses nodes that are empty/null but have attributes
if (($node.node.IsEmpty -ne $false) -and ($node.node.'#text' -eq $null) -and ($node.node.HasAttributes -eq $true)){
    $AttributeText = ""
    $Attributes = $node.node.Attributes
    Foreach($Attribute in $Attributes){
    $AttrName = $Attribute.Name
    $AttrText = $Attribute.'#text'
    $AttributeText += "@$AttrName='$AttrText' and "
    #write-host $AttributeText
    }
    $AttributeText = $AttributeText.TrimEnd(" and ")
    $Nname = $node.Node.Name
    if($node.node.Parentnode.ParentNode.Name -eq "Event"){
    write-host "*[$($node.node.Parentnode.name)[$($node.node.LocalName)[$AttributeText]]"}
    if($node.node.Parentnode.ParentNode.ParentNode.Name -eq "Event"){
    write-host "*[$($node.node.ParentNode.Parentnode.name)[$($node.node.parentnode.name)[$AttributeText]]]"}
    if($node.node.Parentnode.ParentNode.ParentNode.Parentnode.Name -eq "Event"){
    write-host "*[$($node.node.ParentNode.Parentnode.Parentnode.name)[$($node.node.ParentNode.Parentnode.name)[$($node.node.parentnode.name)[$AttributeText]]]]"}
    }

}

Running the above against my Event Record ID I chose in turn gives me the following output:

Well that’s it.  Hopefully this helps someone else setting up WEF Xpath filters.  Let me know if I have any bugs

<# EDIT .. there has been a wiki article posted by my colleague John Rodriguez at https://social.technet.microsoft.com/wiki/contents/articles/32905.how-to-enable-restricted-admin-mode-for-remote-desktop.aspx that discusses RDPRA configuration further which is a good source for information and seeing it’s a WIKI is also a better place to keep updated easily #>

This is a follow on post to my previous one about a year ago regarding RDPRA (yeah just made up an acronym).  If you have not as a security responsible resource for your organization viewed and read through https://technet.microsoft.com/en-us/library/security/2871997.aspx I would highly recommend doing so as there are a number of security OS fixes that were introduced in 8.1/2012 R2 which subsequently have been back-ported to Win 7/2008 R2/8/2012.

The key section of that article that I want to cover are the below items:

On October 14, 2014, Microsoft released the following updates. The applicable updates add a restricted admin mode for Remote Desktop Connection and Remote Desktop Protocol:

• 2984972 for supported editions of Windows 7 and Windows Server 2008 R2
• 2984976 for supported editions of Windows 7 and Windows Server 2008 R2 that have update 2592687 (Remote Desktop Protocol (RDP) 8.0 update) installed. Customers who install update 2984976 must also install update 2984972.
• 2984981 for supported editions of Windows 7 and Windows Server 2008 R2 that have update 2830477 (Remote Desktop Connection (RDC) 8.1 client update) installed. Customers who install update 2984981 must also install update 2984972.
• 2973501 for supported editions of Windows 8, Windows Server 2012, and Windows RT.

AND

Two registry key settings can be configured to manage the Restricted Admin mode. The DisableRestrictedAdmin key is used to enable or disable Restricted Admin mode. If Restricted Admin mode is enabled, the DisableRestrictedAdminOutboundCreds is used to enable or disable the ability for a user connected to a system using Remote Desktop with Restricted Admin mode from automatically authenticating to remote resources using the local machine account.

So basically we back-ported both the ability to initiate RDPRA connections as well as receive RDPRA connections on Win7+ platforms.

The updates that are listed above are all “Security” updates which means that they have probably been applied to your current systems at this point (or you need to examine your patching methodology). By default RDPRA as a “server” / endpoint is not enabled on any systems when installed.  In order to enable this setting you need to create the following registry value.

DWORD value that is named DisableRestrictedAdmin at the following location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

• To disable Restricted Admin mode, type 1 in the Value data box, and then click OK.
• To enable Restricted Admin mode, type 0 in the Value data box, and then click OK.

By default the value does not exist, creating it and assigning a value of 0 to it will immediately enable that system to receive RDPRA connections (no reboot’s required).

With this backport there was also another registry value that was introduced called DisableRestrictedAdminOutboundCreds.  It also must be created as follows:

DWORD value that is named DisableRestrictedAdminOutboundCreds at the following location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

• Default value = doesn’t exist = 0 = Admin Outbound Creds are enabled 
• Value =1 == Admin Outbound Creds are disabled

So what does this new setting mean?  If you read my previous article I go into detail about how we authenticate to the system using RDPRA however once logged onto it if we try to hop from that system to another system say a file server or some other resource that our outbound credentials at that point are not our domain credentials but rather we are authenticating as the domain\computer$ of the system we did an RDPRA connection to.  This new setting allows you to go a step further and disable that functionality as well  which basically means you fail at authentication to network resources when trying to auth outbound from a system that you used RDPRA to connect to.

In case you are wondering I am aware that RDPRA does open a new issue from an exploit perspective in that it allows a modified rdp client such as FreeRDP-pth to use an NTHash as an authentication method which normally is not allowed.  You will have to do your own risk analysis to determine whether or not using RDPRA is feasible in your environment.  If you are randomizing local account passwords and they are unique across your machines in your environment and you are using firewalling between your client base then I would argue that using RDPRA is a value add in that it allows helpdesk to be able to connect to client machines easily without exposing their credentials to those client machines.

An EMET customer pointed out that for the Default Sets in the .admx GPO’s the “Disabled” setting wasn’t actually doing anything. 

After some review of it appeared that these 3 settings have an <enabledList> however no <disabledList> in the GPO to control them which in turn meant the Disabled button didn’t perform a removal of the registry keys.  Setting to Not Configured would remove them however in a tiered GPO situation an Enabled would take precedence over a Not Configured Setting.

I’ve attached an updated emet.admx file to this post that contains settings that will make the Disabled setting properly work.  If you use emet.admx in your environment I recommend replacing the copy you currently have in your SYSVOL Policy Definitions folder (the emet.adml doesn’t need any changes).

Here is the link to get an updated copy.  https://1drv.ms/1wl5EN6