FaresMorcy
  • Whoami
  • Footprinting Labs
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Shells & Payloads
    • The Live Engagement
  • Password Attacks
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Active Directory Enumeration & Attacks
    • Active Directory Enumeration & Attacks
    • AD Enumeration & Attacks - Skills Assessment Part I
    • AD Enumeration & Attacks - Skills Assessment Part II
  • SOC Hackthebox Notes & Labs
    • Security Monitoring & SIEM Fundamentals Module
    • Windows Event Logs & Finding Evil Module
    • Introduction to Threat Hunting & Hunting With Elastic Module
    • Understanding Log Sources & Investigating with Splunk Module
      • Introduction To Splunk & SPL
      • Using Splunk Applications
      • Intrusion Detection With Splunk (Real-world Scenario)
      • Detecting Attacker Behavior With Splunk Based On TTPs
      • Detecting Attacker Behavior With Splunk Based On Analytics
      • Skills Assessment
    • Windows Attacks & Defense
      • Kerberoasting
      • AS-REProasting
      • GPP Passwords
      • GPO Permissions/GPO Files
      • Credentials in Shares
      • Credentials in Object Properties
      • DCSync
      • Golden Ticket
      • Kerberos Constrained Delegation
      • Print Spooler & NTLM Relaying
      • Coercing Attacks & Unconstrained Delegation
      • Object ACLs
      • PKI - ESC1
      • Skills Assessment
    • Intro to Network Traffic Analysis Module
    • YARA & Sigma for SOC Analysts Module
      • Developing YARA Rules
      • Hunting Evil with YARA (Windows Edition)
      • Hunting Evil with YARA (Linux Edition)
      • Sigma and Sigma Rules
      • Developing Sigma Rules
      • Hunting Evil with Sigma (Chainsaw Edition)
      • Hunting Evil with Sigma (Splunk Edition)
      • Skills Assessment
  • TryHackme SOC 1
    • TShark
      • TShark: The Basics
      • TShark: CLI Wireshark Features
      • TShark Challenge I: Teamwork
      • TShark Challenge II: Directory
    • Tempest
    • Boogeyman 1
    • Boogeyman 2
    • Boogeyman 3
  • TryHackme SOC 2
    • Advanced Splunk
      • Splunk: Exploring SPL
      • Splunk: Setting up a SOC Lab
      • Splunk: Dashboards and Reports
      • Splunk: Data Manipulation
      • Fixit
    • Advanced ELK
      • Slingshot
    • Threat Hunting
      • Threat Hunting: Foothold
      • Threat Hunting: Pivoting
      • Threat Hunting: Endgame
  • TryHackme Rooms
    • Investigating Windows
    • Splunk 2
    • Windows Network Analysis
  • Powershell Scripting Fundamentals
  • SANS SEC504 & Labs
    • Book one
      • Live Examination
      • Network Investigations
      • Memory Investigations
      • Malware Investigations
      • Accelerating IR with Generative AI
      • Bootcamp: Linux Olympics
      • Bootcamp: Powershell Olympics
    • Book Two
      • Hacker Tools and Techniques Introduction
      • Target Discovery and Enumeration
      • Discovery and Scanning with Nmap
      • Cloud Spotlight: Cloud Scanning
      • SMB Security
      • Defense Spotlight: Hayabusa and Sigma Rules
    • Book Three
      • Password Attacks
      • Cloud Spotlight: Microsoft 365 Password Attacks
      • Understanding Password Hashes
      • Password Cracking
      • Cloud Spotlight: Insecure Storage
      • Multipurpose Netcat
    • Book Four
      • Metasploit Framework
      • Drive-By Attacks
      • Command Injection
      • Cross-Site Scripting
      • SQL Injection
      • Cloud Spotlight: SSRF and IMDS
    • Book Five
      • Endpoint Security Bypass
      • Pivoting and Lateral Movement
      • Hijacking Attacks
      • Establishing Persistence
      • Defense Spotlight: RITA
      • Cloud Spotlight: Cloud Post-Exploitation
  • SANS SEC511 & Labs
    • Resources
      • Primers
      • References
      • Tools
        • Network
        • Elastic Stack
      • Printable Versions
    • Book One
      • Part One
      • Part Two
      • Part Three
    • Book Two
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Three
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Four
      • Part One
      • Part Two
      • Part Three Lab
      • Part Four Lab
    • Book Five
      • Part One Lab
      • Part Two Lab
      • Part Three Lab
  • CyberDefenders
    • XXE Infiltration Lab
    • T1594 Lab
    • RetailBreach Lab
    • DanaBot Lab
    • OpenWire Lab
    • BlueSky Ransomware Lab
    • Openfire Lab
    • Boss Of The SOC v1 Lab
    • GoldenSpray Lab
    • REvil Lab
    • ShadowRoast Lab
    • SolarDisruption Lab
    • Kerberoasted Lab
    • T1197 Lab
    • Amadey Lab
    • Malware Traffic Analysis 1 Lab
    • Insider Lab
    • Volatility Traces Lab
    • FalconEye Lab
    • GitTheGate Lab
    • Trident Lab
    • NerisBot Lab
  • Practical Windows Forensics
    • Data Collection
    • Examination
    • Disk Analysis Introduction
    • User Behavior
    • Overview of disk structures, partitions and file systems
    • Finding Evidence of Deleted Files with USN Journal Analysis
    • Analyzing Evidence of Program Execution
    • Finding Evidence of Persistence Mechanisms
    • Uncover Malicious Activity with Windows Event Log Analysis
    • Windows Memory Forensic Analysis
  • Hackthebox Rooms
    • Campfire-1
    • Compromised
    • Brutus
    • Trent
    • CrownJewel-1
  • WEInnovate Training
    • Weinnovate - Active Directory Task One
    • Build ELK Lab
      • Configure Elasticsearch and Kibana setup in ubuntu
      • Configure Fluent-Bit to send logs to ELK
      • Set up Winlogbeat & Filebeat for log collection
      • Send Logs from Winlogbeat through Logstash to ELK
      • Enable Windows Audit Policy & Winlogbeat
      • Elasticsearch API and Ingestion Pipeline
    • SOAR
      • Send Alerts To Email & Telegram Bot
      • Integrate Tines with ELK
    • SOC Practical Assessment
    • Lumma C2
    • Network Analysis
  • Build ELK Lab
    • Configure Elasticsearch and Kibana setup in ubuntu
    • Configure Fluent-Bit to send logs to ELK
    • Set up Winlogbeat & Filebeat for log collection
    • Send Logs from Winlogbeat through Logstash to ELK
    • Enable Windows Audit Policy & Winlogbeat
    • Elasticsearch API and Ingestion Pipeline
  • Build Home Lab - SOC Automation
    • Install & configure Sysmon for deep Windows event logging
    • Set up Wazuh & TheHive for threat detection & case management
    • Execute Mimikatz & create detection rules in Wazuh
    • Automate everything with Shuffle
    • Response to SSH Attack Using Shuffle, Wazuh, and TheHive
  • Home Lab (Attack & Defense Scenarios)
    • Pass-the-Hash Attack & Defense
    • Scheduled Task Attack & Defense
    • Kerberoasting Attack & Defense
    • Kerberos Constrained Delegation
    • Password Spraying Attack & Defense
    • Golden Ticket Attack & Defense
    • AS-REProasting Attack & Defense
    • DCSync Attack & Defense
  • Home Lab (FIN7 (Carbanak Group) – Point of Sale (POS) Attack on Hospitality Chains)
  • Home Lab (Lumma Stealer)
