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.
The Problem:
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…
![]()
Signature Woes
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.
![]()
The Bypass:
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.
Payload Creation:
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.
Takeaways:
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.
Dan Astor
Dan Astor is Director of Offensive Security, Research & Innovation at Security Risk Advisors, where he leads and oversees SRA’s penetration testing, application security, red team, and offensive security research practices.
Dan is responsible for the technical direction and execution of these services, including the development and maintenance of SRA’s testing methodologies, standards, tooling, quality practices, and operator tradecraft. He works closely with SRA’s technical teams to continually evolve how engagements are delivered as technologies, attacker techniques, regulatory requirements, and client environments change.
His work includes leading and supporting complex adversary simulation and threat-led penetration testing programs, including engagements aligned with TIBER-EU and DORA Threat-Led Penetration Testing (TLPT) requirements. He also helps guide the development of offensive security capabilities for highly regulated organizations and critical industries.
As part of SRA’s Research & Innovation efforts, Dan researches emerging offensive security techniques and technologies and helps translate that research into new tooling, methodologies, and client services. His current areas of focus include the application of artificial intelligence and agentic systems to penetration testing, application security, reconnaissance, security research, and the automation and augmentation of offensive security workflows.
Dan contributes to vulnerability research and coordinated disclosure, including SRA’s CVE Numbering Authority activities, and develops and contributes to open-source security tooling. He also regularly publishes technical blog post and presents at industry conferences.
Dan has worked with Fortune 1000 organizations across financial services, healthcare, pharmaceutical, technology, telecommunications, media and entertainment, manufacturing, utilities, and other critical industries. He holds the Offensive Security Certified Professional (OSCP), Certified Red Team Operator (CRTO), and CREST Practitioner Security Analyst (CPSA) certifications.





