# Masking Your Base Image With FSLogix

This post will describe the process of using FSLogix App Masking to hide the core set of tools and utilities that an attacker will try to gain access to in order to exploit your platform.

This will need testing before you implement this into production.

### Overview

I presented at the UK Citrix User Group recently on 10 Quick Wins for Red Team Testing and one of the subjects I covered was hiding base applications from the users when they do not need access to them.

Now, I know there are a host of tools to do this and that some are better than others (think application whitelisting) but what if there was a quick win? One that may not stop all attacks but will prevent the majority of internal users (yes, not all attacks are external) from even seeing PowerShell, Ping, FTP and a whole host of applications even being installed on your platform.

Enter FSLogix, specifically FSLogix App Masking.

When many hear FSLogix, they immediately think “ahh, yeah the profile tool” but there is another tool in your arsenal, Application Masking.

This post is not intended to give you an “all-in” look at App Masking and what it can do, if you want that then look here but what this will do is show you how to hide common apps that are not required from your standard users to enable a more secure platform.

### What Is App Masking?

According to Microsoft Application Masking manages access to an application, font, printer, or other items. Access can be controlled by user, IP Address range, and other criteria. Application Masking significantly decreases the complexity of managing large numbers of gold images.

Normally this is what it is used for, a group of users “Word Users” for example get access to the installed copy of Word. If you are not in that group then FSLogix App Masking “hides” that application. That’s it, gone, like It’s not even installed.

I am not going to claim to be clever enough to understand how all of this works under the hood, but, if we applied the same principle to a master image then we could in theory “hide” system applications we don’t want users to have access to but leave them there for the Administrators. This can be done at image creation or even applied to an existing image making retro fitting this easy!

### Installation

The first thing you will want to do is install the FSLogix product set onto your master image. You can download FSLogix from here and just extract the ZIP file onto your master image.

#### FSLogix Apps

Run the FSLogixAppsSetup.exe file

Click to agree to the licensing and click install

#### FSLogix Apps Rule Editor

Run the FSLogixAppsRuleEditorSetup.exe file

Click to agree to the licensing and click install

I normally install the Rule Editor onto the master image in order to be able to select files, folders and registry keys from the platform that the users will be operating from. You can remove this if required once the rules are set up

### Rule Configuration

Once the software is installed on your master image open up FSLogix Apps RuleEditor from the Start Menu

Click on New to create a new rule and save it to a location you can copy the 2 files from later (in my case I am putting it on the desktop)

You will notice 2 files get created, you will need both of these to implement the rule later. One is the rule definition and the other is the assignments.

Select to create a Blank Rule Set and click OK

Right click in the right-hand pain and select New Rule

Select Hiding Rule and click Browse

Select to browse for a file

Locate the PowerShell executable from the pop-up window that appears

Click OK and select Yes to the system instability warning

Repeat this process for all the programs you want to hide from your users. Below are the programs and printers that I normally add

#### Hiding Rules I Add

ProgramReasoning
powershell.exePowerShell - the bain of my life with regard to security
powershell_ise.exeSee above!
ftp.exeCan pipe commands via FTP to the command prompt
fsutil.exeCan be used for an Applocker Bypass
cmd.exeNot required for end users Be careful if you have login scripts
ping.exeAlso not required by end users
reg.exeRegistry manipulation
regedt32.exeMore registry manipulation
regedit.exeYet more registry manipulation
regsvr32.exeNot required by end users
PrinterReasoning
FaxReally !?!
Microsoft Print to PDFNormally use other tools
Microsoft XPS Document WriterNot required

#### Hiding Rules As Per Microsoft

Now, Microsoft have been kind enough to provide a list of applications that attackers could potentially use to bypass AppLocker or Windows Defender Application Control. You can find this list below

https://learn.microsoft.com/nb-no/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules

This is their take on it

Members of the security community* continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass WDAC.

With that in mind I tend to add the relevant applications provided by Microsoft to by rule set to prevent internal users accessing these.

Please note that EACH ENVIRONMENT DIFFERS, you will have to test this prior to releasing it into production, or you could break lots of your VDA’s. Check on each exe file and see if it is feasible to implement in your environment. Test, test and test some more and if you don’t, well, that’s your own fault then!

Once you are done you should have a fairly robust rule base as you can see below

Next you will need to deal with the assignments, this is who this rule applies to, and also who it does not!

Click on Manage Assignments and remove Everyone from the list. Then add Domain Users and select Rule set does apply to user/group and also add BUILTIN\Administrators and select Rule set does not apply to user/group

Click to save the rule and close the rule editor.

### Deployment

To deploy your new rule you will need to copy both files to the following location on all your VDA’s

This can be done with a start-up script, part of the image seal process or a whole host of other options, that’s up to you.

### Testing

First let’s test as an Administrator to make sure that everything still works as expected

As you can see PowerShell still works

As does ping

So, let’s switch to a standard user

You can see that Windows can’t even see that a registry editor is installed now, if you try and run it, nothing happens

The same with Windows PowerShell

So, let’s try and run the PowerShell file directly from the file system

As you can see, it’s not there, FSLogix App Masking is doing its job and “masking” those files we defined earlier from the user.

### Conclusion

Now I know that there are plenty of smart people out there who may be able to bypass this with all the tools they have available to them. But, if you consider that quite a bit of breakout is done internally by your standard users this is a pretty good win.

It does not take a lot to set up, does not cost much and can immediately add a layer of security between your users and the base operating system you are deploying to them.