Veil-PowerView v1.3

Veil-PowerView has had even more recent changes, culminating in the release of version 1.3:

  • The optional “-CheckShareAccess” flag that can be passed to Invoke-Netview and Invoke-ShareFinder should now accurately record shares that you currently have access to.
  • Get-NetGroups and Get-NetGroupUsers now accept wildcards for the -GroupName passed.
  • Get-NetServers was combined into Get-NetComputers, which now accepts wildcards for the -HostName, -OperatingSystem, and -ServicePack to query AD for.
  • Invoke-FindVulnSystems was implemented, which uses Get-NetComputers to query AD for machines that are likely vulnerable to MS08-067.

There’s also been a major rewrite in how PowerView invokes various Windows API methods (such as NetShareEnum). The standard approach most resources recommend for .dll access is through using the Add-Type method and a member definition to expose specific methods, documented here. You might ask, if this works, why change anything? Two main reasons- first, while this method actually compiles C# code on the fly in memory, some temporary files actually touch disk. As an attacker, refraining from any/all disk access when possible is a good philosophy to maintain. And second, since some code has to be JIT compiled, this method will actually fail in some environments, where some csc.exe/.NET wonkiness can mess stuff up.

Luckily, @mattifestation wrote an excellent post on an alternative method to access the Windows native API. His post can explain it better than I can, but a tldr; is that you can use some native .NET functionality to resolve the address of any method in a loaded .dll. You can then build a custom delegate that models the method you’re intending to call and invoke whatever functionality you need. Graeber also has an article on building structs and enums without having to invoke the csc compilation method as well. All .dll imports and structs in PowerView were rewritten using these methods, leaving disk pristine and expanding the environments you can run PowerView in.

Happy (user) hunting :)

Veil-PowerView v1.1

Veil-PowerView has gotten a few changes over the past week or so. As mentioned previously, right after its release, Carlos Perez and the PowerSploit guys, @obscuresec and @mattifestation, gave some great feedback on how to make PowerView standards compliant. At the short March 2014 NovaHackers presentation given on PowerView, Rob Fuller (@mubix) gave some more great feedback on tweaks and features to add. Veil-Powerview v1.1 is the implementation of those suggestions, and integrates the following changes:

  • The verbs for all “Net-*” functions have been changed to “Get-Net*” and “Invoke-Net*” as appropriate.
  • The verbs for the meta functions have all been changed to “Invoke-*” (i.e. Invoke-Netview).
  • The method Invoke-UserDescSearch has been added, and will pull all AD user data and search account descriptions for particular keywords, defaulting to “password”.
  • Invoke-Netview and Invoke-ShareFinder now both have a “-CheckShareAccess” flag that will only display found shares that the local user has access to (through the use of the Check-Path cmdlet).
  • Invoke-ShareFinder now includes all shares by default, with an “-ExcludeShares” flags to exclude common shares.
  • Use of ‘return’ has been greatly reduced.
  • adsi is implemented in more places instead of straight API calls – for example, Get-NetServers now uses an adsisearcher instead of API calls to get ALL server host names from Active Directory.
  • Write-Host and Write-Output have been eliminated, with functions now returning pure objects.

I’m sure a few things were missed, so let us know as problems or suggestions arise. Also, the functions Get-NetConnections and Get-NetFiles were implemented to enumerate the connections and open files on servers with more granularity. Unfortunately, these calls need a user to be local admin on a target server, but they still have their specific uses. For anyone wanting to get going on writing powershell, I highly recommend checking out Carlos’ style guide, some of his examples, as well as the awesome examples from the PowerSploit project.

March 15th V-Day Release

This month’s V-Day will be quick, but we promise still useful. Veil-Evasion 2.6.0, just pushed to the master branch, now implements two new obfuscated C payloads, c/meterpreter/rev_http and it’s service-version brother c/meterpreter/rev_http_service. These are the http flavors of the rev_tcp stagers released a while back, and function the same way the python reverse_http stagers do. They have the MSF http checksum algorithm built in as well, so each run should request a shiny new resource URI for staging. Oh, and these work great against a beacon handler as well.

We also have a shiny new update from @midnite_runr‘s awesome Backdoor Factory tool, check it out!

