I’ve recently converted my sturdy Raspberry Pi Zero W to a bad USB using the P4wnP1 image and toolkit created my mame82. The ultimate goal was to run a remote command shell while evading the latest version of Symantec SEP with full protection enabled. Its easy to run a remote shell by creating your own payload, however the advance features available in Symantec makes it difficult to execute as the SONAR and IPS detection techniques are powerful. You can go far by encrypting the payload and delivery as Symantec will be unable to anaylse it. The brilliant article by Erik outlines how the SSL certificate can be a give-away as portions are not encrypted and looks illegitimate.

Some articles to read before on evading detection:

With my setup I have the following to complete the below tutorial:

Raspberry Pi Zero W and SD Card

Pi Zero W USB A addon (https://www.amazon.com/MakerFocus-Raspberry-Required-Provide-Connector/dp/B077W69CD1 and http://www.raspberrypiwiki.com/index.php/Raspberry_Pi_Zero_W_USB-A_Addon_Board)

Laptop used for attacking, IP in the tutorial for attacking machine is 192.168.1.106.

Windows 10 machine with full Symantec SEP enabled

Overall Setup

P4wnP1

I won’t cover the P4wnP1 USB setup as this has been covered on several articles. Have a look at the official git https://github.com/mame82/P4wnP1_aloa and WIKI https://p4wnp1.readthedocs.io/en/latest/.

Some notes of the setup, I’ve changed the following important settings:

Hotspot name

USB HID attack script, discussed below

Some pictures of the final device, ready for action.

Plugged in on victim machine, yes not the most covert USB port!

3D Printed Case

Victim Machine

My test machine runs a Windows 10.0.16299.125 and a trail version of Symantec Endpoint Protection 14.2.

I’ve also ensured that UAC is enabled on the default settings.

Attacking machine

I run my own customized Ubuntu for pen-testing. One caveat for the testing is that I’m on the same network in order to connect. This off-course, will be different depending on your engagement and you can covert your connection and egress through port 443 etc., which is mostly allowed on corporate networks with little filtering. I’ll leave further reading to yourself.

Attacking our Target

The Payload

Obfuscation can go a long way in evading payload detection. I do however prefer to create my own using c# or c. Shout-out to Bank Security for a great article on this, follow here https://medium.com/@Bank_Security/undetectable-c-c-reverse-shells-fab4c0ec4f15. For this specific instance I’ve gone with a simple C# payload, source code hosted and created by the above author on github.

Reminder to make small changes to your attacking machine’s IP and port, I’ve used port 443 for the test.

This mostly covers the payload, I’ve run a test instance on the victim machine and surprise, no detection by Symantec. This is where the ease of things stopped.

Payload Delivery

Delivering the payload was not as easy. Symantec’s SONAR monitors powershell and command prompt very tightly and seem to detect everything I throw at it.

My initial idea was to stay close to native windows in order to evade. I’ve tried using certutil to deliver the payload from my website hosted on my local webserver. Another alternative was decoding the payload as base64 and use certutil to decode. This also failed.

I would love to hear some other techniques that worked for others!

I eventually settled using a very simple technique by running SyncAppvPublishingServer to execute the code. A good write-up on this and similar techniques can be found here https://ired.team/offensive-security/powershell-without-powershell. This seems to evade Symantec’s monitoring of powershell completely.

Do deliver the payload I use a simple command, powershell downloads the payload, which is evaded using SyncAppvPublishingServer and the payload also evades detection as its custom developed. Once downloaded File is run from the user’s profile. Let’s focus more on the code below.

Completion

To wrap up the attack, I’ve setup the bad USB to execute the commands. Some pictures on my setup are below. I’ve accessed my bad USB by connecting via WiFi to my android phone. There is no detection from Symantec as this isn’t a usb device but is seen as a keyboard.

Connecting using my Android device, e.g. Kevin’s Android is the AP name for my bad USB

Loading and running my HID script

The HID script is setup to wait until the users repeatability pressed the Numlock key, this can be modified to your liking when and how to execute. Keep in mind that USB HID device will show on-screen and you need to cater that your common user won’t care or might get suspicious.

The HID script i’ve setup as below:

Finally, once executed I gain my remote shell.

This wraps up a very simple technique for payload creation and evading Symantec’s advance features on payload delivery.

Would love to know what techniques you found working or any improvements!

Special thanks to the authors of the above articles, great for the community to share.

Updates — Other AV Solutions

Based on the great feedback I’ve tried to test some other solutions. I’ll be compiling a table with the results the moment I’ve had a few of them covered.

So far Windows Defender seems very capable of detecting the attack where Symantec SEP still struggles, logs, especially SONAR shows not a single event.

Windows Defender