Install the complete Veil-Framework from the following: [download] After git-clone has completed, go inside the “Veil” directory and run the “update.sh” shell script. It will take some time to download and setup everything. When everything has been setup, go to the “Veil/Veil-Pillage/” directory and run the “Veil-Pillage.py” Python script. Set the target and the login credentials in Veil-Pillage. You can also specify multiple targets and credentials by separating them with a comma (,) in the same line.
Set a global value of “lhost“, which is the IP address of the attacking machine, using the below command:
At the time of writing this article, there were 7 categories with total of 60 modules in Veil-Pillage. Categories and Modules in Veil-Pillage: Tab completion for modules: enumeration/domain/query_domainsid enumeration/domain/query_group enumeration/domain/query_users enumeration/host/credential_validation enumeration/host/detect_powershell enumeration/host/detect_powershell_install enumeration/host/enum_host enumeration/host/etw_results enumeration/host/etw_wininet enumeration/host/user_hunter management/enable_uac management/force_logoff management/force_reboot management/force_shutdown management/run_command persistence/registry/sticky_keys persistence/registry/sticky_keys_disable persistence/registry/sticky_keys_exe persistence/registry/unc_dll powersploit/exfiltration/invoke-ninjacopy powersploit/invoke-script powersploit/invoke-script-results powersploit/kill-scripts
Use “credentials/autograb” to get hashes of users on the victim machine:
Note that “force_method” has been set to none, which means this module will first run this module using the PowerShell script “autograb.ps1“. If this fails, then it will use the binary technique. You can see that attacker’s IP address has been set to “10.0.0.14”, which we did earlier using the “setg lhost” command. Press Enter (Option (Y)) to execute the module.
In the above screenshot, the first highlighted area shows that PowerShell has been found on the victim machine and it is being used to execute the AutoGrab module. Then the PowerShell script is downloaded and installed from the second highlighted HTTP path, which is hosted on the attacker machine by Veil-Pillage itself. After the module has executed, a screen similar to the one below is shown. It shows the location of the file containing the output of the AutoGrab module execution (file name is a timestamp of module execution).
Pressing “y” will show you the output of the command:
This module can be used to dump not just local system hashes but also other hashes and plaintext passwords from memory and publicly known password files. Similar to this module are “credentials/hashdump” and “credentials/powerdump” modules, which can dump hashes of local system users. The next module is one of the very popular modules used in post-exploitaiton phases of a penetration testing engagement, “credentials/mimikatz“:
Executing the module and waiting for it to complete and get output:
And read the output of the executed module:
The Mimikatz module dumped the login hashes for two logged-in users, “Administrator” and “slave”. One of the biggest advantages of using Mimikatz is that it is executed from memory only, and nothing is written on disk. It can also dump other data like Kerberos tickets if they are stored in memory. The Enumeration category contains modules using which domain and host enumeration can be performed. It allows an attacker to gather more information about the victim and the infrastructure of which it is part by using the data gathered from it. If you have a collection of login credentials, then “enumeration/host/credential_validation” can be used to validate those credentials against the victim machine. A sample screenshot of the same can be seen below:
If you have a number of hosts, then “set targets target1,target2,target3,…” can be used to set multiple targets along with credentials set using “set creds username1:password1,username2:password2,…“. Detailed information about the victim machine can be obtained using the “enumeration/host/enum_host” module:
This module accepts an “out_file” option, which allows you to specify the file name in which output of this module will be stored temporarily on victim machine. The output of this module after being received on the attacker machine is stored in a text file (not shown on screen because of its huge content):
This text file contains the following information in an organized manner:
ipconfig (network connectivity – IP address, interfaces, etc.)
ARP table
User accounts
Currently logged-in users
Netstat (TCP & UDP)
Currently running processes
System information
Earlier I had mentioned that some modules have an option “force_method” with values none, powershell & binary. To find out if PowerShell is installed and accessible on the victim machine or not, Veil-Pillage has a module “enumeration/host/detect_powershell“.
Similar to this module is “enumeration/host/detect_powershell_install” which only finds if PowerShell is installed on the victim machine or not. Two interesting enumeration modules are “enumeration/host/etw_results” and “enumeration/host/etw_wininet“. ETW stands for Event Tracing for Windows and these modules are used to fetch event logs from Windows and to fetch cookies & post parameter data of the Internet Explorer browser only. These modules can prove to be very useful if some sensitive information like authenticated cookies can be fetched from the victim machine. But unfortunately, these modules were not working for me.
Getting an interactive shell from the victim machine can easily be done using the “impacket/psexec_shell” module.
Since I have the credentials of the Administrator account on the victim machine, and this module uses psexec, I am getting a highest privileged SYSTEM shell:
This module makes getting an interactive shell ridiculously easy and saves a lot of time when you just want to have a quick shell (which is just a module click away in Veil-Pillage). Have you ever used the “smbclient” utility, which is used to connect to remote SMB services used to access files and perform other activities? Very similar to that is the next module, “impacket/smb_shell“, which gives an interactive SMB shell on the victim machine.
A successful SMB shell is shown below with some sample commands, which show you have full-fledged SMB shell access on the target machine.
Another shell access module is “impacket/smbexec_shell“. This module gives shell access to the victim machine, but is semi-interactive. Being a psexec shell gave a SYSTEM shell access.
It is called semi-interactive for a reason: if you execute a command with very large output like “systeminfo“, it will crash the shell, but the command does get executed on the victim machine. So running a delete all files command will get executed on the server if you want to create havoc for no reason. To make changes or enable/disable settings and some services on the target machine, we have the Management category of Veil-Pillage modules. User Access Control (UAC) is protection implemented in Windows, and you can check if it is enabled on the victim machine or not using “management/check_uac” module:
As you can see below, on my victim machine it is disabled right now:
UAC can be enabled using the “management/enable_uac” module:
Let us again check UAC status using the “management/check_uac” module:
To get remote desktop access to the victim machine and to enable remote desktop (if disabled), we have a useful module, “management/enable_rdp“.
To intercept traffic originating from the victim machine, a very useful management module is “management/enable_proxy“, which can be used to enable a system proxy that points to an attacker’s controlled proxy machine.
I have configured my Burp Suite to listen on 10.0.0.14:8080 as a proxy. This module at present is showing an error message. But it is a very useful module which can be used to intercept all traffic. But it will show an error message for SSL websites since the SSL Certificate will fail to be validated by the victim’s web browser.
The Payload Delivery category contains those Veil-Pillage modules which can be used to upload and execute a specific payload like a Meterpreter executable or any Windows executable file. One of the modules of this category is “payload_delivery/exe_delivery” which can be used to upload an executable file and execute it on the victim machine. For this demo I am generating a Meterpreter EXE file using Veil-Evasion (part of the Veil-Framework). In the below image, you can see Veil-Evasion has generated a Meterpreter EXE along with a resource file (.RC).
Configure the module to upload the generated EXE file and execute it on the victim machine:
After executing the EXE file, a cleanup file path is also shown, which we will use in just a minute.
We can check out msfconsole, which we had earlier called using the resource file:
When we are done with the Meterpreter execution and want to clean up the files from the victim machine, we simply have to use the “cleanup” command from Veil-Pillage with the path to the cleanup script shown above:
The Persistence category consists of those modules which can help you maintain access to compromised machines. One helpful task to maintain access is to create a new user account. The “persistence/add_local_user” module can perform this task easily:
The user account has been created when this module is executed. And the best part is that you will also get a cleanup script to remove it when you want to.
Use the “net users” command in the “management/run_command” module to get a user list or “credentials/hashdump” module to dump the user list and corresponding login hashes. One of the old hacks but still a popular backdoor is the Sticky Keys hack. In this hack, the Sticky Keys executable “sethc.exe” (C:WindowsSystem32) is backdoored or replaced by another EXE. When a user presses the SHIFT key 5 times, this executable is called. This hack has been made automated in Veil-Pillage using the “persistence/sticky_keys” and “persistence/sticky_keys_exe” modules. The former will show a CMD when sticky keys are called, whereas the latter can be used to replace it with any other EXE of your choice like a Meterpreter EXE. One advantage of both these modules is that they have a cleanup script too, using which you can restore the original “sethc.exe” file. The last category of Veil-Pillage is PowerSploit. The scripts in this category have already been covered in the “PowerShell Toolkit – PowerSploit” article. I request you to please refer to it. Also note that one article is not enough to cover all the modules of Veil-Pillage. At the time of this writing, there were 60 modules. Many of the useful modules have been discussed here, but I have faith that you will try others if and when needed or for knowledge purposes.
