Automating the world one-liner at a time…
Have you tried out the new AppLocker feature in Windows 7? If not, check it out here and here. Also check out the AppLocker references during TechEd here along with a related video here.
AppLocker allows you to specify applications that can or cannot run on the machines in your network. AppLocker’s management tools are optimized towards creating an “allow list” of applications i.e. the list of applications that are allowed to run. Applications not on the allow list are blocked by the system.
Perhaps, you have been intrigued by “allow listing” and have tried to implement this approach to get a control over the applications being run on machines in your network. The typical concern about the “allow listing” approach is that it is too hard to build and maintain an “allow list”. And if this list is not up to date, then applications that are not in the list get blocked, your users call HelpDesk, costs go up and it becomes harder to justify the value of maintaining an allow list.
We heard these concerns. So, with AppLocker in Windows 7, we have tried to reduce the cost of developing and keeping an allow list up to date. So, in addition to a lot of enhancements in the AppLocker policy enforcement engine, support for testing policies using audit mode and improvements to the MMC snapin for AppLocker policy management, in the Windows 7 RC builds, we have also introduced a set of AppLocker Powershell cmdlets.
To get started, just start a new elevated Powershell session and import the AppLocker module and you are on your way …
The above screenshot shows the five cmdlets that are currently available. Go ahead and use the convenient “get-help” command to check out the details of each AppLocker cmdlet. Now let’s step through each of the cmdlets and see what they do:
This is the most basic cmdlet in the AppLocker family. It provides the very simple (yet powerful) functionality of looking through a list of files, folders or event log entries and extracting the information relevant to AppLocker e.g. for each executable in a folder, it can retrieve the corresponding publisher, path and hash information etc. Here is an example:
The “Recurse” flag tells the cmdlet to dive in to each sub-folder of Office12 while the FileType enum indicates that only Executable (as opposed to scripts, MSIs etc.) should be looked at. In the example, we piped the output to out-gridview to provide an easier visualization of the file information retrieved.
This cmdlet can also be used to retrieve AppLocker file information from the current event log or from an archived event log file.
You might be asking why this is so interesting (the SHA-256 hash of each file is really cool, right? :))? Well, we promise that this does get interesting and useful. Read on:
This cmdlet is most useful to quickly generate a new AppLocker policy from a list of AppLocker file information. Imagine generating all the rules necessary to allow Microsoft Office12 programs to run using a single command line! Here it goes:
In the above example, we used the New-AppLockerPolicy cmdlet to generate a policy for Office12 using publisher rules for signed binaries and hash rules for any unsigned binaries it might encounter. The “-Optimize” flag provides another interesting feature; rather than create one rule for every executable, this flag causes the cmdlet to look for specific patterns and create an optimal set of rules. For publisher rules, this can lead to a fewer set of rules. For hash rules, this will group multiple hashes in to a single rule.
To save the generated policy, we redirected the output to an XML file. The generated policy can be conveniently loaded and applied using AppLocker MMC snapin (available through secpol.msc or gpmc.msc).
Now that we have generated a policy for Microsoft Office12, how about we try to test and apply it?
Using the Test-AppLockerPolicy cmdlet
Wasn’t it a little too easy to generate a policy? Can we just check and confirm that we can really continue to use Outlook.exe once we apply/set the policy? Yes, we can! Here is how:
The cmdlet not only confirms that Outlook.exe would have been allowed, it also tells us which rule would match and allow Outlook to run.
This is not just useful in confirming and increasing our confidence in the policy we are about to deploy, it can come in very handy later on, when we might need to troubleshoot why an application is being allowed or blocked. We will see how later!!!
As the name suggests, you can use this cmdlet to set the AppLocker policy. So, lets go and set the policy that we generated earlier.
That’s it! It is as simple as that!!!
Now for fun, let’s combine all the three previous examples in to one command line (rather than following each of the above steps separately).
So, in one line, we gathered AppLocker file information for each executable in Office12, generated a AppLocker policy and set it to the Local GPO (btw, it is just as easy to set this policy in to an existing domain GPO using its ldap path has a parameter). The “-Merge” option with Set-AppLockerPolicy allowed the rules to be merged with any existing rules applied previously. Cool, huh?
Troubleshooting with the Get-AppLockerPolicy & Test-AppLockerPolicy cmdlets
The Office12 policy (along with a default rule allowing everything under the Windows directory) has been deployed in enforcement mode. Since it is so easy to generate policies for applications that you want to allow, you keep incrementally adding rules for such applications. But now one of your colleague complains that he cannot use DVDMAKER.EXE. What do you do?
No worries! You can use Get-AppLockerPolicy and Test-AppLockerPolicy can be used in conjunction to answer why DVDMAKER is getting blocked. Here is how:
The Get-AppLockerPolicy retrieved the current effective policy and Test-AppLockerPolicy tested DVDMaker.exe against that policy. The reason why it was blocked is clear. Now you can decide whether to allow it or not.
That was a run down on AppLocker’s Powershell cmdlets. Hopefully, you will explore these and find them useful. If you decide to try AppLocker and these cmdlets, our suggestion would be to deploy AppLocker policies in audit mode first and leave the default rules untouched - allowing everything under Windows and allowing Administrators to run everything. Put your policies in enforcement mode only after you are comfortable that you have the right policy in place. And remember the appidsvc service must be enabled to actually enforce or audit your policies.
We are looking forward to your feedback. So, do keep them coming.
And this was just an introduction to some simple ways to get started with AppLocker cmdlets. There are lots of interesting solutions that can be put together to make “allow list” management simpler and cooler. So, stay tuned …
Arindam C. (AppLocker Feature Team)
By using the GUI, you can specify the "All files" by entering "*" in the folderpath. How do you specify the same critiera but from the cmdlet New-ApplockerPolicy or Set-ApplockerPolicy. I dont want to import it from an already existing .xml template, rather build the XML data from within a script. The one thing that we can specify is the "All files" feature from the cmdlets. Suggestions?
Where it says "But, it should be working like this." it was suppose to be "But, it shouldn't be working like this."
I see that you have moderated my comment. Could you just reply with a "Yes" or "No", if you'll do something about it? For you folks not to disclose what I previously wrote in the other comment, then I'd believe you're taking it serious enough?