Over the past 6 months the Veil team has built up a decent private repository of publicly-drawn and privately-developed AV-evasion research. This has resulted in 30+ private payload modules that span a variety of methods and languages. We realized that this code was doing no good just sitting around; we want these methods out! So after some debate, a schedule for the next year has been drafted to release these modules in the main Veil github repository.

The Veil-Evasion team is starting something we’re calling “V-Day”, for victory over antivirus. On the 15th of every month, for the next year, at least one new payload module will be released. We’d like to thank Microsoft with their Patch Tuesday as our inspiration :) With that being said, we’re happy to release the following updates to Veil-Evasion for our very first V-Day.

We’ve released the capability to include void pointer casting to all python payloads. We wanted to be able to provide some information to you about how they work and what it means for you.

Currently, Veil now has two methods of injecting shellcode into memory, Void Pointer Casting or VirtualAlloc (and a few additional calls). Both methods can work, but void pointer casting does require a specific target and/or configuration setting.

Void pointer casting works by storing our shellcode in an array, and passing a pointer to the array to a function which then executes the shellcode. The issue you may encounter with this method of injecting code is DEP (Data Execution Prevention). When injecting shellcode in this manner, we aren’t “marking” the location in memory where our shellcode is stored as being executable. Therefore, systems (typically Vista or newer) that use DEP will likely prevent your shellcode from being executed. You may receive an access violation message, or simply nothing at all. There is a chance that this method in injecting and executing shellcode will work, however, it does require that the enforcement “level” is set in an insecure manner, potentially such as “AlwaysOff”.

VirtualAlloc lets us bypass standard DEP enforcement. When we use VirtualAlloc to allocate memory, we specifically set the allocated memory as being “PAGE_EXECUTE_READWRITE“. This allows us to not only write to the allocated section of memory, but also execute the code stored inside of it as well. This is a valid call that can be used to bypass DEP. Therefore, for DEP protected systems, this is likely the injection method that will work to execute your payload.

If you have any questions about this, feel free to leave a comment, or just ask any of us on twitter.

Note: with this version of Veil, the ./config/veil.py settings file may have moved for some installations to /etc/veil/settings.py , and the ./output/ folder is being moved to ~/veil-output/ in an effort to move towards proper Debian compliance for Kali.

Thanks, and don’t get caught!