Scaling AppLocker - Managing it AFTER Deployment!

When working on limiting outbound access to the internet by application with Windows Firewall with Advanced Security I kept running into a key shortcoming - introducing a new or previously unknown application to the system allowed bypasses to firewall rules when using a blocklist configuration. A pre-defined allow configuration of outbound traffic with WFwAS is difficult or nearly impossible to scale, so it wasn't going to solve the problem by itself. WFwAS can do a great job of limiting web access for pre-defined applications in common locations, but it is difficult to use it when there are new applications introduced into folders with different or random path names on thousands of machines. The lack of wildcards or user variables in the path of an application in a rule means that many applications that use the internet could not be managed in a practical manner for more than a small number of machines.

This is one area that an application control policy can help quite a bit. An application control policy can limit newly introduced applications to only those that are trusted (more or less) to behave or have limited abilities to interact with the web programmatically, helping mitigate some of the gaps left by WFwAS. The best bet for a strong security posture on Windows workstations is to use Windows 10 with all of the great mitigations that come with it. For example, Device Guard can be deployed as a very effective deterrent to malware, and many people who are much more knowledgeable than me have discussed it in depth. But what if Device Guard isn't available or isn't enough? There is still a strong case for using AppLocker in many environments, either alone (not as good as Device Guard but better than nothing) or as a more granular supplement to Device Guard.

There is quite a bit of documentation from Microsoft, as well as help on several blogs, with information on how to create an initial AppLocker policy. If you are looking for a place to start, here is a great reference resource; there are many others out there: https://docs.microsoft.com/en-us/windows/device-security/applocker/applocker-overview

A lot of the documentation and blogs discuss creation of an AppLocker policy using a gold image and then pushing it out in a manner that enforces this gold image. It is a good practice and definitely the way to get the most benefit from AppLocker...

...but what about deploying it to a large number of already existing machines that were built over a long period of time with different images of various metallurgic constitutions? What if AppLocker has to be deployed (maybe quickly) into an environment that already has accumulated years of bad habits and many applications that aren't even remotely accounted for by the gold image?

There are a few things that can help make this happen.

1. Have a clear plan on what to accomplish with AppLocker (see previous link to AppLocker Overview from Microsoft)
2. Have a method of centralizing and analyzing AppLocker audit logs, such as Windows Event Forwarding (WEF). https://social.technet.microsoft.com/wiki/contents/articles/33895.windows-event-forwarding.aspx
3. Create a candidate policy based off of a gold image and best practice recommendations.
4. Test the candidate policy against a representative group in audit mode.
5. Adjust the policy as necessary using audit logs to inform of blocked files or applications.
6. Apply the policy in an audit configuration to the whole organization.
7. Adjust the policy as necessary based off of the audit logs.
8. Train IT staff and end users on what to expect when the policy is enforced.
9. When auditing and training is at an acceptable level, enforce the policy.
10. Continue to adjust policy as needed when something is blocked that should be allowed using enforcement logs.
11. Continue training.

Sounds pretty straightforward, right? But when I tried this I kept having problems on the steps requiring that the policy be adjusted. When I initially rolled it out I knew of two ways to create an exception to adjust the policy.

1. Obtain a copy of the application installer and install it on a test machine. Collect all related installer, exe, script, and/or DLL files and use the GPO editor or PowerShell to create new rules.
2. Copy installer, exe, script, and/or DLL files from a production machine that already has the application installed and use the GPO editor or PowerShell to create new rules.

This worked well when going through the initial deployment, but as the deployment moved from a few machines to a few hundred to thousands these two methods of updating policies didn't scale. The biggest issue was with application installations or updates that executed files or scripts from a temporary location (which would be blocked) and then removed the files from that temporary location when the installation didn't complete. Many of these were triggered by automated update processes that were difficult or time consuming to manually trigger on a test machine. By the time a notification was generated and someone was able to investigate on a production machine the file was already deleted by the installer. Even without those problems, the sheer volume of blocks and time it took to retrieve the files or install them on a test machine to create rules made it difficult to deploy to the entire organization.

In all of the research I did I couldn't find anything that indicated how to solve this problem. All of the guides I had read talked about what to do once I had a local copy of a file, but all I had was a log entry indicating that something had been blocked. I didn't have access to the file, or it took too long to get it, or there were too many.

After a fair amount of researching and frustration I finally found this gem in the Get-AppLockerFileInformation cmdlet documentation:

"The Get-AppLockerFileInformation cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields."

 source: https://technet.microsoft.com/en-us/library/ee460961.aspx, emphasis added

The log entry turned out to be the key to solving the problem - and it was staring me in the face the whole time! If I could retrieve the file information from the event log, I could then pipe it into the New-AppLockerPolicy cmdlet and create rules based off of the logs that were already being centralized. This allowed policy modifications for files even if I no longer had access to the file - as long as I had the audit or prevention log event - which meant it could much more easily scale to a full deployment.

Here is a link to some example snippets of code: https://github.com/limpidweb/applocker/blob/master/applocker_ps_examples-1

These can be used as part of a much larger script to help automate some of the more tedious tasks in making AppLocker policy changes, such as version control, partial match searching, policy backups, change control, etc.

Hope this helps! Now to start planning a new post...

Until then, work hard and spend time with your family.
Branden
@limpidweb

What to do about SMB...