Also, a few people have been having problems with some Veil-Evasion payloads crashing, often with the powershell/* modules. We figured that this was due to the Metasploit Framework modifying the output format for msfvenom, which is where we pull our generated shellcode from. The specific commit is here. We put a patch into Veil-Evasion that attempts to determine the build version of your local Metasploit installation and pulls shellcode output appropriately depending on version. Let us know if there are any additional problems.

Lastly, to offer another option to utilize Veil-Evasion in external tools, we’ve implemented a basic JSON RPC interface for payload generation. Invoking it with ./Veil-Evasion.py –rpc will open up a local listener to handle the RPC connections, spitting back out the paths to successfully generated payloads. We’ll have a quick blog post up in the next week on utilizing this functionality.

Veil-Evasion Cortana Integration

During our second Shmoocon demo, we briefly demonstrated the newly released Cortana script, veil_evasion.cna, included at Veil-Evasion/tools/cortana/veil_evasion.cna. We wanted to go over exactly what this script is and how it can be used effectively.

Cortana is an attack scripting language based on Sleep, both written by Raphael Mudge. Cortana allows for advanced manipulation of Armitage or Cobalt Strike, the free and paid versions of a gui-type environment (and more) for Metasploit. (Note: armitage is freely available in Kali with apt-get install armitage). With Cortana, you can trigger on specific events or user actions, interact with the full Metasploit backend, modify menus, and more. There are some great examples on Raffi’s github of what you can do with this powerful language at your fingertips.

We wanted to fully integrate Veil-Evasion’s capabilities into Armitage/Cobalt Strike utilizing Cortana. In order to get the menu structure desired, Armitage (bsd-licensed) backend code was stripped apart and custom menus were constructed using Raffi’s existing code examples. We were finally able to get our graphical menus to what we wanted. To load up the veil_evasion.cna script in Armitage, go to Armitage -> Scripts, select the Load button and navigate to the veil_evasion.cna script:

load_cortana

On first run, you will be prompted for your Veil-Evasion installation path:

veil_evasion_path

After loading the Cortana script, a Veil-Evasion menu will be opened in the top menu bar. Clicking on it will allow you to Generate a payload, check the Current PSEXEC Payload, or Set Veil-Evasion Path to your current installation. Choosing Generate will present the main Veil-Evasion menu:

veil_evasion_cortana_main

Double-clicking on Payload will fill a dynamically-generated list of all current Veil-Evasion payloads in your installation:

veil_cortana_payload

Double-clicking MSFPayload will present a set of selectable msfpayload options for shellcode_inject payloads:

veil_cortana_msfpayload

Clicking Generate will run the appropriate Veil-Evasion command in the backend and generate the output path for your generated payload If you select Set as PSEXEC Payload, then all straight Metasploit psexec module executions will be hooked and your generated payload will be substituted in:

veil_cortana_generate

If you ever want to chance the hooked PSEXEC payload to something else, choose Veil-Evasion -> Current PSEXEC Payload and either enter a custom .EXE path or clear to eliminate the custom .EXE hooking. If you’re utilizing Cobalt Strike, selecting Use Listener will allow you to select one of your existing listeners and fill in all appropriate options for payload generation.

If you’re interested in Cortana, check out Raffi’s master github, his tutorial, and/or the Cortana script pack I’ll be maintaining here. And if you happen to be in Austin in mid-to-late March, check out my talk on Cortana scripting at @BSidesAustin, “Wielding a Cortana” where I’ll cover this particular Cortana effort and others in more detail. The slides are up on slideshare and the video is posted here.

 

Server Donation – Our Thanks!

The Veil development team has been extremely fortunate to have a number of people reach out to ask how they can help us to continue our work on the Veil-Framework.  We’re pretty fortunate to be able to call Ahmed, the owner of Digitalfyre, our friend.

Ahmed has donated to the Veil development team a server to utilize as we see fit.  As of now, we will utilize the server to track our project goals and utilize the infrastructure to test future development work on.

Personally, our development team have also purchased virtual servers for use from Ahmed, and couldn’t speak highly enough of the stability and customer service we receive when working with Digitalfyre.  We obviously wanted to say thanks to Ahmed, and hope that if anyone has any hosting needs of any kind, that you look to Digitalfyre.

Bypassing On-disk Detection With Veil-Catapult

Say you’re on an internal pentest for a client, and the backdoor .exe you’ve been using has suddenly been snatched up by some antivirus solution. You’re short on time, you haven’t heard of Veil-Evasion, and you really need access. Are you toast, or is there some other option?

There still might be hope. One of the techniques released with Veil-Catapult at Shmoocon 2014 is the host-and-UNC-invoke approach. Choose the [h]ost method when prompted and enter your local IP (tab-completable) so the target machines know where to reach back to:

catapult_host_launch

We use the Impacket library to throw up a temporary SMB server to host an .EXE, and then issue a pth-wmis or pth-winexe command that invokes a command with a \\UNC path back to our attacker box. This will load the payload executable into memory without touching disk, allowing otherwise disk-detectable executables to bypass detection:

catapult_host_execute

One interesting note we discovered when working with this technique: you can use this to get some otherwise disk-detectable executables past some solutions, but not all. Microsoft Security Essentials will detect a stock-generated msfvenom executable executed-in-memory using host/execute but not other disk-detectable methods (like c/shellcode_inject/void):

mse

More evidence that AV vendors are trying to block pentesting tools without actually doing the correct behavioral detection.

#avlol :)

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.

DEP and Pyinstaller

Previously, on our first V-Day payload release, we described using void pointer casting as a method to invoke shellcode. We also noted that when using this method, you may run into some problems with DEP enforcing systems as we memory location in memory is not explicitly marked as RWX. As most systems tend to default to an opt-in DEP enforcement policy, if the executable you’re running opts-in to this protection, this method will fail with an access violation.

We were recently investigating a weird quirk with these types of payloads: python void pointer payloads (currently) work when being run as a manual python .py file, but fail when packaged into an executable with Pyinstaller. We determined that while the python.exe interpreter used and packaged with the Pyinstaller binary is not DEP enabled, the resulting Pyinstaller payloads do in fact opt in to this protection. If you’re interested, you can check/confirm this using the GetProcessDEPPolicy system call.

So the next step was to determine how to convince Pyinstaller to generate executables that don’t opt into DEP protection. Pyinstaller binaries are conceptually somewhat simple: the python interpreter and necessary libraries are packaged together with the target script into a CArchive, and packed onto the end of a small loader executable. The Pyinstaller website concisely describes a CArchive as, “Very much like a .zip file. They are easy to create in Python and unpack from C code. CArchives can be appended to other files (like ELF and COFF executables, for example).” Pyinstaller holds precompiled copies of 32-bit and 64-bit loaders for Linux, OSX and Windows in ./pyinstaller-2.0/support/loader/* , then dynamically builds the CArchive structure and attaches it to the appropriate loader. When the resulting executable runs, the loader extracts the python environment and script from the CArchive, and uses the interpreter to run the packaged script.

These loader executables are what what were throwing us for a loop: all the windows loaders included with the project are compiled with DEP protection enabled. Luckily, the source for the loaders are included with the project in ./pyinstaller-2.0/source/* , and if you have Visual Studio installed on a Windows box, the binaries can easily be recompiled in a way to fit out needs.

The binaries utilize the WAF build system to build the loaders. Open up .\pyinstaller-2.0\source\wscript , and add conf.env.append_value(‘LINKFLAGS’, ‘/NXCOMPAT:NO’) right after the other flags on lines 209 and 211 (as seen on line 210 and 213 below). This will instruct the Visual Studio linker to turn off DEP compatibility:

 

wscript_dep

Then run

C:\pyinstaller-2.0\source\> python waf configure
C:\pyinstaller-2.0\source\> python waf 

to configure the build system to your environment and build all the loader executables. For our purposes, the only binary you need is  .\pyinstaller-2.0\source\build\releasew\runw.exe – copy this into the pyinstaller-2.0/support/loader/Windows-32bit/ install location used by Veil (found under PYINSTALLER_PATH in /etc/veil/settings.py).

Pyinstaller generated executables should now opt out of DEP protection, enabling you to use void pointer shellcode invocation on a much larger number of machines.

 

How to Safely Check Veil Payloads Against VirusTotal

In hindsight, this post is probably one of the first ones that we should have written, but better late then never.

As many of you know, we heavily state on our website, within Veil, and within the license, that you should not be submitting your payloads to VirusTotal, or any online virus scanner. We still heavily believe in this, and if you want the best chance to not get caught, just don’t do it.

With that said, there’s another option. In case no one has used it before, Rob Fuller (@mubix) created a great tool called VT-Notify. VT-Notify works by sending a SHA1 hash of a binary to VirusTotal through its API. The key thing to note here is that your payload is not uploaded to VirusTotal, simply its SHA1 hash. VirusTotal then uses the SHA1 hash against its AV solutions, and let’s you know if any of the SHA1 hashes have been flagged/detected by any of the antivirus solutions it has available. Again, while we still think it’s best to not submit any information anywhere, this is the best solution for checking to see if your payloads have been flagged.

First, in case you haven’t noticed, Veil is now creating a list within the ~/veil-output/ directory called hashes.txt.

Hashestxt

This file contains the SHA1 hashes of all payloads you’ve created, along with their name. This is what VT-Notify will use when interacting with VirusTotal.

VT-Notify has been added to Veil in two different areas, and can be accessed either way. To use it within Veil’s menu, simply start Veil, and then at the main menu you should see the new option. This is for a quick single check. Simply call the command “checkvt”, and you should see the following output if all your payloads are “clean”.

Checktvclean

Now, if one of your payloads have been flagged, you should see something similar to the following.

Checkvtcaught

This essentially concludes how to use it within Veil’s menu system. You also can use the tool, like normal with all its command line options from the command line. To to this, just simply browse to its location at /path/to/veil/tools/vt-notify/ and call it from within that directory.

Vtnotify

If anyone has any questions, feel free to hit us up in our forums! Thanks!