In this blog post, I'll share two low-tech methods I've used for defeating antivirus, EDR, MDR, XDR and whatever else the kids on my lawn are calling it these days. The first is a method I've been using for years that has yielded many wins for me during pentests. You'll probably chuckle when I describe it though because it's simple, low-tech, and convoluted all at the same time. You see, while others are out there in the arms race tweaking and re-tweaking payloads to throw at antiscan[.]me, I'm just out here installing LogMeIn, booting into Safe Mode with Networking remotely, and crippling EDR. That's right. That's it. That's the exploit. Let me show you an example of how I did this with Palo Alto Cortex XDR.
After RDPing with local admin rights to a victim workstation, I wanted to run mimikatz but knew that was not going to bode well with Palo Alto Cortex XDR. So I downloaded LogMeIn using a browser and installed it. I should mention here that in some cases web filters can block the download of the installer (this can be bypassed by placing the download on your own server) or even the communication back to LogMeIn's servers. In this case, there were no issues and everything went smoothly. Keep in mind that RDP wasn't actually necessary though. LogMeIn's installer supports a silent install from the command line which I'll sometimes run from a reverse shell.
My next step was to log into the LogMeIn web console and trigger a 'Safe-mode Reboot'. I'm not aiming to provide a full tutorial on LogMeIn here, but let me at least give you the location of this setting:
Dashboard > Computer Management > Reboot Options
This causes the target to boot into Safe Mode with Networking. I wish I could figure out how to do this myself without LogMeIn, but I've tried several different times using several different ways and it's proven challenging to get Windows to start the Remote Desktop service in Safe Mode with Networking. I'm not sure what LogMeIn's secret sauce is, but if you know of a way, please comment. In any case, having LogMeIn acting as a persistent backdoor is nice anyway in case I lose my current foothold.
Once my victim machine was in Safe Mode with Networking, I pulled up regedit.exe and browsed to the following:
Computer\HKLM\SYSTEM\CurrentControlSet\Services\Telam
(CurrentControlSet or ControlSet001, etc.)
Then I adjusted the 'Start' subkey from 0 (boot) to 4 (disabled) and initiated a normal reboot from LogMeIn. When it came back online, I logged in and observed that the Cortex XDR services were not started. After disabling Windows Defender, I then had full control to run any malicious executables.
As a side note, a bonus feature of having LogMeIn installed is the remote command line feature. It basically gives you a command line in the browser. This is great if EDR doesn't like psexec and using RDP would interrupt a user who needs the machine.
The second low-tech bypass method I'd like to share is perhaps more convoluted and applies to a specific situation. This one involves compromising the cloud EDR console and uninstalling/disabling the EDR. Below is an example of how I pulled this off.
In this case, I already had achieved Domain Admin access but wanted to dump the hashes from the domain controller and Cortex XDR was not having it. To remedy this, I reset the password of a user who I suspected would have access to the Cortex XDR cloud console. Once that was done, I logged into their email account to prepare to receive password reset emails. I also pulled up the tray icon for Cortex XDR and observed the server URL. I put that URL in a browser and it yielded a login page. From there I performed the password reset, intercepted the password reset email and logged into the Cortex XDR cloud console. Once logged in, I removed the protection from the DC. This methodology was appropriate for a DC because it doesn't require a reboot like the LogMeIn method does. Perhaps a malicious actor would reboot a DC, but I wouldn't - at least without permission!
These methods are low-tech and unsophisticated but they work. The first one involving LogMeIn I've been using for many years. I've never had the installation of LogMeIn or the subsequent disabling of EDR trigger any alarms, though I'm not going to say it couldn't happen. If I was a malicious actor with no regard for downtime and the cloud console method hadn't worked on the DC, I would probably try the LogMeIn/reboot method. So that leads us to the question of how to defend against the LogMeIn attack. The short answer is you can't. Defenders should instead focus on the vulnerabilities that led an attacker to gain this level of access. Come to think of it though, I have had situations where a web filter blocked communication to the LogMeIn server. Perhaps there was a rule in the web filter for the 'remote access' category. But a persistent attacker could likely find another way to boot it into Safe Mode with remote access. It also might be possible to develop a sophisticated monitoring scheme that would detect that a computer is responding to ICMP/SMB but not checking in with the EDR server. This is a feature that would probably be best implemented by the EDR vendor. Some EDR solutions do alert you if an endpoint goes offline, but how do you know if it's just rebooting? And even with such a solution in place, an attacker could cleverly block ICMP/SMB in the local firewall so that the monitoring server thinks it's totally offline, and therefore probably powered off. This leads me to a bonus low-tech technique to share.
This last technique involves blocking communication from the victim machine to the EDR's management server, using the host-based firewall. It's not a full bypass, but a technique that can help you get there. If I have compromised a Windows host for instance, and I want to experiment with malicious executables without defenders getting alerts, I'll create a Windows firewall rule. To begin, I'll try to identify the IP address(s) that the client EDR software agent is talking to. In some cases, the URL is shown when you click on the tray icon and open the local console window. In other cases, I've had to retrieve it by process of elimination within the output of netstat. Once I have the IP addresses, I will create a Windows firewall rule blocking all outbound traffic to that IP address. Update: I recently was able to also accomplish this by pointing Windows firewall to the EDR's executable instead of a DNS name or IP address. This allows me to throw all the payloads I want at the EDR to experiment, without generating alarms which are delivered to defenders. This is important because antiscan[.]me and Virustotal only tell you if it's detected, not if all malicious actions were blocked. Sometimes EDR will let an unknown executable run until it does something that it detects as bad. There can be complexities here. The EDR may only catch say, the third bad thing that the executable did, for instance. So the malware was able to accomplish a couple of its tasks before it was caught, but not all. What you get with antiscan[.]me is either positive or negative. In the real world, some bad things may happen before the EDR decides to call it a positive. However, I've seen EDR with machine learning draw knowledge from this situation. Going forward it will start to flag the things that happened before that third bad thing happened because it decides they're related after all. And this is where the server communication becomes important. If you're messing with payloads, machine learning means that the server will draw knowledge from the client and start to block these other previously undetected actions across the board for the whole organization. So blocking communication while you work on your exploit code can be very important so that the server can't learn from the client. This can even help outside of pentests, when you're just experimenting in a lab environment.
It goes without saying that if you are going to cripple EDR on a production network, you need to do so with mindfulness. Don't cripple it for any longer than you need to, and reenable asap. Sometimes pentesters have to make strategic decisions a malicious attacker would never face. Think ahead. What If you have trouble reenabling the EDR protection? Then you will have to reach out to defenders, which will blow your cover. It's not always worth it to take the risk. Will you really be able to get what you want before you have to engage in conversation with defenders, or will you just make a mess and blow your cover without much actual benefit? Map out your strategy and the risks before you proceed.
Resources: