(In)sekurity

infosec | IT | random

Blog

4\15\2020

SANS (FOR610) VIRTUAL MACHINES + ESXI

After recently doing the Reverse-Engineering Malware course from SANS, I wanted a long-term environment to keep the virutal machines on. To avoid the VMWare 30-day Workstation license limitations, in addition to being able to access my analysis lab remotely, I made an effort to move that over to my ESXI lab. Not a lot of changes required to get it working as the vm's were likely created from a VMware product initially. First, once I moved all the files related to each virtual machine into one of my ESXI datastores, I was able to register the vmx file without an issue. Once you try to boot the first time it prompts with a move\copy question, I used the "I copied it" option. Next, an error message popped up stating "Unsupported or invalid disk type 2 for 'scsi0:0'. Ensure that the disk has been imported". The setting that needs to be modified is the hard disk controller. Going to Edit Settings>Hard disk 1>Controller location for each virtual machine, you can modify the disk type. Change the setting from "SCSI controller 0" to "IDE controller 0" and the disk should now boot fine. (Below image)

If you have ESXI version 5.1 (?) or newer, before you even power on the virtual machine from the steps above, you will need to change the format of the .vmdk file to be able to take snapshots while the machine is running. It will give the error "Failed - An error occurred while saving the snapshot: Object type requires hosted I/O.".

When it comes to malware analysis labs, it is imperative to have snapshot functionality. The snapshots also help to have all the display and network settings hardcoded, restoring right to a running machine and not worry about load time, and not require you to adjust settings every time you restore your snapshot.

Enable ssh on the ESXI server, navigate to your datastore where the vmdk files are located, and run the following tool:

vmkfstools -i boot.vmdk boot-esxi.vmdk

Once that's cloned and completed, replace the new vmdk with the old and boot normally. Now you have snapshots capability while the machines are running.

The other side of this that needs to be changed is the network settings. Its best to keep these systems isolated and separate from any other systems or networks. I created a new Virtual Switch for the analysis lab, no uplinks, and a new Port Group attached to the aforementioned Switch. With this setup, the systems are isolated, no internet access, but connected to the same switch. As there isn't a DHCP server on ESXI itself, you must statically configure the IP settings on the analysis machines themselves. Here, I assigned 192.168.200.2/24 to my REMnux vm, and 192.168.200.1/24 with the DNS and GATEWAY of 192.168.200.2 on my REMWorkstation.

Lastly, even though you are isolating the vm's there is always a chance that malware tries to exploit a vulnerability in vmware itself and escaping outside of the vm. Its best to keep this esxi instance separate from any other production or personal systems, with proper network segmentation or on a whole different network entirely.

2\7\2020

Intro to wifi pineapple and wifiphisher - WIRELESS ASSOCIATION ATTACKS AND captive portals

The Wi-Fi Pineapple and Wifiphisher were the tools of choice for a project on Wireless association attacks, which was done in the end of 2018 and finally came around to do the blog post. Both tools could perform the three common methods for association attacks which are:

Evil Twin mimics any existing legitimate wireless network or hotpot in the vicinity to appear like the real one. The way evil twin attack works is having the hacker position near any authentic Wi-Fi access point and discover its SSID and Frequency. The hacker can then replicate the same SSID Frequency as the legitimate Wi-Fi Access point and then use it to lure users to connect to the attacker hotspot by tricking or forcing users on to it.
The approach of KARMA is to stand-up an open wireless access point in attempt to have unsuspecting victims connect to the AP thinking it is a legitimate AP. It differs from Evil Twin in the sense that its not targeting or replicating an existing wireless network and instead is named and configured to the attackers liking.
Known Beacons is where the attacker monitors Wi-Fi client devices (mobile, laptop, etc.) for beacons. Every wireless enabled device contains a Preferred Network List (PNL). Regardless of the location of a device and with with wireless enabled, every device periodically emits beacons associated with a network on the PNL to check if it is in the vicinity and to automatically connect (if auto-connect is enabled). Once the attacker identifies a given networks information in the PNL beacons, they can stand-up and mimic a wireless network from that PNL. This tricks the client devices to think their home or saved network is being broadcasted and typically attempts to connect to it automatically.

I'd recommend following the Hak5 instructions and video in getting the Wifi pineapple online. (https://docs.hak5.org/hc/en-us/categories/360000979333-WiFi-Pineapple)

Once online, a web interface is provided where you can control and see all the AP's, clients, and configure everything.

Dashboard showing an overview and status of the wifi pineapple in action.

The Recon module is where you will usually get started to scan the wifi landscape and see the access points, from the scan results one can be aware of which wireless networks and their respective clients are in the wifi pineapple range.

Recon tab showing the scan results and settings.

In the Evil Twin method, determine which network you’d like to target and the respective clients for that network. Once clients are identified, you would select the “Deauth” option on the client MAC address in order to force disassociation\disconnection with the legitimate Access point network and hopefully have them connect to the mimic’d AP or "evil twin". The PineAP module daemon must be enabled with the following settings to allow the Evil Twin attack and Known Beacons methods:

Capture SSID's to Pool - collects all wifi networks name and information and saves it to the list
Beacon Response - configures the pineapple identify itself as a given network and responds back to clients as it
Broadcast SSID Pool - broadcasts all wifi networks within the list of captured SSID's

PineAP module options and current pool list

The Known Beacons works similarly to Evil Twin. Instead of selecting one of the networks collected from the AP broadcast list, the pineapple automatically identifies those networks from the client PNL, and responds back with beacons to associate itself with that network in the PNL. From there, the attacker can "Deauth" if necessary and direct you to connect to one of your "trusted" networks in your PNL.

For the KARMA method, one can setup a custom WiFi network to be used within the Configuration module of the Pineapple. Once the SSID name has been specified, saving the settings automatically enables KARMA with the Evil Portal(captive portal) module if desired. Once enabled, one can monitor the pineapple dashboard for active clients and the logs associated with client connects and disconnects, associations and disassociations. Once an unsuspecting victim is successfully connected to one of the spoofed networks, their network access is in control of the attacker. If the Captive Portal was enabled, a page asking for some type of information would present itself and any information entered gets logged into pineapple logs, not in the GUI.

Client module showing connected devices\clients and the current settings.

As the pineapple controls the network and the captive portal is enabled, regardless of which website the client browses to they will be presented with our specified web page.

Fake Starbucks login page from wifi pineapple's Evil Portal module.

Fake Facebook login page from wifi pineapple's Evil Portal module.

Testing with Wifiphisher is an easier process and also doesn't require any hardware such as the wifi pineapple. After executing Wifiphisher with the following command "python bin/wifiphisher", it immediately jumps into action and once you go through a few prompts and selections, it begins doing its magic.

Wifiphisher showing the wireless networks to be targeted.

Phishing scenario options wifiphisher provides.

Testing with the Wifphisher tool, there aren't many options or settings to be changed or made. In this project, only KARMA and Evil Twin attacks were performed with Wifiphisher. Simply following the command prompt options gets the methods setup quickly, first choosing the target network, and second choosing the Phishing scenario available. Once those selection have been made Wifiphisher automatically starts the rogue AP (Evil Twin) and also acts as a legitimate AP (Karma), it sends out the deauth packets to the connected clients, and waits until they connect to the Wifiphishers broadcasted AP’s. Once a victim is connected, they will be forced to the captive portal where webpage asking for credentials or sensitive information is presented. In the same terminal screen, the victim information is provided along with any credentials, nothing is saved in any logs.

Although, the wifiphisher tool provides similar functionality to the Wi-Fi Pineapple, it does have its shortcomings. Some of the limitations being its primarily phishing focused, software-based meaning it requires your laptop or usb NIC to be capable of packet injection, its mainly command-line driven (no GUI), and overall more basic and feature-less than the pineapple. The upside to Wifiphisher is its open-source (free to use) and it was well developed. The upsides to the Pineapple are far wider and greater, to start it is a complete software\hardware package and no additional tools necessary (aside from your computer at least). It also has modules which can be easily downloaded from the interface to provide some more capabilities such as tcpdump to dump\monitor all the network traffic, or EvilPortal which is the package that contains fake Websites to in attempt to gather sensitive information or credentials.

5\30\2019

Intel NUC \ ESXI \ usb nics \ pfsense VM \ VLANS

I thought I would share my struggles with deploying my Intel NUC (nuc7i7bnh) environment using VMware esxi and pfsense as a Virtual Machine. The impetus was the desire to downsize from a Dell Precision 690, a monster Workstation with dual Xeon processors which is essentially a server. The fan noise on this machine feels like I'm in an airplane all the time, and considering I work from home, I was desperate to migrate my lab environment to a new silent hardware architecture. I had that server for over 7 years and had not maintained the VM's or updated esxi (still on 5.5), so that motivated me further.

Installing esxi on the NUC is straightforward, use a usb drive with the installer on it and install. Since I am running pfsense as a VM, I wanted to have multiple network interfaces on the nuc and not bottleneck the one interface the nuc comes with and use the 'the router on a stick' method ( 1 nic wan\lan separated by vlans). To avoid that, I purchased a dual 1GB usb nic from Amazon for under $40 dollars to increase my interface count to 3 total nics though this is where the struggles came in. https://www.amazon.com/gp/product/B00D8XTOD0/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Esxi by default doesn't support USB interfaces but fortunately and thanks to the vmware fling community, a team of developers but together the necessary fling to get usb interfaces to work on esxi. They do provide most of the instructions to get it to work though there was 2 critical lines of code that had me banging my head for a few days. The issue was with the persistence script provided, this script is necessary for the functionality of the usb nics since usb devices get identified late in the boot process.

https://labs.vmware.com/flings/usb-network-native-driver-for-esxi#instructions

The 2 lines of code are in bold and italic font in the persistence script below. Make sure you change out the appropriate esxi Port Groups and Switch names as the ones below are the default ones.

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

count=0

while [[ $count -lt 20 && "${vusb0_status}" != "Up" ]] ]

sleep 10

count=$(( $count + 1 ))

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

done

if [ "${vusb0_status}" = "Up" ]; then

esxcfg-vswitch -L vusb0 vSwitch0

esxcfg-vswitch -M vusb0 -p "Management Network" vSwitch0

esxcfg-vswitch -M vusb0 -p "VM Network" vSwitch0

/etc/init.d/hostd restart

/etc/init.d/vpxa restart

Without these 2 lines of code my nuc would identify the usb interfaces though upon reboot the interfaces would not be identified in the esxi gui nor could I make any changes to any of the switches associated to the usb interfaces.

My idea was to control my vlans all from pfsense, I didn't want multiple management GUI's to change\adjust when needed and therefore choosing the right esxi VLAN option is important to getting VLANS to work in esxi. If this sounds like what you are attempting to accomplish as well, then VLAN tagging at the switch level is what you want. This is the VGT (virtual machine vlan tagging) mode and can be explained in this vmware article (https://kb.vmware.com/s/article/1004252). The other method, EST (external switch tagging is when you would have an external switch or device responsible for the vlan tagging after it leaves the esxi environment which is not my case, and lastly, VST mode supports the VLAN tagging coming into esxi but does not support it within the port groups and therefore I believe would not specifically run a VM within a VLAN.

As my port groups show below, my wan or connection coming into my pfsense has the 4095 VLAN id which supports all VLAN tagged traffic, and my lab environment has VLAN 10 assigned.

Below is the an image showing the vlan interface configuration in pfsense.

Image showing the Interface Assignment in pfsense, VLAN 10 is running off of the LAN

Make sure you enable DHCP server for the VLAN network, which in my case is my LabNetwork, and set the appropriate DHCP settings. Most importantly, define firewall rules for the LabNetwork which would disallow it from accessing your LAN or other VLAN environments.

Finally, having everything configured properly I was able to successfully run pfsense in a vm, with usb network interfaces, and with VLANs on my small NUC server. Hopefully this helps someone who encountered similar issues.

References:

00\00\00

Hello World!

This is the beginning of my blogging journey.

Author: Julian

Contact: root@insekurity.com for any questions, comments, or love

Google Sites

Report abuse