Powered by GitBook
On this page
  1. SANS SEC511 & Labs
  2. Book Four

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:

  1. Configure AppLocker to trust Microsoft-signed executables, and also enable the default rules

  2. Configure executable enforcement in audit mode

  3. 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

  4. 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

  5. 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.:

sc.exe start appidsvc

Next, let's run the local security policy editor (secpol.msc) that allows us to manage and configure security-related settings and policies:

secpol.msc

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:

Get-WinEvent @{logname="Microsoft-Windows-Applocker/EXE and DLL";} | ogv

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.

C:\labs\putty.exe
Get-WinEvent @{LogName="Microsoft-Windows-Applocker/EXE and DLL";} | ogv

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.

copy C:\labs\putty.exe C:\windows\System32
C:\Windows\System32\putty.exe
Get-WinEvent @{LogName="Microsoft-Windows-Applocker/EXE and DLL";} | ogv

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.

C:\windows\System32\putty.exe
Get-WinEvent @{logname="Microsoft-Windows-Applocker/EXE and DLL";} | ogv

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.

C:\windows\System32\putty.exe
Get-WinEvent @{logname="Microsoft-Windows-Applocker/EXE and DLL";} | ogv

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:

  1. C:\Windows\system32\putty.exe

  2. C:\labs\pscp.exe (Putty Secure Copy, signed by the same vendor as putty.exe).

C:\windows\System32\putty.exe
C:\labs\pscp.exe
Get-WinEvent @{logname="Microsoft-Windows-Applocker/EXE and DLL";} | ogv
PreviousPart TwoNextPart Four Lab

Last updated 5 months ago