Honeypot Tales: The EDR That Just Wouldn’t Die

Welcome to “Honeypot Tales” an ongoing series of posts by our Director of Incident Response, Tyler Hudak, sharing stories from the front lines of cybersecurity. 

In our last post, we described how a honeypot with Remote Desktop Protocol (RDP) exposed to the Internet was compromised and how the attacker deleted our triage files while we were still collecting them. 

That honeypot was monitored with SentinelOne, one of our endpoint detection and response (EDR) tools. In this post, we’ll give you a fascinating look into how attackers try to remain undetected and let their tools run unimpeded by removing these endpoint protections from compromised systems. 

The Attacker vs. SentinelOne 

Once inside the honeypot, our attacker immediately noticed that SentinelOne was running. But rather than backing off, they quickly went on the offensive, trying four different methods to disable or uninstall it. 

Spoiler Alert: SentinelOne was configured to require approval before any uninstallation, which ultimately prevented them from succeeding.  

Here’s how it went down: 

Method 1: Standard Uninstall 

The attacker first tried to uninstall the EDR using SentinelOne’s removal program, most likely through Windows' Add/Remove Programs. This was confirmed through several forensic artifacts, including the RecentApps registry key under the attacker-created System32 user account.  

 

Method 2: Third-Party Tools 

With the uninstall program not working, the attacker downloaded and ran Revo Uninstaller, a third-party utility that’s designed to uninstall programs that are difficult to remove. This failed to remove the agent due to the approval requirements.  

 

Not giving up, they made another attempt by downloading and running SuperF4, a third-party utility that’s designed to kill stubborn or protected processes. This also failed to terminate SentinelOne. 

 

Method 3: PowerShell Process Termination 

When third-party tools didn't work, the attacker moved to using PowerShell. Inside System32’s ConsoleHost_history.txt file, Windows' PowerShell history log, we found commands that attempted to stop SentinelOne's process using Stop-Process. 

 

Method 4: Command Line with net stop 

With no other methods working, the attacker turned to traditional Windows service control methods. They attempted the net stop command to shut down the SentinelOne service. Like all previous attempts, this also failed. 

 

 

Other Methods 

While the methods used above on our honeypot are common, they aren’t the only ones we’ve seen attackers use.  

Common EDR, like Windows Defender, have multiple methods to disable them and some attacker tools have them coded in. When this fails, the Inversion6 Incident Response Team has also seen attackers escalate their tactics and load kernel-level debuggers to unload drivers and modules from memory or even use dedicated tools to killing EDR. 

Detection and Analysis Methodology 

Even though this was a honeypot and we wanted it to be hacked, we still monitored the system in the same way we watch client systems—including the use of SentinelOne to watched for any alerts or anomalous activity.  

In this case, the attackers weren’t particularly quiet. 

 

As we began our information gathering, triage tools were run on the system to collect artifacts and began our forensic analysis.  

Any forensic examination we perform is done with prioritized goals in mind to ensure we are focused and not straying off into unneeded areas. We use tools like CyberTriage to automate our initial examination, and then go back with best of breed tooling like RegRipper to enhance our findings and dig deeper. 

In this case, our analysis methodology gave us a clear timeline of how the attacker repeatedly tried and failed to disable endpoint security. 

Lessons Learned 

In this case, we saw an attacker doing whatever they could to remove endpoint visibility and protection. This case study is a strong reminder that defense-in-depth is not optional. 

Here are the key lessons from this incident: 

• Monitor for EDR agents going offline. Unexpected shutdowns or uninstall attempts should be investigated immediately. 

• Require approval for agent uninstalls or disablements. This setting was the key factor that protected SentinelOne on our honeypot. 

• Attackers are persistent. They don’t try just one method. In cases I’ve worked, I’ve seen attackers try upwards of 20 different methods to uninstall EDR. 

• Endpoint activity can expose attacker intent. Registry keys, PowerShell history and execution traces can all show what the bad guys trying to do—even if they fail. 

• Monitor for downloads of known “admin helper” tools like Revo Uninstaller or SuperF4 on production systems. 

Bottom line, attackers will go after the tools that defenders rely on. Ensuring those tools are hardened, monitored, and backed by additional controls is essential to keeping your incident response effective under pressure. 

Stay vigilant and keep learning!