Watch Demo×
×

See NinjaOne in action!

By submitting this form, I accept NinjaOne's privacy policy.

How to Create a Software Restriction Policy to Block Executables From AppData and Users’ Downloads folder

In today’s complex IT environments, maintaining the security of user environments is paramount. For IT professionals and Managed Service Providers (MSPs), one challenge is restricting the execution of potentially harmful executables that reside in locations like AppData or a user’s Downloads folder. Understanding this challenge, let’s deep dive into a powerful script solution to block executables from AppData and other designated locations.

Understanding Software Restriction Policies

Software Restriction Policies (SRP) is a feature of Windows that allows administrators to control which software can run on their computers. SRP can be used to block specific executable files, file extensions, or even entire directories.

When an executable file is executed, Windows checks the SRP settings to see if the file is allowed to run. If the file is not allowed to run, an error message will be displayed.

SRP is a powerful tool that can be used to help protect computers from malware and other security threats. However, it is important to use SRP carefully, as it can also block legitimate software from running.

The Disable-AppDataExe.ps1 Script

The Disable-AppDataExe.ps1 script is a PowerShell script that can be used to block executable files from running in the %AppData% and %UserProfile%Downloads directories. The script is customizable, so you can choose which file extensions to block and which directories to restrict.

#Requires -Version 5.1

<#
.SYNOPSIS
    Creates a Software Restriction Policy to block executables from AppData and a user's Downloads folder.
.DESCRIPTION
    Creates a Software Restriction Policy to block executables from AppData and a user's Downloads folder.
.EXAMPLE
     -RestrictedDirectory "%APPDATA%", "%UserProfile%Downloads"
    Creates a Software Restriction Policy to block executables from AppData and a user's Downloads folder. This is the default.
.EXAMPLE
    PS C:> Disable-AppDataExe.ps1 -RestrictedDirectory "%APPDATA%", "%UserProfile%Downloads"
    Creates a Software Restriction Policy to block executables from AppData and a user's Downloads folder. This is the default.
.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016 - DOES NOT SUPPORT WINDOWS 11
    Release Notes:
    Initial Release
    (c) 2023 NinjaOne
    By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
#>

[CmdletBinding()]
param (
    # Paths to block executions
    [Parameter()]
    [String[]]
    $RestrictedDirectory = @("%APPDATA%", "%UserProfile%Downloads"),
    # Executables
    [Parameter()]
    [String[]]
    $ExecutableTypes = @("ADE", "ADP", "BAS", "BAT", "CHM", "CMD", "COM", "CPL", "CRT", "EXE", "HLP", "HTA", "INF", "INS", "ISP", "LNK", "MDB", "MDE", "MSC", "MSI", "MSP", "MST", "OCX", "PCD", "PIF", "REG", "SCR", "SHS", "URL", "VB", "WSC")
)

begin {
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
        { Write-Output $true }
        else
        { Write-Output $false }
    }
}
process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }
    # Clear existing rules
    $BaseRegPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\safer'
    if (Test-Path "$BaseRegPath") { Remove-Item "$BaseRegPath" -Recurse }
    # Create our rule settings
    New-Item "$BaseRegPath"
    New-Item "$($BaseRegPath)\codeidentifiers"
    New-Item "$($BaseRegPath)\codeidentifiers\0"
    New-Item "$($BaseRegPath)\codeidentifiers\0\Paths"
    New-ItemProperty "$($BaseRegPath)\codeidentifiers" -Name 'authenticodeenabled' -Value 0 -PropertyType DWord
    New-ItemProperty "$($BaseRegPath)\codeidentifiers" -Name 'DefaultLevel' -Value 262144 -PropertyType DWord
    New-ItemProperty "$($BaseRegPath)\codeidentifiers" -Name 'TransparentEnabled' -Value 1 -PropertyType DWord
    New-ItemProperty "$($BaseRegPath)\codeidentifiers" -Name 'PolicyScope' -Value 0 -PropertyType DWord
    New-ItemProperty "$($BaseRegPath)\codeidentifiers" -Name 'ExecutableTypes' -Value $ExecutableTypes -PropertyType MultiString

    foreach ($Directory in $RestrictedDirectory) {
        $pathguid = [guid]::newguid()
        $newpathkey = "$($BaseRegPath)\codeidentifiers\0\Paths{" + $pathguid + "}"
        if ((Test-Path -LiteralPath $newpathkey) -ne $true) { New-Item $newpathkey }
        New-ItemProperty -LiteralPath $newpathkey -Name 'SaferFlags' -Value 0 -PropertyType DWord
        New-ItemProperty -LiteralPath $newpathkey -Name 'ItemData' -Value $Directory -PropertyType ExpandString
    }
    gpupdate.exe /force
}

 

How to Use the Script

To use the Disable-AppDataExe.ps1 script, you will need to have PowerShell installed and be running it with administrative privileges. Once you have the script, you can execute it by typing the following command at the PowerShell prompt:

.Disable-AppDataExe.ps1

The script will then block the specified executable files from running in the specified directories.

Final Thoughts

The Disable-AppDataExe.ps1 script is a useful tool for blocking executable files from running in specific directories. However, it is important to be aware of its limitations. By understanding how SRP works and how to use the script, you can help to protect your computers from malware and other security threats.

Here are some additional things to keep in mind when using the Disable-AppDataExe.ps1 script:

  • The script will only block executable files that are in the specified directories. It will not block executable files that are in other directories, such as the Program Files directory.
  • The script will not block executable files that are run from a command prompt or a batch file.
  • The script can be bypassed by users who have administrative privileges. (You may be interested in, how to disable local administrative privileges with PowerShell.)

NinjaOne can help IT professionals to seamlessly block executable files across an unlimited number of endpoints. NinjaOne is a cloud-based IT management platform that offers a variety of features for security, including the ability to create and deploy Software Restriction Policies (SRP). NinjaOne’s SRP feature is easy to use and can be customized to block executable files from running in specific directories, file extensions, or even entire applications. Additionally, NinjaOne’s SRP feature can be centrally managed, making it easy to scale up to an unlimited number of endpoints.

Here are some of the benefits of using NinjaOne to block executable files:

  • Seamless deployment: NinjaOne’s SRP feature can be deployed to endpoints without the need for individual installations or configurations. This makes it easy to deploy the policy to a large number of endpoints quickly and easily.
  • Centralized management: NinjaOne’s SRP feature can be centrally managed from a single console. This makes it easy to create, modify, and deploy SRP policies across all of your endpoints.
  • Flexibility: NinjaOne’s SRP feature is flexible and can be customized to meet the specific needs of your organization. You can choose to block executable files by directory, file extension, or even application.
  • Scalability: NinjaOne’s SRP feature can be scaled up to an unlimited number of endpoints. This makes it a great solution for organizations of all sizes.

Learn more about NinjaOne Endpoint Management.

Next Steps

Building an efficient and effective IT team requires a centralized solution that acts as your core service deliver tool. NinjaOne enables IT teams to monitor, manage, secure, and support all their devices, wherever they are, without the need for complex on-premises infrastructure.

Learn more about NinjaOne Remote Script Deployment, check out a live tour, or start your free trial of the NinjaOne platform.

Categories:

You might also like

NinjaOne Terms & Conditions

By clicking the “I Accept” button below, you indicate your acceptance of the following legal terms as well as our Terms of Use:

  • Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms.
  • Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party.
  • Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library belonging to or under the control of any other software provider.
  • Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations.
  • Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks.
  • Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script.
  • EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).