Security News Someone wrote a PoC on how to turn off Defender EDR using AppLocker (even when AppLocker is not active)

Khushal

Level 13
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
601
3,608
1,169
Threat actors could abuse AppLocker to deploy rules that will prevent EDR processes from execution in order to execute arbitrary commands and software on the asset without EDR disruption. Splunk identified a malware called “Azorult loader” back in 2022 that introduced this behaviour.
 
The core idea in that quote is real (malware has abused AppLocker to “impair defenses”), but the “prevent EDR processes from execution” part needs some important nuance.

What Splunk actually documented (Azorult loader)
Splunk’s write-up on “Azorult loader” shows it importing an AppLocker XML policy that adds deny rules for various security product components, using PowerShell (Import-Module AppLocker / Set-AppLockerPolicy -XMLPolicy). This is a legitimate defense-evasion pattern worth monitoring.
However, Splunk also references an important limitation: AppLocker generally can’t block (and may not even log) processes whose token includes NT AUTHORITY\SERVICE, which many AV/EDR “prevention” components use. In other words, this technique may block some userland components (UI, notification, helper processes), not necessarily the core protected/service components.

Practical limitations that matter in the real world
  • AppLocker only affects new process creation. If an EDR component is already running, a deny rule won’t retroactively kill it. A reboot / service restart is typically needed for “it won’t start again” impact (the iPurple article also notes this).
  • AppLocker enforcement depends on configuration. If AppLocker isn’t enforced (or the Application Identity service isn’t running / policies aren’t applied), deny rules won’t have the intended effect.
  • Impact varies by product architecture. Some EDRs can be meaningfully degraded if key user-mode services/helpers are blocked; others have strong self-protection/tamper protection and/or kernel components that still keep meaningful visibility and blocking.

Why defenders should still care
Even with the above constraints, importing AppLocker policy to target security tooling is a strong “impair defenses” signal (and it’s attractive to attackers because it can look like “normal Windows policy administration” rather than a blatant process-kill loop).

Defensive takeaways (high signal, low debate)
  • Monitor for AppLocker policy imports/changes (especially Set-AppLockerPolicy with -XMLPolicy) and changes under HKLM\SOFTWARE\Policies\Microsoft\Windows\SrpV2. (Splunk has published detections/hunting content for this.)
  • Forward and alert on AppLocker operational logs (notably the events generated when policies are applied and when executions are blocked).
  • Treat “deny rules targeting security agent binaries/paths” as high severity and investigate the policy source (local policy vs. GPO/MDM), author, and change time.
  • Harden who can modify application control policy (GPO security, admin delegation, change control), and ensure EDR tamper protection is enabled where available.

Conclusion
It’s accurate to say AppLocker can be abused to block some security/EDR components from launching, and Splunk’s Azorult analysis is a credible example. It’s not universally accurate that it can cleanly “prevent EDR processes” in general, because AppLocker has scope/identity limits (especially around SERVICE tokens) and only applies at process creation time.

Sources
 
From what I understood, attackers can use AppLocker to trip up some security programs 🛡️. It doesn’t mean they shut down the whole defense, but they can stop certain parts from starting properly. That already makes the system more vulnerable ⚠️.

It’s like putting a blindfold on the guard’s eye 👀: he’s still standing, but sees less… and anyone would take advantage of that slip.
 
  • Like
Reactions: Khushal
How attack is started is not described.
Does it need an ignorant user running some unknown command file as admin?
If yes, does the same scenario can apply to any other peer?
 
  • Like
Reactions: Khushal
Technical Analysis & Remediation
MITRE ATT&CK Mapping

T1562.001

Impair Defenses: Disable or Modify Tools.

T1562.002
Impair Defenses: Disable Windows Event Logging (Secondary effect).

T1112
Modify Registry (To enable AppIDSvc).

CVE Profile

Status

Feature Abuse (No specific CVE). Relying on legitimate administrative functions (Set-AppLockerPolicy).

Active Exploitation
Confirmed. Historically linked to Azorult loader; currently productized in "GhostLocker" PoC.

Live Evidence & Indicators of Compromise (IOCs) Based on the ipurple.team analysis, look for the following specific artifacts:

Service Modification
The AppIDSvc (Application Identity) service is normally set to Manual. GhostLocker forces it to Auto: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\AppIDSvc" -Name Start -Value 2.

Registry Artifacts
AppLocker rules are stored and enforced from: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2. Look for new subkeys under SrpV2\Exe containing rules with Action="Deny".

Targeted Processes (String Literals)
The PoC specifically scans for and blocks:

MpDefenderCoreService.exe

MsMpEng.exe

WinDefend.exe.

Event Logs

Event ID 8001

AppLocker policy applied successfully.

Event ID 8004
AppLocker blocked a file (This will flood logs if the EDR attempts to restart).

Remediation - THE ENTERPRISE TRACK (SANS PICERL)
Phase 1: Identification & Containment

Query AppLocker Status

Run PowerShell to check for active Deny rules targeting your security tools:

PowerShell
Code:
Get-AppLockerPolicy -Effective | Test-AppLockerPolicy -Path "C:\Program Files\Windows Defender\MsMpEng.exe" -User Everyone
If the result is Denied, the host is compromised.

Isolate
Move the host to a VLAN with strict egress filtering. Do NOT reboot the host yet if the EDR is still running; rebooting will trigger the block.

Phase 2: Eradication

Strip Malicious Policies

You must clear the AppLocker local policy. Note: This clears all local AppLocker rules.

PowerShell
Code:
Set-AppLockerPolicy -XMLPolicy '<AppLockerPolicy Version="1"><RuleCollection Type="Exe" EnforcementMode="NotConfigured" /></AppLockerPolicy>'
Alternatively, manually delete the SrpV2 registry keys if GPO allows.

Reset AppIDSvc
Set the Application Identity service back to Manual (Start=3) if your environment does not use AppLocker. Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\AppIDSvc" -Name Start -Value 3

Phase 3: Recovery

Force Update

Run gpupdate /force to re-apply legitimate domain-level AppLocker policies.

Validation
Reboot the host and confirm MsMpEng.exe starts successfully.

Phase 4: Lessons Learned

Detection Logic

Implement SIEM alerts for Event ID 8001 where the XML policy contains "Action=Deny" AND "MsMpEng.exe".

Hardening
Restrict Local Administrator rights strictly. This technique requires Admin privileges to modify the AppLocker policy.

Remediation - THE HOME USER TRACK

Priority 1: Safety (Scan & Verify)

Do not restart your computer if you suspect an infection until you have checked your security software status.

Open Windows Security. If it says "Managed by your administrator" or refuses to open, you may be affected.

Download a standalone scanner (like Microsoft Safety Scanner) to a USB drive from a clean computer and run it on the affected machine.

Priority 2: Restore Functionality
Open PowerShell as Administrator.

Run this command to clear local blocking rules
Remove-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\SrpV2" -Recurse -ErrorAction SilentlyContinue

Restart your computer.

Hardening & References

CIS Benchmark

Ensure 2.2.4 User Rights Assignment restricts "Debug programs" and "Load and unload device drivers" to Administrators only.

Defensive Strategy
AppLocker rules are additive. A local Deny rule merges with Domain Allow rules. Use Signed Binary enforcement in AppLocker to prevent untrusted code (like the GhostLocker executable) from running in the first place.

Sources

AppLocker Rules Abuse – Purple Team

Splunk Security Blog
 
How attack is started is not described.
Does it need an ignorant user running some unknown command file as admin?
If yes, does the same scenario can apply to any other peer?

Leaving aside Proof of Concept, almost none of the articles that various users bring to our attention in the forum describe the preliminary/initial stages that can lead to a PC infection.

If we hypothesize 10 access routes, the browser is involved in over 50% of cases.

In my opinion, it is pointless to try to understand the primary target attacked by malware.
At this stage, the PC is already partially compromised.
It is a matter of skill or luck (depends on the countermeasures put in place by the user) whether the infection does not progress successfully.

Ask any AI the question I wrote above.

Eliminate the routes of infection that are not possible in your case and therefore in the vast majority of users of forums like this one (installation of software that you do not suspect is malicious, phishing emails, etc.) and you will see that you are left with only one predominant route of possible PC compromise.

Which one?
 
Last edited:
How attack is started is not described.
Does it need an ignorant user running some unknown command file as admin?
If yes, does the same scenario can apply to any other peer?

The article is related to the Enterprise scenario. Such attacks (rarely) happened for years.
On Windows 11 Home/Pro fresh installations, the APPID service is enabled by default.
Simple infection chain at home (tested by me):
malicious URL ---> ZIP file ----> shortcut + DLL hijacking ---> UAC bypass + applying predefined AppLocker policy

No need to create any changes in the registry or use PowerShell. Deleting the AppLocker registry keys will not help to get rid of it (although this could help against the attack from the article).
The attack is quite similar and similarly effective as in the EDR challenge (instead of AppLocker, WDAC was used). I tested both two years ago. The attack via WDAC can be more destructive.
 
Last edited: