Troubleshooting

Well that depends on what you have downloaded:

• '.7z', '.RAR', '.TAR', '.TAR.BZ2' and '.ZIP' - These are different compressed archive formats. They can be extracted to reveal additional files. 7-zip is free, cross-platform and is able to extract all the mentioned formats.
• '.ISO' and '.IMG' - These are disk images of an optical disc. They could be burnt onto a CD/DVD (IMGBurn), loaded onto a USB stick (UNetbootin) or mounted inside a virtual machine.
• '.NVRAM' - The virtual machine's BIOS.
• '.OVA' - 'Open Virtualization Archive' is a single compressed archive ('.tar') which contains the entire virtual machine (Virtual machine's settings ('.OVF') & hard drive ('.VMDK')). This can be imported into virtualization software.
• '.OVF' - 'Open Virtualization Format' is the configuration file for the virtual machine. This can be imported into virtualization software.
• '.VMDK' and '.VHD' - 'Virtual Machine Disk (VMDK)' and 'Virtual Hard Disk (VHD)' are virtual hard drive formats. These can be compressed to save room and expand when required. These can be imported into an existing virtual machine.
• '.VMEM' - The Virtual machine's paging file.
• '.VMSN' and '.VMSD' - VMSN are VMware snapshots and VMSD file stores metadata related to the snapshots.
• '.VMX' - Virtual machine's settings. This can be imported into virtualization software.

• Did it download correctly?
  Check the checksum of the file. For every download, we list the MD5 and SHA1 checksum of the file. You can find all the checksums here. Alternatively they will be individually displayed on their entry page. To check the checksum, you can do it here.
• Using the right software?
  See here.
• How do you know it's not working?
  See here.

If you're still having issues, see here.

Below are different methods for Linux, OSX & Windows to calculate the checksum value of a file. We will use 'metasploitable-linux-2.0.0.zip' in the examples below.

If you have the 'coreutils' packaged install (which is very common with major Linux distribution), you can use 'md5sum' & 'sha1sum' for checking files checksums.

[[email protected] ~]# md5sum metasploitable-linux-2.0.0.zip
8825f2509a9b9a58ec66bd65ef83167f  metasploitable-linux-2.0.0.zip
[[email protected] ~]# sha1sum metasploitable-linux-2.0.0.zip
84133002ef79fc191e726d41265cf5ab0dfad2f0  metasploitable-linux-2.0.0.zip
[[email protected] ~]#

Simlar to Linux, OSX comes with 'md5' & 'shasum' to generate files' checksums.

[localhost:~ dev]$ md5 metasploitable-linux-2.0.0.zip
8825f2509a9b9a58ec66bd65ef83167f  metasploitable-linux-2.0.0.zip
[localhost:~ dev]$ shasum metasploitable-linux-2.0.0.zip
MD5 (metasploitable-linux-2.0.0.zip) = 84133002ef79fc191e726d41265cf5ab0dfad2f0
[localhost:~ dev]$

By default, windows doesn't come with a program to calculate checksums. We recommend using a 3rd party tool called 'hashtab'.
To use it:

• Right click on the file --> Properties --> File Hashes.
• Wait a short while, as it calculates the file's checksum (you can select which values to calculate by right clicking in the hash window --> settings).
• You can easily compare the hash values by pasting a known value into the text box below, and hashtab will automatically compare the values and display the outcome.

When the author created the virtual machine, they may have chosen for the machine to have a static IP address, or for it to be assigned one via a Dynamic Host Configuration Protocol (DHCP) server.
If there is a README file to go along side the machine, it might be mentioned there. It may also be discussed on the author's download page. However, there are certain cases when this hasn't been disclosed.
If you're new to setting up a lab, you might be unsure if the target machine is working correctly or not, or, if you have over looked something. This is why on the entry page on VulnHub; we have listed the networking status of each machine.

If it is using a static IP address it will have a pre-assigned IP address. As IP addresses are unique and shouldn't have duplicates on the same network, you will need to check that there isn't already a device using the machine's static IP address. Usually this shouldn't be a problem as these machines should be placed in an isolated network.
However, if the virtual machine requires a DHCP server to assign an IP address, there needs to be a DHCP service running within the environment. Both Virtualbox and VMware products offer a DHCP service, which, when using the right 'network type', will isolate the machine from the current network. See the lab for our guide on doing this.
It is highly recommended that you DO NOT run these machines on a: production network, home network, a network with Internet access and/or a network containing sensitive information (VulnHub will not be responsible for any loss or damage caused). These virtual machines will work in isolated networks. See security for reasons why. Click here to see how to setup a network correctly.


IPv4 network addresses can be broken down into various classes:

 Class   -    Start-End        Subnet Mask (Dotted)-CIDR notation  - Common Ranges

Class A  -  0.0.0.0-127.255.255.255  255.0.0.0      /8       - 10.xxx.xxx.xxx

Class B  -  128.0.0.0-191.255.255.255  255.255.0.0      /16      - 172.16.xxx.xxx

Class C  -  192.0.0.0-223.255.255.255  255.255.255.0    /24      - 192.168.xxx.xxx

If the machine is using a DHCP to get an IP address, it will be placed into the same subnet as the DHCP configuration.
But, if the machine is using a static IP address, the machine could lie outside the subnet. Common ranges for a class C network are 192.168.0.0/24, 192.168.1.0/24. However, if the virtual machine uses '192.168.2.50/24', or '10.10.10.100/16' as examples, the attacker will need to adjust their virtual environment so they are in the same subnet.

Being the attacker, you will need to learn techniques to locate machines on a network.


A common way to see if the machine is 'alive' on a network is to send a ping packet (Internet Control Message Protocol (ICMP) echo request) and see if there is a reply.
However, if the machine has a firewall installed, it could be designed to drop the packet. This would result in no response to the ping request, thus failing the test to see if the machine is 'alive'.

Being the attacker, you would have to discover/research other methods to see if the machine is actually online & functioning correctly.

Depending on the virtual machine, that's the aim of it! You gain access to the system, with the highest user privilege you can reach, usually by exploiting a service running on the machine. Giving you the user credentials would defeat the purpose of the exercise.

This isn't always the case, some machines have local challenges which require you to login locally.
If this is the case, the username & password would be mentioned in the README file.
Such machines are: 'Damn Vulnerable Linux' & 'Exploit-Exercises'.

Sorry to hear that!
Depending on the nature of the question:

• You can try search the internet using a search engine.
• Contact the original author (You can find contact details on their profile).
• Get in touch with VulnHub (Please allow for 2 business days for a response).
• Join the IRC channel (Due to time-zone differences and/or peoples' personal lives it could take 'a while' for someone to respond).

Software

A 'virtual machine (VM)', is the simulation of a machine (called the 'guest') that is running inside another machine (the 'host').
The 'guest' machine uses the 'hosts' system resources to create a virtual environment, which allows for multiple machines to be created and running at the same time.
These machines behave as close as possible to a 'real' instance.
Depending on the virtualization software, the virtual machine could use 'hypothetical specifications' or emulate the host's hardware.
These machines can be integrated with a virtual network or interact with an existing network.

It depends what you want to get out of them:

• Virtualbox is free & open source. VMware has a freeware and commercial products. VMware player is freeware; VMware workstation & VMware fusion are commercial.
• Both solutions work on Linux & Windows hosts, and both support Linux & Windows guests. However, Virtualbox also supports OSX as a host & guest. Whereas VMware fusion is the only product which VMware currently offers which supports OSX host & guest.
  
  
• VMware player has the same 'core' as workstation, but its either missing various features, or has limitations.
• Virtualbox has all the features of VMware player, including any features that are 'limited' (e.g. snapshots & virtual network control) along with additional ones (e.g. cloning).
• Virtualbox has a few features that VMware doesn't (currently) offer, such as, capping 'processor usage'.
• VMware workstation offers a lot more features which Virtualbox (currently) doesn't, for example, fully automated installations of operating systems, USB3.0 support, better USB device control (more reliable connecting & releasing devices).
  
  
• VMware player is free, and is a limited version of workstation. It's good if you just want to run a virtual machine.
• Virtualbox is free, works everywhere and has various features over VMware player that are very beneficial: this product is good if you want to run & manage various virtual machines.
• VMware workstation needs to be purchased, works everywhere and has additional features that are very beneficial. This product is great if you want to run & manage various virtual machines, especially across multiple hosts.

Pentesting

Our answer can be found here, and been touched on in the 'Lab' guide.

We answered this question here, in our 'Lab' guide.

These are our recommendations if you're completely new to this:

• De-ICE: S1.100, De-ICE: S1.110 & De-ICE: S2.100 - Great way to start out.
• Metasploitable 1.0 - Lots of different ways into the box.
• pWnOS 1.0 - Good introduction to (fixing and) using exploits outside metasploit.
  
  
• Damn Vulnerable Web Application - Good introduction into the basics of web application attacks.
• Webgoat - Good introduction into the basics of web application attacks.
• Mutillidae - Good introduction into the basics of web application attacks.
• sqli-labs - Good introduction into the SQL injection attacks.

Afterwards, that's up to you! If you're stuck for ideas/wanting to do something specific, feel free to join the IRC channel and see what someone suggests.

Formats

Both Virtualbox and VMware use different virtual machine formats, but each support the 'Open Virtualization Format'. However, you can be at risk of breaking a virtual machine by doing so. The reason for this is that there may be a 'new' network card attached (as each VM solution uses a different virtual network card). Because a different interface will be active, it may conflict with the setup script of the machine (inside the VM itself) that the author created. It really depends on how the original author designed the machine.
All the virtual machines can be converted, however, some will function correctly, others will not. Maybe at a later date, this is something VulnHub will look into documenting.

In the following example, we will move a 'Windows 7' VM from Virtualbox 4.2.4 to VMware Player 5 & Workstation 9, on a windows host.
To do so, we will use 'OVF Tool', which comes pre-installed with VMware player, fusion & workstaion. You can find the homepage of the tool here.
The basic method/principle is the same when the host OS is Linux or OSX.

1. Power off the machine (Make sure it's not suspended).
   
   
   
2. Virtualbox --> File --> Export Appliance.
   
   
   
3. <Machine name> --> Next.
   
   
   
4. Choose --> <path to export to> (Leave the two boxes 'un-ticked').
   
   
   
5. Check values --> Export.
   
   
   
6. Wait.
   
   
   

1. Press 'Open a Virtual Machine'.
   
   
   
2. Locate exported file (See stage 4 of Virtualbox).
   
   
   
3. Check machine name & where to store the virtual machine.
   
   
   
4. Wait.
   
   
   
5. The virtual machine should now work.
   
   
   
6. The virtual machine will then detect new hardware as a result of the switch in the software.
   
   
   

1. Press 'Open a Virtual Machine'.
   
   
   
2. Locate exported file (See stage 4 of Virtualbox).
   
   
   
3. Check machine name & where to store the virtual machine.
   
   
   
4. Wait.
   
   
   
5. If 'The import failed because <path> did not pass OVF specification conformance or virtual hardware compliance checks', press 'Retry'.
   
   
   
6. The virtual machine should now work.
   
   
   
7. The virtual machine will then detect new hardware as a result of the switch in the software.
   
   
   

You can see what files were produced as a result.
(First window: the original Virtualbox format. Middle: an export in OVA format. Bottom: VMware format).

The same introduction message in converting 'Virtualbox' to 'VMware' applies here. Even if it is successfully converted it may still not function correctly due to the internal scripts not being coded to use the 'new' hardware.
VMware has the ability to convert to different formats, however, it is achieved by 'Command Line Interface (CLI)', not a 'Graphical User Interface (GUI)'.

In this example, we will move a 'Windows 7' VM from VMware to Virtualbox 4.2.4.
It doesn't matter if it's player or workstation, as they are both in the same directory.
The basic method/principle is the same when the host OS is Linux or OSX.

1. Power off the machine (Make sure it's not suspended).
   
   
   
2. Locate the working path of VMware (Windows users can quickly find it by right clicking on the shortcut then 'Open file location').
   Windows XP: 'C:\Program Files\VMware\VMware Workstation'
   Windows Vista or higher: (x64) 'C:\Program Files (x86)\VMware\VMware Workstation' or (x86) 'C:\Program Files\VMware\VMware Workstation'
   Linux: '/usr/lib/vmware-ovftool/'
   OSX: '/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/'
   
   
   
   
3. Once the path of VMware is known, open a command prompt window in the same directory (Window Vista or higher users can quickly do this by holding 'shift' & right clicking then press 'Open command window here').
   
   
   
4. Type the following commands:
   
   Windows
   :
   
   • cd OVFTool
   • ovftool.exe <path of the virtual machine> <path to export to> For example: ovftool.exe "C:\Virtual Machines\Windows 7.vmx" "C:\Virtual Machines\Windows 7.ovf"
   Linux/OSX
   :
   
   • ./ovftool <path of the virtual machine> <path to export to> For example: ./ovftool /home/user/vms/vmware/win7.vmx /home/user/vms/vbox/win7.vmx
   
   
   
5. Wait.
   
   
   

1. Virtualbox --> File --> Import Appliance.
   
   
   
2. Open appliance --> Locate exported file (See stage 4 of VMware) --> Next.
   
   
   
3. Virtualbox then displays a summary of the machine which will be imported. The settings now can be altered from the VMware values.
   
   
   
4. Wait.
   
   
   
5. The virtual machine should now work.
   
   
   
6. The virtual machine will then detect new hardware as a result of the switch in the software.
   
   
   

In this example, we will add the virtual hard drive from Kioptrix level 1.3 to an existing machine.
If you don't have a existing machine to amend, you'll need to create a new virtual machine. This guide

cover this.
It doesn't matter if it's player or workstation.
The principle is the same when the host OS is Linux or OSX.

1. Power off the machine (Make sure it's not suspended).
   
   
   
2. Edit virtual machine settings.
   
   
   
3. Add --> Hard Disk --> Next (You may get a UAC prompted if you're using Windows Vista or higher and have UAC enabled. Press 'Yes').
   
   
   
4. Select 'Use an existing virtual disk'.
   
   
   
5. Browse --> Locate the image file.
   
   
   
6. Select 'Keep Existing Format'.
   
   
   
7. Okay.
   
   
   
8. The virtual machine should now work.
   
   
   

Virtual Machines

Networking

• Bridged
• This allows for the VM to connect to the same network via the host's network card (You can specify which interface to use).
• The VM will have its own unique IP address on the network (closest possible to simulating an additional node on the network).
• If there is already a DHCP service running on the network, it will be automatically assigned an IP address. Otherwise, it needs to be manually assigned one (a static IP address).
• This is useful when providing services externally to/from the VM
• Any external nodes on the same network are able to interact with the VM as well as any VMs which also have access to the host network.



• NAT (Network Address Translation)
• This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
• The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the hosts, it appears to originate from the host (masking the effect of an additional node on the network).
• Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from VMware, but afterwards it uses the host's address. Therefore, no network configuration is needed.
• This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
• No external nodes on the same network are able to interact with the VM, however, other machines also using 'NAT' will be able to communicate with each other.



• Host-only
• This creates a separate network which is only connected to the host, thus causing an isolated virtual network.
• The VMs will have their own unique IP addresses on the separate network.
• VMware has its own DHCP service (by default) running for the clients, however, IP addresses can still be manually assigned.
• If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as well as the host inside the virtual network.
• This is useful for separating machines from any existing network access, whilst allowing for communication to still happen between the host and the VM.
• No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be able to communicate.



• LAN segment
• This creates a separate network, with no network access to the host, causing an isolated virtual network.
• The VM will have their own unique IP addresses on the separate network.
• IP addresses need to be a manually assigned or a DHCP service needs to be installed, configured and running inside the segment. There isn't any communication to the host so VMware can't offer its DHCP service.
• Only machines that are in the same segments can communicate with each other. Multiple segments can be used at once, however these are separate networks so nodes can't communicate between segments.
• This is useful for separating machines from any existing network access and the host, whilst allowing for communication to still happen between VMs in their virtual segments.
• No external nodes are able to interact with the VM including the host. Only machines on the same segment are able to communicate.

By enabling the option 'Replicate physical network connection state' under 'Bridged' network type selection, when the network connection is disconnected on the host this will be reflected inside the VM. For example, if the host was using a wired connection and the cable is unplugged, or if disconnected from a wireless network, the VM will also be disconnected. By doing so, the IP address of the VM will be renewed. This is useful for mobile devices that might not always have a permitted network connection as they could be moving from wired connections or using a different wireless connection.

A good guide explaining the differences in network modes can be found here.

You can customise VMware player further by pressing on 'advanced', to reveal more control over the virtual network.

• Share with my Mac/NAT (Network Address Translation)
• This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
• The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the hosts, it appears to originate from the host (masking the effect of an additional node on the network).
• Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from VMware, but afterwards it uses the host's address. Therefore, no network configuration is needed.
• This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
• No external nodes on the same network are able to interact with the VM, however, other machines also using 'NAT' will be able to communicate with each other.



• Bridged Networking
• This allows for the VM to connect to the same network via the host's network card (You can specify which interface to use).
• The VM will have its own unique IP address on the network (closest possible to simulating an additional node on the network).
• If there is already a DHCP service running on the network, it will be automatically assigned an IP address. Otherwise it needs to be manually assigned one (a static IP address).
• This is useful when providing services externally to/from the VM
• Any external nodes on the same network are able to interact with the VM as well as any VMs that have external access.
• You can select which interface to use, or VMware can 'auto detect' the interface.



• Private to my Mac/Host-only
• This creates a separate network which is only connected to the host, thus causing an isolated virtual network.
• The VM will have their own unique IP addresses on the separate network.
• VMware has its own DHCP service (by default) running for the clients, however, IP addresses can still be manually assigned.
• If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as well as the host inside the virtual network.
• This is useful for separating machines from any existing network access, whilst allowing for communication to still happen between the host and the VM.
• No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be able to communicate.

• Bridged
• This allows for the VM to connect to the same network via the host's network card (You can specify which interface to use).
• The VM will have its own unique IP address on the network (closest possible to simulating an additional node on the network).
• If there is already a DHCP service running on the network, it will be automatically assigned an IP address. Otherwise it needs to be manually assigned one (a static IP address).
• This is useful when providing services externally to/from the VM
• Any external nodes on the same network are able to interact with the VM as well as any VMs that have external access.



• NAT (Network Address Translation)
• This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
• The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the hosts, it appears to originate from the host (masking the effect of an additional node on the network).
• Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from VMware, but afterwards it uses the host's address. Therefore, no network configuration is needed.
• This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
• No external nodes on the same network are able to interact with the VM, however, other machines also using 'NAT' will be able to communicate with each other.



• Host-only
• This creates a separate network which is only connected to the host, thus causing an isolated virtual network.
• The VM will have their own unique IP addresses on the separate network.
• VMware has its own DHCP service (by default) running for the clients, however, IP addresses can still be manually assigned.
• If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as well as the host inside the virtual network.
• This is useful for separating machines from any existing network access, whilst allowing for communication to still happen between the host and the VM.
• No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be able to communicate.



• Custom
This allows for custom settings for 'Bridged', 'NAT' or 'Host-only'. For example:

• Change which interface to use (Bridged).
• Port forwarding (NAT).
• DHCP settings (NAT & Custom).



• LAN segment
• This creates a separate network, with no network access to the host, causing an isolated virtual network.
• The VM will have their own unique IP addresses on the separate network.
• IP addresses need to be a manually assigned or a DHCP service needs to be installed, configured and running inside the segment. There isn't any communication to the host so VMware can't offer its DHCP service.
• Only machines that are in the same segments can communicate with each other. Multiple segments can be used at once, however these are separate networks so nodes can't communicate between segments.
• This is useful for separating machines from any existing network access and the host, whilst allowing for communication to still happen between VMs in their virtual segments.
• No external nodes are able to interact with the VM including the host. Only machines on the same segment are able to communicate.

By enabling the option 'Replicate physical network connection state' under 'Bridged' network type selection, when the network connection is disconnected on the host this will be reflected inside the VM. For example, if the host was using a wired connection and the cable is unplugged, or if disconnected from a wireless network, the VM will also be disconnected. By doing so, the IP address of the VM will be renewed. This is useful for mobile devices that might not always have a permitted network connection as they could be moving from wired connections or using a different wireless connection.

A good guide explaining the differences in network modes can be found here.

You can customise VMware workstation further by pressing on 'advance' or going to 'virtual network editor' (from either the start menu or VMware workstation --> Edit), to reveal more control over the virtual network.

• Not attached
• This has the effect of not having been plugged in, causing the machine itself to be isolated from the network.
• The VM will not be able to get an IP address.
• No machine will be able to communicate to the VM.
• Useful for separating the machine from any network access.



• NAT (Network Address Translation)
• This allows for the VM to connect to the same network as the host by using the hosts PC & IP address.
• The VM only has a unique IP address between the guest OS and the host OS. When traffic is leaving from the host's, it appears to originate from the host (masking the effect of an additional node on the network).
• Between the guest OS and the host OS, the VM will have an IP address automatically assigned to it from Virtualbox, but afterwards it uses the host's address. Therefore, no network configuration is needed.
• This is useful when IP addresses are limited/restricted. For example, dial up Internet or Wi-Fi hotspots.
• No external nodes on the same network are able to interact with the VM, as well other VMs also using 'NAT' (This is because each VM has the same NAT IP address).



• Bridged Adapter
• This allows for the VM to connect to the same network via the host's network card (You can specify which interface to use).
• The VM will have its own unique IP address on the network (closest possible to simulating an additional node on the network.
• If there is already a DHCP service running on the network, it will be automatically assigned an IP address. Otherwise it needs to be manually assigned one (a static IP address).
• This is useful when providing services externally to/from the VM
• Any external nodes on the same network are able to interact with the VM as well as any VMs that have external access.



• Internal Network
• This creates a separate network, with no network access to the host, causing an isolated virtual network.
• The VM will have their own unique IP addresses on the separate network.
• IP addresses need to be a manually assigned or a DHCP service needs to be installed, configured and running inside the virtual network. There isn't any communication to the host so Virtualbox can't offer its DHCP service.
• Only machines that are in the same 'network name' can communicate with each other. Multiple 'network names' can be used at once, however these are separate networks so nodes can't communicate between networks.
• This is useful for separating machines from any existing network access and the host, whilst allowing for communication to still happen between VMs in their virtual networks.
• No external nodes are able to interact with the VM including the host. Only machines with the name 'network name' can communicate.



• Host-only
• This creates a separate network which is only connected to the host, thus causing an isolated virtual network.
• The VM will have their own unique IP addresses on the separate network.
• Virtualbox has its own DHCP service (by default) running for the clients, however, IP addresses can still be manually assigned.
• If multiple VMs use 'host-only' on the same host, they will all be able to communicate between themselves as well as the host inside the virtual network.
• This is useful for separating machines from any existing network access, whilst allowing for communication to still happen between the host and the VM.
• No external nodes are able to interact with the VM, however, other machines also using 'host-only' will be able to communicate.



• Generic Driver
Requires downloading the extension pack for Virtualbox.

• UDP Tunnel - Enabling virtual machines to be interconnecting using different hosts machines.
• 'Virtual Distributed Ethernet (VDE)' networking - "a flexible, virtual network infrastructure system, spanning across multiple hosts in a secure way. It allows for L2/L3 switching, including spanning-tree protocol, VLANs, and WAN emulation".

If 'Promiscuous mode' is disabled, only the traffic that was intended to receive will be passed along. It's seen as more 'secure' because only the intentional traffic for each node will forward along. This is how a 'network switch' functions.
However, if it's enabled, the 'network interface controller (NIC)' will pass all the traffic which is going though. This is used for 'packet sniffing' and a single node can view all the traffic on the network, useful for inspecting & debugging the network. This is how a 'network hub' functions.
Virtualbox has multiple settings regarding promiscuous mode:

• Deny - Disables promiscuous mode. It has the effect of using a virtual switch, rather than a virtual hub.
• Allow VMs - Only the traffic between VMs will be promiscuous mode.
• Allow All - All traffic (VMs & supported devices in the physical network) will be promiscuous mode.

VulnHub

We all learn in different ways. What works for some people, doesn't for others.
Some people learn by "watching others", or "hands on experiences", other learn by "reading about it".
We offer walkthroughs for various reasons:

• If this is all new to you, you might want a helping hand to get you started.
• After giving it a go, you might become stuck for a few hours, so they offer a nudge in the right direction.
• Once completing it, you can compare methods.

We don't make you press the 'walkthrough' button, if you wish to 'cheat' - that's your decision and you're only 'cheating' yourself.
This is the reason why we will not have a 'hall of fame' or 'user rankings' as it wouldn't be fair to the people who tried.