So, how busy were you patching after the worm outbreak last month? Hopefully not very busy - hopefully you had MS17-010 patched in March soon after it was released. Unfortunately it appears that many did not, which begs the question, "Why not?". I am sure there are many reasons - I have heard many of them myself in almost every organization I have worked for. So what to do about SMB now that we have seen this worm and others actively taking advantage of unpached systems? Few mitigations are as good as applying the patch. Please patch quickly and thoroughly! Another good option is to stop using SMB1 - although there are still issues with SMB2 that also need to be patched.

But what can be done if none of these are options? What if you need SMB, but machines can't be patched, or they could be patched but can't be rebooted... because of uptime requirements, or business criticality, or the moon is made out of cheese, or whatever other bad reason for not patching exists... another mitigation option is to block SMB with a firewall. For SMB worms, blocking SMB at the edge of your network and through VPN tunnels is a great start, but what if it gets inside the network through some other form? As long as none of the end users execute untrustworthy email attachments or browse the internet while using a local admin account then things are fine. 😉 For discussion sake let's just say there is a very remote chance that these (or other) SMB exploits cold run on an internal machine on some hypothetical network somewhere. Once the worm is in, the fact that it is remotely exploitable means that it can spread to other systems quickly and have a wide impact if not mitigated internally as well.

One way to stop the risk from unpatched (or unknown vulnerable) systems on the network is to use an endpoint firewall to block the service where it is not needed. For example, almost all workstations need SMB enabled outbound when they are acting as a client, especially to things like domain controllers, file servers, and print servers. But how many things really need inbound access SMB shares on workstations? There are a few use cases I could think of, but not many. For example, many admin functions that require SMB inbound to a workstation could be limited to hardened jump boxes or severs. Blocking SMB access from a workstation to other workstations can also have a substantial benefit - things like making workstation to workstation pivoting much harder. This is a micro implementation of that old adage of network segregation/zones, and there is a lot of benefit from blocking just this one protocol.

So if this can help us limit the risk to workstations, how can we limit risk to our servers? Important servers like domain controllers, file servers, and print servers often require SMB and should always be allowed; because of that they should be prioritized to be patched quickly. Outside of these, many servers don't need SMB so it can be turned off, or if a small amount of SMB is needed it can be allowed for just some devices and the rest can be blocked with inbound rules on their endpoint firewall.

If there are servers that can't have the endpoint firewall deployed or SMB service disabled, another option is to create an outbound rule in Windows Firewall with Advanced Security on as many workstations as possible to block traffic destined to SMB ports on devices that are known to be vulnerable. This isn't guaranteed to stop malicious activity, the firewall could potentially be disabled or the initial infection could be from a device without an outbound firewall. But if it is pushed out via GPO many of the highest risk machines could stop most automated infection vectors, which is better than nothing. If there is a similar scenario like this in the future with SMB or another protocol, the same mechanism could be deployed to protect vulnerable devices as a temporary protection until patching/rebooting could kick in.

Here is what an outbound rule to protect other vulnerable devices could look like (high level):

1. Have outbound block rules with inverse blacklists for commonly abused applications (like I have covered in previous posts - especially for powershell.exe and mshta.exe)
2. Configure an outbound block rule for protocol TCP/445 (SMB), and use inverse ranges to exclude (go around) servers/devices that have been patched and restarted (preferably things like Domain Controllers, Print Servers, File Servers, etc. that are patched quickly - I do not recommend blocking these). This would be similar to the inverse ranges configured for applications as discussed in previous posts, the difference for this rule would be to allow for Any application, and then specify a protocol, and this time the "skipped" IPs would likely be on an internal network instead of the internet.
3. Have the default action be Allow.

As devices are patched the inverse list can be modified to "go around" them, allowing traffic to them but blocking other devices that are not patched. In the case of an infection the initial point of entry would be lost, and in many cases accessible file shares could be encrypted (in the case of ransomware), but this could stop the worm from spreading to other workstations or servers that would be vulnerable. This could limit the damage significantly, and instead of having a shutdown of all devices could just be a file restore for the affected shares and workstation re-deploy for the initial infection.

This could be used for other protocols/ports, it certainly would not be limited to SMB. Hopefully there would be enough warning to configure this and push it out to all devices before a new attack hit. A better scenario would be to proactively enable WFP audit logs, forward them to a central location, and analyze them to come up with a proactive list of outbound protocol access to many popular services and only allowed for the destinations that really need them. Here is possible list of places to start - except for really common ports like 80 and 443. If this could be configured and deployed before something was released the chances of having it spread on your network would be much lower. There is also the added (marginal) benefit of becoming aware of when someone is trying to use a new service without going through proper channels. Maybe that server admin wasn't authorized to install MySQL, or maybe that server (or workstation!) wasn't supposed to have a file share or SMTP services configured on it. With something like this in place, the workstations couldn't connect to it without the rules being reconfigured... which provides an opportunity for discussion of securing and managing this new app before it is deployed to production.

I hesitated to publish this, I still recommend patching as quickly as possible, but I hope that this post shows creative ways that the Windows Firewall with Advanced Security can be used to quickly block a specific risk without the risks of deploying a full workstation firewall allow list.

As hinted before I have some interesting things in the works for AppLocker. The hard part is done and now I am polishing it up, I hope to have it published in my next post.

Until then, work hard and spend time with your family.
Branden
@limpidweb