Part Three Lab
Lab 4.3 - Applocker
Objectives:
Use and understand application control
Configure AppLocker to trust executables: First in audit mode Then in block/enforce mode
Detect the following AppLocker events:
Audit mode events
Enforce/block mode events
Challenge:
Reconfigure AppLocker to trust executables. Perform the following steps:
Configure AppLocker to trust Microsoft-signed executables, and also enable the default rules
Configure executable enforcement in audit mode
Run C:\labs\putty.exe, view the AppLocker event logs, and investigate why it was trusted
Remove the default rule that disables trusting all executables for Administrators
Re-run C:\labs\putty.exe, and view the AppLocker event logs
Copy C:\labs\putty.exe to C:\windows\System32
Run C:\windows\System32\putty.exe, and view the AppLocker event logs
Remove the default rules that trust executables in the 'Program Files' and 'Windows' folders
Re-run C:\windows\System32\putty.exe, and view the AppLocker event logs
Temporarily configure AppLocker in executable enforce/block mode
Re-run C:\windows\System32\putty.exe, and view the AppLocker event logs
Let's start the Application Identity Service (appidsvc) because it manages application control policies, including AppLocker.:
Next, let's run the local security policy editor (secpol.msc) that allows us to manage and configure security-related settings and policies:
From the Application Control Policies, we'll select AppLocker, scroll to "Overview," and click "Executable Rules":
Let's create a rule to trust Microsoft-signed executables. In the process, AppLocker will suggest enabling the "Default Rules," which also permit the following executables to run:
Everyone: All files in the Program Files folder
Everyone: All files in the Windows folder
BUILTIN\Admin: All files
All three rules carry potential risks. The first two rules trust not only the current programs in the 'Program Files' and 'Windows' folders but also any files added there later, including possible malware. The third rule removes restrictions on trusting executables run by administrators (and the student account is an administrator). We’ll temporarily enable these rules to demonstrate their risks and then implement stricter configurations.
Let's allow Microsoft-signed binaries to run from any location on the filesystem. This ensures that Microsoft-signed software outside the 'Program Files' and 'Windows' folders can execute, and supports running all Microsoft-signed software once we start tightening the default rules. We 'll start by right-click "Executable rules" in the left panel and select "Create New Rule"
Then click"Next"
Press "Next" again:
Then we'll click "Next" on the "Conditions" screen, and select "Browse" and navigate to Program Files > Windows Defender > MpCmdRun (Microsoft Malware Protection Command Line Utility, signed by Microsoft). Click "Open."
Note: Browse for a signed file to use as a reference for the rule. Use the slider to select which properties define the rule; as you move down, the rule becomes more specific. When the slider is in the any publisher position, the rule is applied to all signed files.
Next, let's move the blue arrow to "Publisher" and click "Create."
Then press "Next" and click "yes":
Microsoft utilizes multiple code-signing certificates, so let's add one more. We'll follow the same process we just completed. First, let's create a new rule, then click "Next" on the following three screens. Then, navigate to C:\Windows\explorer.exe, move the blue arrow up to "Publisher," and click "Create."
Next, let's enable AppLocker audit mode. We need to click on AppLocker, then select "Configure rule enforcement."
Note: Audit Mode allows administrators to monitor which applications would be blocked by AppLocker rules without actually enforcing the blocks. This is helpful for testing and evaluating the potential impact of your AppLocker rules before enforcing them.
We need to verify that AppLocker is active and logging. To do this, let's run cmd.exe, which will trigger AppLocker alert 8002 ("…CMD.EXE was allowed to run").
Next, let's enter the following command in our PowerShell window:
Let's run putty.exe, a trusted SSH client located in the C:\labs folder (note that it's not in the 'Program Files' or 'Windows' directories).
Let's close the program. Then, review the AppLocker logs again.
The application "putty.exe" was allowed to run, even though it was not located in the 'Program Files' or 'Windows' folders. This occurred because the student account has administrator privileges, and AppLocker is currently disabled for administrators. We need to update the settings to ensure that AppLocker policies apply to administrators as well.
Let's return to the Local Security Policy Editor (secpol.msc) and select "Executable Rules."
Let's right-click the rule for the user "BUILTIN\Administrators" and select "Delete." Confirm by clicking "Yes" in the pop-up window.
Let's run C:\labs\putty.exe again to confirm that it is no longer trusted.
The AppLocker event for putty.exe changed from 8002 ("...was allowed to run") to 8003 ("...PUTTY.EXE was allowed to run but would have been blocked if AppLocker policies had been enforced").
We are currently trusting all executables in the 'Program Files' and 'Windows' folders. Let's copy the file C:\labs\putty.exe to C:\Windows\System32, execute it, and review the resulting AppLocker event.
PuTTY is considered trusted because it was copied to the C:\Windows\System32 directory. However, this also means that malware could potentially exploit the same location.
Let's remove the two rules that allow executables in the 'Program Files' or 'Windows' folders. After that, we'll run C:\windows\System32\putty.exe again and check the AppLocker events.
Let's run C:\windows\System32\putty.exe again and view the AppLocker events.
It appears that C:\windows\System32\putty.exe is no longer trusted.
Let's temporarily enable enforce mode for testing purposes. We will only enable it for a short period, as other executables, like Chrome, are not currently trusted.
Let's open the Local Security Policy Editor (secpol.msc), navigate to AppLocker, and click on "Configure rule enforcement"" again.
Let's run C:\windows\System32\putty.exe again and view the AppLocker events.
Error: Program 'putty.exe' failed to run: This program is blocked by group policy. For more information, contact your system administrator
The AppLocker events show that putty was blocked.
Let's switch back to audit mode to allow other executables, like chrome.exe, that are not currently trusted to run. Then, we'll add chrome.exe and putty.exe to the trusted list.
To do this, let's open the Local Security Policy editor (secpol.msc), go to AppLocker, and click on "Configure Rule Enforcement."
Then, let's create a new rule.
We will trust the publisher of C:\Windows\System32\putty.exe. This trust will extend to both the putty.exe file and its copy on C:\labs\putty.exe, as well as any updates to putty.exe signed by the same publisher. Additionally, any other software signed by the same publisher, such as C:\labs\pscp.exe, will also be trusted.
Let's click "Next" on the next three screens. Then, we'll navigate to C:\Windows\System32\putty.exe, move the blue slider to "Publisher," and click "Create."
Let's perform the same steps for the file located at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe:
Finally, let's click the Chrome icon on the taskbar, then run the following files:
C:\Windows\system32\putty.exeC:\labs\pscp.exe(Putty Secure Copy, signed by the same vendor as putty.exe).
Last updated
