Arbitrary File Delete to SYSTEM (Emsisoft Antivirus)

Introduction

Back in August last year, I decided to take a closer look at lesser-known antivirus vendors after reading an excellent ZDI post discussing the rise of link-following vulnerabilities. That article made me wonder: if this bug class is so easy to find and exploit, surely major AV vendors are well-aware and protected, right?

Turns out, that’s not always the case. In this blog post, I’ll walk through a Local Privilege Escalation (LPE) vulnerability I discovered in Emsisoft Antivirus, which allowed me to escalate to NT AUTHORITY\SYSTEM via arbitrary file deletion.

Finding Targets

My initial step was simple: map out antivirus vendors using search engines and shortlist those I hadn’t encountered much before. Emsisoft stood out.

Google results when searching for antivirus vendors

Before diving into installation, trials, and VM setups, I did a quick CVE search to see which vendors had the fewest public disclosures. Emsisoft had very few, so I decided to start my testing there.

Hunting for Link-Following Vulnerabilities

To identify potential link-following vulnerabilities, I followed this process:

1. Target applications with elevated privileges — ideally, those performing file operations.
2. Monitor file activity using Procmon to log file I/O and behavior.
3. Check access control — ensure the file operations occur in user-writable locations.
4. Look for sensitive actions, especially:
   • File create, copy, move, rename, delete
   • Modifying folder DACLs
5. Analyze security checks — determine if the application blindly trusts symlinks or junctions.

Local Privilege Escalation in Emsisoft Antivirus

Like most AV software, Emsisoft allows users to quarantine or permanently delete detected files via the GUI. Interestingly, I found that when a file is deleted from the UI, it’s not moved to a temporary directory, nor is it locked — the software simply references its full path and deletes it.

Naturally, I fired up Procmon to validate this behavior.

Procmon log showing a2service.exe deleting files as SYSTEM

As shown above, a2service.exe — running as NT AUTHORITY\SYSTEM — is responsible for the deletion.

I tested what would happen if I deleted the flagged file and replaced it with a junction pointing to another location (e.g., C:\), using the same filename. The result? Arbitrary file deletion as SYSTEM — a perfect candidate for privilege escalation.

Exploitation Flow

Here’s the exploit chain:

1. Create a folder on the user’s Desktop.
2. Place a “malicious” file in it (use a name matching a critical file or directory).
3. Scan the folder using Emsisoft AV — the file gets detected.
4. Replace the folder with a junction to C:\.
5. In the UI, choose to quarantine or delete the detected file.

6. Behind the scenes, leverage the MSI rollback LPE method, as described by Abdelhamid Naceri:

   • Set an oplock on C:\Config.Msi
   • Wait for the deletion to trigger the oplock
   • Move a file and install an MSI package, racing to overwrite the rollback script
   • If successful, the overwritten .rbs script executes and spawns a SYSTEM shell

Exploit Demo

Here’s the exploit in action:

Conclusion

This vulnerability highlights how even lesser-known AV products can harbor serious privilege escalation bugs — especially when link handling is done naively. If you’re working in vulnerability research, AV software remains a rich hunting ground, and it’s worth checking out what happens when SYSTEM blindly trusts user-controlled paths.

---

Disclosure was made responsibly to Emsisoft, and the issue has been addressed in a recent update.