During a recent engagement, I was asked to perform advanced threat simulations designed to test the detection capabilities of current desktop security controls and advanced threat toolsets. The purpose of these simulations were to determine if the current capabilities would be able to detect a threat agent on the network with out-of-the-box rule sets or through the creation of custom correlation rule sets.
I have had the opportunity to go up against many different antivirus (AV) tools and it is usually trivial to create payloads that will bypass these endpoint protections and provide me with remote access to the systems. In this particular case, McAfee’s ePolicy Orchestrator (ePO) was deployed across the entire environment. At first I tried typically successful payloads to rip back shells and beacons to my Amazon EC2 instance. But…
McAfee detected the payloads that I tried to upload to our test system. Why? Several months ago, McAfee released a signature for their AV products to detect variants of “Veil” payloads, which I commonly use for our testing. Veil’s Python-based payloads use a package called Pyinstaller by default, which creates a standalone executable (.exe) for use on Windows based systems. This standalone executable is a compressed zip file which contains a Python installer, the required Python libraries, and the payload script. McAfee’s “Veil” signature keys off of this compressed zip and prevented my payload from running.
Fortunately for me, the developers of Veil developed a second method for creating a standalone Python executable. This is called Pwnstaller, which is an obfuscated Pyinstaller loader. Pwnstaller obfuscates the source files that are used by the payload and makes it very difficult for AV signatures to detect the payloads. I then created a new payload using Pwnstaller instead of Pyinstaller, which allowed me to bypass McAfee’s signature detection.
For a full breakdown on how Pyinstaller and Pwnstaller are used in Veil, check out the Veil developer’s blog.
Note: For the following process I used Kali Linux, Veil Evasion, and Cobalt Strike
Within Cobalt Strike, I first need to create a listener. The listener is what the payload calls back to once it is executed on the target system. For this particular scenario I used the HTTP Beacon listener in Cobalt Strike.
Once the listener is created, I then generate shellcode in Cobalt Strike. This can be done from the “Attack” menu inside Cobalt Strike. There are a few settings that need to be tweaked to allow for the shellcode to be accepted by Veil:
- Set the Encoder to generic/none
- Set the ExitFunc to process
- Set the Output to veil
After creating the custom shellcode, I copy the shellcode and paste it into Veil Evasion. To do this I cat your payload to display the shellcode.
Next, I start up Veil Evasion and select the payload. For this example, I used the python/shellcode_inject/flat payload. Once selected, I type generate and then select option 2 to supply custom shellcode. I paste in the shellcode generated from Cobalt Strike.
I then supply a file name for the payload. The final step is to select how to create the payload executable. For this step, I select option 2 Pwnstaller (obfuscated Pyinstaller loader).
Once the creation process is complete, I’m able to slip past AV without any issues and continue to pop boxes throughout the internal network.
As we’ve known for a while, AV is not an “All-In-One” solution that you can deploy and expect to be protected against all threats in your environment. It is, and should be, part of your desktop security controls that are deployed on each workstation and server in the environment to help protect endpoints from known commodity malware and viruses. For attackers using more advanced threats, AV is more like a speed bump that a true deterrent. It’s hard to prevent a dedicated spear-phishing threat, but a combination of tiered prevention, detection and response controls need to be well-thought out and tested regularly to make sure they are still picking up the latest techniques.