AppLocker Application Would Have Been Blocked
Detects when AppLocker "Audit only" enforcement mode reports that an Application, DLL, Script, MSI, or Packaged-App would have been blocked if AppLocker "Enforce rules" enforcement mode was enabled. This rule triggers on the AppLocker audit events and requires review of the reported path against the local AppLocker policy. Since this rule triggers solely on event IDs without path-based filtering, tuning and false positive suppression must be handled at the AppLocker policy level by the policy author, not via Sigma filters. Analysts should review the reported FullFilePath and correlate with the local AppLocker policy to determine whether the activity is expected or warrants investigation.
Convert In Phoenix Studio
Open this Sigma rule in the converter with the YAML preloaded and ready for backend selection.
detection:
selection:
EventID:
- 8003 # EXE and DLL would have been blocked
- 8006 # MSI and Script would have been blocked
- 8021 # Packaged app execution would have been blocked
- 8024 # Packaged app deployment would have been blocked
# Common FP examples (environment-specific, handle at AppLocker policy level):
# filter_main_fp_examples:
# FullFilePath:
# - 'C:\Windows\system32\VERSION.dll'
# - 'C:\Windows\SYSTEM32\WINNSI.DLL'
# - 'C:\Windows\SYSTEM32\NetSetupEngine.dll'
# - 'C:\Windows\uus\AMD64\uusbrain.dll'
# - 'C:\Windows\SYSTEM32\ImplatSetup.dll'
# - 'C:\Windows\System32\bcrypt.dll'
# - 'C:\Windows\SYSTEM32\NETAPI32.DLL'
# - 'C:\Program Files\SplunkUniversalForwarder\bin\VCRUNTIME140.dll'
# EventID: 8003
condition: selectionExpected during AppLocker policy testing and audit mode deployments
Legitimate system DLLs and applications not yet covered by the AppLocker policy (e.g. Windows system components, third-party software). False positives must be handled at the AppLocker policy level by the policy author, not via Sigma filters.