Wikileaks has begun dumping a large number of files on the CIA's hacking tools. The dump is called Vault 7. It is a goldmine, not only for information about the CIA's activities, but also for information on things like how to set up a development environment or properly use Git in your everyday programming workflow. Here are a couple highlights from some cursory searches of the document dump:
CIA Git Tutorials
CIA Vim Tutorials
CIA Setting Up a Development Environment
Showing posts with label hacking. Show all posts
Showing posts with label hacking. Show all posts
NSA = Not So Adept: Hackers Loot Brash Stash Of NSA Exploits & Data
Who watches the watchers?
Apparently, now it’s…well, everybody with a computer. A massive hack against the NSA has revealed a
treasure trove of previously-private exploits and other data, and it doesn’t
make our “security agency” look very secure at all…
 |
| If the future won't let us have space-war, we'll have cyberspace-war. (Image courtesy techworm.com.) |
Pride Vs. Prejudice: Anonymous Gaily Hacks ISIS Twitter Pages
When acts of terror occur, one wonders at the source of the vitriol towards certain intended targets. Often, it seems that ignorance, hatred, and other motivators of malevolent acts may be based in a person (or a fanatical subculture’s) self-hatred, or repression of certain aspects of their lives. This creates a strong means of turning the terror back upon itself...for instance, in this faaaaaaabulous way.
 |
| Oh myyyy. (Image courtesy techly.com.au.) |
Eyes In The Sky That Pry Via Wifi: Malware-Injecting Drones Swoop In To Spy
Hackers, in an ever-escalating bid to stymie security, have teamed up with an arm of one of the world's leading aerospace companies to create computer-death from above...
 |
| As usual, we're sure this is all to "protect your freedom"... (Image courtesy youtube.com.) |
To Have And To Hold And To Hack: Cheaters' Website Info Held Hostage
Cheating on your spouse is probably a really bad idea. Cheating on your spouse and leaving a cyber trail which will be inevitably hackable seems like you're just asking to get caught...
 |
| This gets even worse when your wife learns the person on the left is a dude... (Image courtesy ofwstories.com.) |
Hacking Health: IV Pumps Can Be Remotely Reset To Cause Overdose
Last week we pondered the troubles of hacking a self-driving car. Unsavory for sure, and a nasty way to go, but something that could possibly be thwarted with a manual override via steering wheel (surely those won't get phased out completely, right?) However, what happens when the hack doesn't mess with your automotive ride, but rather your physical one?
 |
| An unlikely accomplice to chaos... (Image courtesy turbosquid.com.) |
Hackseat Driver: Will Autonomous Cars Be Too Susceptible To E-Intruders?
Hackers love taking on the challenge of manipulating technology that is supposed to be beyond any outsider's control. This can cause havoc on computers, phones, and other devices...but what happens when a hacker targets a self-driving car?
 |
| Could hackers take you and your car for a joyride? (Image courtesy computerworld.com.) |
Spy vs. mSpy: Tracking-App Company Reveals Blackmail Attempt
With so many adults willing to give up their privacy in the name of security, it's no surprise that they'd levy that same treatment (with the same unwarranted sneakiness) onto their own children. Amusingly enough, one firm that provides such products has now been hit by blackmailers.
 |
| Stalk your kids while sipping your coffee! Except sometimes, it's not so simple... (Image courtesy whiterosereader.org.) |
Euthanizing Youtube: Security-Testing Hacker Discovers Ultimate "Delete" Button
What if you had computer hacking skills of such astonishing power, you could bring an entire lane of the information superhighway to a screeching halt? What would you do with your great and terrible force? This week, one man was faced with this fascinating decision...
 |
| NOOOO! NOT THE HARLEM SHUFFLE! (Image courtesy answerbag.com.) |
IS Hacks U.S. Central Command Twitter Feed, Posts Prankish "Leaks" Like The Trolls They Are
It seems that our once-raging war against terrorism has now, at least publicly, been downgraded to some unpleasant cyberbullying.
As reported by the BBC, the United States Central Command's Twitter account was hacked by the revolutionary Islamic fundamentalist group IS, who referred to their online troll brigade as "the CyberCaliphate" in the attack. Their "CyberJihad" didn't seem to accomplish much more than ruffling a few feathers, despite the "leak" of "secrets" like a few upper-echelon bureaucrats' mailing addresses.
The Centcom Twitter account, which was known to report on strikes against IS (before the account was taken down after the hack-attack), provoked a standard "appropriate measures" response as to what was being done in retaliation. The hack occurred while President Obama was giving a speech on cybersecurity.
Several maps and diagrams were "released" by the hackers, but these appeared to be vague logistics of maritime armaments along the Chinese coast, as well as maps of various installations in North Korea. Nothing was more of a "secret" than a little googling couldn't uncover, with much of the (completely non-threatening) information sourced from U.S.-based think tanks.
According to Reuters, The Defense Department wasn't flustered, stating the government "views this as little more than a prank, or as vandalism...It's inconvenient, it's an annoyance but in no way is any sensitive or classified information compromised," Pentagon spokesman Army Colonel Steve Warren said.Nevertheless, when posted in conjunction with incendiary (fake) headlines reading "PENTAGON NETWORKS HACKED!", the IS troll brigade probably raised a few heartbeats in Washington. For a minute. Then we continued bombing them in real time, without needing to tweet about the success. The "CyberJihad's" silence in America will speak to that.
Unfortunately in France, the AnonGhost cyberterrorism group, a pro-Islamic organization, have tried to terrorize French websites in wake of the Charlie Hebdo attacks. The UK Mirror reports that larger and more notorious computerized collective Anonymous have vowed revenge for the Charlie Hebdo attacks and have been plaguing IS sites throughout the last week. This e-poking might escalate to even further name-calling and photoshopped images of completely unbelievable terrorist victory. In the meantime, they can continue to spam the internet with narcissistic content worthy of a facebook-addicted tween.
As reported by the BBC, the United States Central Command's Twitter account was hacked by the revolutionary Islamic fundamentalist group IS, who referred to their online troll brigade as "the CyberCaliphate" in the attack. Their "CyberJihad" didn't seem to accomplish much more than ruffling a few feathers, despite the "leak" of "secrets" like a few upper-echelon bureaucrats' mailing addresses.
 |
| Nerdy terrorists. Great, just what we need. (Image courtesy bbc.com.) |
The Centcom Twitter account, which was known to report on strikes against IS (before the account was taken down after the hack-attack), provoked a standard "appropriate measures" response as to what was being done in retaliation. The hack occurred while President Obama was giving a speech on cybersecurity.
Several maps and diagrams were "released" by the hackers, but these appeared to be vague logistics of maritime armaments along the Chinese coast, as well as maps of various installations in North Korea. Nothing was more of a "secret" than a little googling couldn't uncover, with much of the (completely non-threatening) information sourced from U.S.-based think tanks.
 |
| The full feed. This could easily be an Islamic twelve-year old. (Image courtesy Reuters.) |
Unfortunately in France, the AnonGhost cyberterrorism group, a pro-Islamic organization, have tried to terrorize French websites in wake of the Charlie Hebdo attacks. The UK Mirror reports that larger and more notorious computerized collective Anonymous have vowed revenge for the Charlie Hebdo attacks and have been plaguing IS sites throughout the last week. This e-poking might escalate to even further name-calling and photoshopped images of completely unbelievable terrorist victory. In the meantime, they can continue to spam the internet with narcissistic content worthy of a facebook-addicted tween.
 |
| Just...no. Not happening, guys. (Image courtesy mirror.co.uk.) |
Bitcoins And Biohacks: Dermally-Implant Your Dough?
Body modifications have been around as long as humanity. We are constantly seeking new ways to embellish, improve, and artistically distinguish ourselves by pimping our corporeal rides, and now, technological innovations may be added to that mix.
As reported by the Telegraph UK, Dutchman Martijn Wismeijer has had 12mm NFC (near-field communication) computer chips embedded in his hands as a sort of human upgrade. On these chips, he stores the keys to his bitcoin wallet, as well as a personalized alarm clock where the chips must be held to a sensor to shut off his daily alarm.
“By supporting these bio-hacking initiatives I believe we are paving the way for social acceptance while at the same time we support the bio-hacking technology that drives it.”
As reported by the Telegraph UK, Dutchman Martijn Wismeijer has had 12mm NFC (near-field communication) computer chips embedded in his hands as a sort of human upgrade. On these chips, he stores the keys to his bitcoin wallet, as well as a personalized alarm clock where the chips must be held to a sensor to shut off his daily alarm.
 |
| Easier than carrying around a sack of doubloons, for sure...but not as secure. (Image courtesy techinasia.com.) |
The 888-byte chips were installed via a ready-made syringe which delivered them to the fatty subdermal flesh. While Wismeijer admitted that many doctors were recalcitrant to perform the modification, other body artists such as tattooists or piercers may be more amenable (although regardless of the surgeon, sterile conditions are still a must.)
The founder of Mr. Bitcoin, a company that deals in crypto-currency ATMs, Wismeijer says the chips are not secure enough to permanently carry the codes at the moment, but that his experiment in embedding them was a success. He eventually would like the technology to include wireless key access for his home. Wismeijer feels this type of "bio-hacking" is just the fingertip of the bigger body of possible uses for the technology.
 |
| In the beginning, there was the byte. (Image courtesy storiesbywilliams.com.) |
Wismeijer explained, “The reason I did take the implants is that I have real-world uses for it today, my phones and tablets are all compatible. I personally feel that by supporting these bio-hacking developments we can learn what works and what doesn't and that some day, in the not so distant future we will be able to implant more functionality like sub dermal glucose sensors or heart rate monitors and other vital health monitoring devices. Imagine a normally invisible tattoo on your arm glowing red when you get a heart attack, swipe your phone and your phone will notify doctor.
“By supporting these bio-hacking initiatives I believe we are paving the way for social acceptance while at the same time we support the bio-hacking technology that drives it.”
 |
| Bodymodding biohackers, use your new powers for good. (Image courtesy hackpittsburgh.com,) |
Hack Lab Intro: How to Set up a Home Hacking and Security Testing Lab
Introduction
This series of articles comprises an introductory tutorial on how to set up a home lab to experiment with common hacking and information security testing tools. Our setup will allow us to explore the sorts of computer and network vulnerabilities that can be encountered on the internet, and to test the security of our own home computer network and networked devices, all from within an isolated and secure working environment. The series is geared toward individuals who have little or no prior experience with virtualization software or common hacking and security testing tools, but are interested in exploring network and computer security.
Over the course of the tutorial series, we will create two separate network configurations. The first will be a completely virtual environment populated by two virtual guest systems running inside a single host computer. This requires nothing more than an internet connection for the necessary downloads, and a computer with relatively modest RAM and disk resources.
The second configuration will be an everyday local area network of the sort that can be found in many homes, but which is isolated from the internet and where we can strictly control and monitor all network traffic. This setup is slightly more involved in terms of hardware than the first, requiring also a spare router.
Our monitoring and attack system in both configurations will be an instance of a Kali Linux virtual machine running inside an installation of the VirtualBox software package on our primary computer. Kali is a Linux operating system distribution intended for security testing and digital forensics.
In the first completely virtual network environment, our victim will be an instance of Metasploitable2, a virtual machine that exhibits vulnerabilities that can be found on everyday computer systems and software configurations. As noted at Offensive Security, "Metasploitable is an intentionally vulnerable Linux virtual machine. This VM can be used to conduct security training, test security tools, and practice common penetration testing techniques."
In the second network configuration, we will use the Kali Linux virtual machine to compromise an everyday local area network router of the sort that can be found on many home networks, in order to demonstrate just how easy it can be to steal login credentials passed from another computer on the network.
The tutorial is broken down into four parts:
This series of articles comprises an introductory tutorial on how to set up a home lab to experiment with common hacking and information security testing tools. Our setup will allow us to explore the sorts of computer and network vulnerabilities that can be encountered on the internet, and to test the security of our own home computer network and networked devices, all from within an isolated and secure working environment. The series is geared toward individuals who have little or no prior experience with virtualization software or common hacking and security testing tools, but are interested in exploring network and computer security.
Over the course of the tutorial series, we will create two separate network configurations. The first will be a completely virtual environment populated by two virtual guest systems running inside a single host computer. This requires nothing more than an internet connection for the necessary downloads, and a computer with relatively modest RAM and disk resources.
The second configuration will be an everyday local area network of the sort that can be found in many homes, but which is isolated from the internet and where we can strictly control and monitor all network traffic. This setup is slightly more involved in terms of hardware than the first, requiring also a spare router.
Our monitoring and attack system in both configurations will be an instance of a Kali Linux virtual machine running inside an installation of the VirtualBox software package on our primary computer. Kali is a Linux operating system distribution intended for security testing and digital forensics.
In the first completely virtual network environment, our victim will be an instance of Metasploitable2, a virtual machine that exhibits vulnerabilities that can be found on everyday computer systems and software configurations. As noted at Offensive Security, "Metasploitable is an intentionally vulnerable Linux virtual machine. This VM can be used to conduct security training, test security tools, and practice common penetration testing techniques."
In the second network configuration, we will use the Kali Linux virtual machine to compromise an everyday local area network router of the sort that can be found on many home networks, in order to demonstrate just how easy it can be to steal login credentials passed from another computer on the network.
The tutorial is broken down into four parts:
- Part 1 covers the installation of VirtualBox and provides a walk through of a full installation of a Kali virtual machine on your primary lab computer. Along the way, we'll take a short detour on how to quickly run live Kali sessions without a full installation of the machine.
- Part 2 demonstrates one way to begin exploring your existing home network with Kali Linux, and test whether you can successfully identify all the devices that are connected to it.
- Part 3 covers the installation of the Metasploitable virtual machine and the configuration of a completely virtual internal network environment inside VirtualBox. We'll then place the Kali VM on this network and offer tips and resources on how to probe the victim machine for vulnerabilities by exploiting the tools that are provided by Kali.
- Part 4 provides details on setting up our second network configuration, which models an everyday home local area network. With the attack machine, we'll conduct a simple man-in-the-middle attack against the network's router, and demonstrate a serious security vulnerability by stealing login credentials sent to it from the victim machine, in this case, the host computer.
Hack Lab Part 4: Compromising a Home Router on a Local Area Network
This is part four in our tutorial series on how to set up a home hacking and security testing lab. In part three, we set up a completely virtual network
inside VirtualBox in order to use Kali to test the (in)security of the
Metasploitable2 virtual machine. In the present article, we'll set up a
local area network similar to one you might find in any home, and then
walk through a man-in-the-middle attack against an everyday router.
Here's our hypothetical scenario: there is a malicious individual on a local area network listening in on the network traffic (sniffing it, as they say) using ARP poisoning in an attempt to steal login credentials from the router's administrator so as to hijack the device, and by extension, the network. In this scenario, Kali will once again function as the attacker but the host computer will be the victim.
This configuration will require a router specifically for the purpose of hosting our home lab's local area network. This could also be accomplished virtually, but having the external network will allow us to test the security of other external networked devices moving forward.
Configuring the Local Area Network
For the present test, which was successful, I picked up one of those ubiquitous Netgear WNR 2000 series home routers at a local flea market for ten dollars. You might even have an old router just lying around collecting dust. Plug the router in, turn it on, and configure it as desired. An online manual for this router stated that once you have connected your computer to it, you can navigate to the URL routerlogin.net or the device's ip address in a web browser to log in for administrative purposes. They further provided the factory default login credentials: 'admin' for the login name, and 'password' for the password. The first thing I did upon logging was to change the password using the router's so-called "Smart Wizard".
I prefer to hook up devices to the lab router through ethernet, and turn off wireless networking in the router when I'm feeling paranoid. Log into the router, and adjust settings as necessary. It should have DHCP, to provide ip addresses to hosts on the network. Keep it completely isolated from your actual home LAN that is connected to the internet, at the very least because connecting a second dhcp server to your main home network would cause a fair amount of chaos. We'll soon see whether this sort of interaction with the router is secure in any way. (Spoiler alert: in the case of the WNR 2000, it is not.)
Once your router is setup, open the Network settings in your Kali machine and change the attachment from the internal network to bridged mode, and attach it to the appropriate interface. (People who are more comfortable with managing multiple interfaces on Linux could just add a second adapter and switch between the two inside Kali.) Under the Advanced section of Kali's Network settings, notice the drop down menu for Promiscuous Mode. This setting is important for our test. There are three options here: Deny, Allow VMs, and Allow All. Set it to Deny. This means that Kali will not be privy to any traffic directly to or from its host machine or other VMs that may be on the network.
Why have we set Promiscuous Mode to Deny?
Abstinence-Only Networking and the IP Stack
When Kali is running in bridged networking mode, so as far as the rest of the hosts on the network are concerned, it is a completely independent host. But it's not, it's a virtual machine, it shares its network interface with its host computer, and by extension with any other VMs that might also access that interface.
If we set promiscuous mode to Allow All, the Kali machine will pick up all traffic going over the network interface, to which it has access because it is itself bridged over this interface. That obviously includes the given network's traffic sent to and from the host computer on which the virtual machine is running, as well as any other virtual machines it might be running on that interface. If the host computer pings the router, Kali will pick up the traffic.
When promiscuous mode is set to Deny, on the other hand, Kali networks with the host computer (and any other virtual machines that might be on the network) as if they were all on completely separate physical devices. If the host computer pings the router, Kali will not pick up the traffic.
If there is a secondary computer on the network, even if Kali is in promiscuous mode, it will not be able to capture a ping from that computer to the router, or any other such traffic between them, for that matter, such as an http session.
When we run the man-in-the-middle attack against the router and the host machine, however, we'll see that we can pick up traffic between them. One might wonder whether this is a true man-in-the-middle attack, because as we already know, the Kali guest and the host computer share an interface. Kali already has access to the host machine's traffic. Setting up the sniffer is basically just enabling promiscuous mode on the adapter setting.
However, we are not conducting a physical layer attack. ARP poisoning is conducted between the link layer and the network layer of the IP stack. This could be demonstrated with a secondary host on the network. An ARP attack by Kali against the secondary computer will still work even though Kali does not share a physical network interface with the victim, and could not detect such traffic even in promiscuous mode.
Reconnaissance and Scanning the Network
There should now be three hosts on the lab LAN: 1) the router, 2) the host computer (our victim), and 3) the Kali virtual machine (our attacker). Let's begin by conducting some passive monitoring of the network traffic.
Open up Wireshark on your Kali instance and conduct a live capture, to see what kind of traffic you can pick up on this network. (See part two in the series for info on how to properly configure Wireshark to conduct a live capture, if you haven't already.) Let the scan run for about half an hour. My capture picked up:
The router is at 192.168.1.1, the primary host computer is at 192.168.1.2 and the Kali machine is at 192.168.1.5. As you can see, Zenmap's color coding indicates that there may be some vulnerabilities in the router.
This scan discovered three open ports on the router, and found no open ports on any of the other hosts. Ports 23 (telnet) and 80 (HTTP) were found open by default on the router. We would expect port 80 to be open since you can log into the router with a web browser for administrative purposes. It seems a bit odd that the telnet port is open as well, as it is unlikely anyone today would be telnetting into the router on their home network. This is a security vulnerability, but, fortunately, this router does not actually allow simple telnet access to its administrative interface. Any basic attempts to connect to it via telnet are rejected, which makes one wonder why it is open to begin with.
Now let's attempt to systematically determine what traffic on the network the Kali instance is able to capture. All packets sent from or to the Kali VM will be captured in Wireshark, since the capture is running on that system: ex. ping requests to the router from Kali, ping requests to Kali from the host computer, HTTP traffic if you use a Kali web browser to navigate to the router's admin page, and so on.
As noted above, if your Kali virtual machine's network settings were in promiscuous mode, Wireshark would also capture any packets directly sent to or from the host computer. But this is not the case here as we have set promiscuous mode to Deny.
With promiscuous mode set to Deny, if you ping Kali from the host computer, the Wireshark capture will pick up all of these packets, since they are being sent directly to and from the Kali machine. However, if you ping the router from the host computer, none of the request or reply packets will be picked up by your Wireshark capture in Kali, nor will any other such traffic. For example, if you use a web browser on the host computer to navigate to the router's login interface, the capture will not detect any of this traffic.
With this observation, we have acquired our target. What we would like to do is two-fold: 1) pick up any direct traffic at all between the host computer and the router, 2) pick up any sensitive traffic (and any correspondingly sensitive information) sent between these devices.
Running a Man-in-the-Middle Attack with Ettercap
To compromise the traffic between the host computer and the router, we are going to use a program called Ettercap. As noted in its manual page, Ettercap is a "multi-purpose sniffer/content filter for man in the middle attacks." Ettercap can be run from the command line or through its graphical interface. To launch the graphical interface, type the following command into a terminal: sudo ettercap -G. The Ettercap graphical interface:
However, we're going to run Ettercap from the command line, as this conserves more resources on the host machine since it does not require excess RAM. Our plan is to use arp poisoning to capture traffic between the victim and the router. Reading through the Ettercap manual pages allows us to determine that we can use the following command to conduct our attack:
Now run the Ettercap command above (with any necessary substitutions for your own network configuration) from a terminal in Kali. If successful, the Wireshark capture should now begin picking up the echo requests and replies between the victim and the router (as well as any other packets passing between them), and Ettercap will print to the terminal any text picked up in those packets. You can now stop the live capture, quit Ettercap and stop the ping from the host machine to analyze the results.
The next question is whether we can pick up any sensitive information, such as login credentials, passing between the victim and the router. For this, we'll slightly modify our Ettercap command:
Start a new Wireshark live capture in Kali. Run the Ettercap quiet mode command in a terminal. Now, on the host computer, use a web browser to navigate to the router and log in to the administrative interface. Here's the result in Ettercap when I ran this attack against the WNR 2000 router:
As you can see, Ettercap picked up the victim's user name (here: 'admin') as well as the password (here: 'supersecretstring'). Moreover, the router passed the login credentials over the network in plaintext six times when the victim logged in to the device! Obviously, 'supersecretstring' is not a very good password, but in the present case it doesn't really matter how secure the password is, since the router passes it over the network in plaintext.
The login credentials can also be found in the Wireshark packet capture run alongside the Ettercap ARP poisoning attack. My Wireshark capture picked up a lot of packets, so let's do a search for 'credentials':
Inspecting the first packet returned from this search, reveals the following under the HTTP section of the packet view:
And there they are, the user name and password, conveniently located under the authorization heading: 'admin:supersecretstring'. In fact, it turns out the login credentials are sent in plaintext every time the victim loads another page in the router web interface!
The victim's router admin account has now been compromised. After the victim logs out of the router, the attacker can immediately log in with admin privileges, change the password and lock out the victim, or make changes to the system's settings, turning it off, etc. The "Smart Wizard" on the WNR 2000 router isn't so smart or wizardly after all!
Now the question is: does this attack work against the router on your home lab? Let us know in the comments.
Reflecting on this attack, one would probably ask: Can't we detect this attack as it was going on? Does it not create a whole load of excess traffic on the network? Wouldn't it be clear from a packet capture on the victim machine that the intrusion took place? Wouldn't it even identify the ip and hardware addresses of the attacker? The answer to all those questions is in the affirmative, but you'd need to have been monitoring the network traffic over the whole course of the login session to know that. A simpler solution for the potential victim is to check the system's ARP cache before logging in to the router. This will identify whether there are two hosts on the network with the same hardware address. Since hardware addresses are supposed to be universally unique, this is a tell-tale sign that ARP spoofing is in progress.
Moving Forward
Now that you have your lab's local area network set up, what can you do with it moving forward? Well, that's up to you! At the very least, you can use it to test the security of any given networked device you like, whether it's your main computer, a secondary computer, a cell phone, a tablet, a network drive or fileserver, a television or gaming console, and so on. Do you know what precise information your cell phone or laptop broadcasts to the entire local area network when you connect to any wireless device?
That concludes part four of our tutorial series on setting up a home hacking and security testing lab. If you've followed along from the beginning, you now have a virtual network you can use to explore the vulnerabilities in Metasploitable, an isolated local area network to test the security of any device you wish, and some familiarity with a handful of the many tools that are bundled with Kali.
As always, questions, comments, suggestions and criticism are welcome in the comments. Happy hacking!
Here's our hypothetical scenario: there is a malicious individual on a local area network listening in on the network traffic (sniffing it, as they say) using ARP poisoning in an attempt to steal login credentials from the router's administrator so as to hijack the device, and by extension, the network. In this scenario, Kali will once again function as the attacker but the host computer will be the victim.
This configuration will require a router specifically for the purpose of hosting our home lab's local area network. This could also be accomplished virtually, but having the external network will allow us to test the security of other external networked devices moving forward.
Configuring the Local Area Network
For the present test, which was successful, I picked up one of those ubiquitous Netgear WNR 2000 series home routers at a local flea market for ten dollars. You might even have an old router just lying around collecting dust. Plug the router in, turn it on, and configure it as desired. An online manual for this router stated that once you have connected your computer to it, you can navigate to the URL routerlogin.net or the device's ip address in a web browser to log in for administrative purposes. They further provided the factory default login credentials: 'admin' for the login name, and 'password' for the password. The first thing I did upon logging was to change the password using the router's so-called "Smart Wizard".
I prefer to hook up devices to the lab router through ethernet, and turn off wireless networking in the router when I'm feeling paranoid. Log into the router, and adjust settings as necessary. It should have DHCP, to provide ip addresses to hosts on the network. Keep it completely isolated from your actual home LAN that is connected to the internet, at the very least because connecting a second dhcp server to your main home network would cause a fair amount of chaos. We'll soon see whether this sort of interaction with the router is secure in any way. (Spoiler alert: in the case of the WNR 2000, it is not.)
Once your router is setup, open the Network settings in your Kali machine and change the attachment from the internal network to bridged mode, and attach it to the appropriate interface. (People who are more comfortable with managing multiple interfaces on Linux could just add a second adapter and switch between the two inside Kali.) Under the Advanced section of Kali's Network settings, notice the drop down menu for Promiscuous Mode. This setting is important for our test. There are three options here: Deny, Allow VMs, and Allow All. Set it to Deny. This means that Kali will not be privy to any traffic directly to or from its host machine or other VMs that may be on the network.
Why have we set Promiscuous Mode to Deny?
Abstinence-Only Networking and the IP Stack
When Kali is running in bridged networking mode, so as far as the rest of the hosts on the network are concerned, it is a completely independent host. But it's not, it's a virtual machine, it shares its network interface with its host computer, and by extension with any other VMs that might also access that interface.
If we set promiscuous mode to Allow All, the Kali machine will pick up all traffic going over the network interface, to which it has access because it is itself bridged over this interface. That obviously includes the given network's traffic sent to and from the host computer on which the virtual machine is running, as well as any other virtual machines it might be running on that interface. If the host computer pings the router, Kali will pick up the traffic.
When promiscuous mode is set to Deny, on the other hand, Kali networks with the host computer (and any other virtual machines that might be on the network) as if they were all on completely separate physical devices. If the host computer pings the router, Kali will not pick up the traffic.
If there is a secondary computer on the network, even if Kali is in promiscuous mode, it will not be able to capture a ping from that computer to the router, or any other such traffic between them, for that matter, such as an http session.
When we run the man-in-the-middle attack against the router and the host machine, however, we'll see that we can pick up traffic between them. One might wonder whether this is a true man-in-the-middle attack, because as we already know, the Kali guest and the host computer share an interface. Kali already has access to the host machine's traffic. Setting up the sniffer is basically just enabling promiscuous mode on the adapter setting.
However, we are not conducting a physical layer attack. ARP poisoning is conducted between the link layer and the network layer of the IP stack. This could be demonstrated with a secondary host on the network. An ARP attack by Kali against the secondary computer will still work even though Kali does not share a physical network interface with the victim, and could not detect such traffic even in promiscuous mode.
Reconnaissance and Scanning the Network
There should now be three hosts on the lab LAN: 1) the router, 2) the host computer (our victim), and 3) the Kali virtual machine (our attacker). Let's begin by conducting some passive monitoring of the network traffic.
Open up Wireshark on your Kali instance and conduct a live capture, to see what kind of traffic you can pick up on this network. (See part two in the series for info on how to properly configure Wireshark to conduct a live capture, if you haven't already.) Let the scan run for about half an hour. My capture picked up:
- SSDP broadcasts from the router, alerting hosts as to its existence
- ARP broadcasts from the victim computer and the Kali host machine, seeking out the router's hardware address from its ip address.
- DNS requests to external websites for services running on Kali and the host machine, these are obviously unresolvable, since the network is not connected to the internet. (I would also like to shut down these services later if they are not system critical, as I don't like the idea of my machines contacting random services on the internet without my say so.)
The router is at 192.168.1.1, the primary host computer is at 192.168.1.2 and the Kali machine is at 192.168.1.5. As you can see, Zenmap's color coding indicates that there may be some vulnerabilities in the router.
This scan discovered three open ports on the router, and found no open ports on any of the other hosts. Ports 23 (telnet) and 80 (HTTP) were found open by default on the router. We would expect port 80 to be open since you can log into the router with a web browser for administrative purposes. It seems a bit odd that the telnet port is open as well, as it is unlikely anyone today would be telnetting into the router on their home network. This is a security vulnerability, but, fortunately, this router does not actually allow simple telnet access to its administrative interface. Any basic attempts to connect to it via telnet are rejected, which makes one wonder why it is open to begin with.
Now let's attempt to systematically determine what traffic on the network the Kali instance is able to capture. All packets sent from or to the Kali VM will be captured in Wireshark, since the capture is running on that system: ex. ping requests to the router from Kali, ping requests to Kali from the host computer, HTTP traffic if you use a Kali web browser to navigate to the router's admin page, and so on.
As noted above, if your Kali virtual machine's network settings were in promiscuous mode, Wireshark would also capture any packets directly sent to or from the host computer. But this is not the case here as we have set promiscuous mode to Deny.
With promiscuous mode set to Deny, if you ping Kali from the host computer, the Wireshark capture will pick up all of these packets, since they are being sent directly to and from the Kali machine. However, if you ping the router from the host computer, none of the request or reply packets will be picked up by your Wireshark capture in Kali, nor will any other such traffic. For example, if you use a web browser on the host computer to navigate to the router's login interface, the capture will not detect any of this traffic.
With this observation, we have acquired our target. What we would like to do is two-fold: 1) pick up any direct traffic at all between the host computer and the router, 2) pick up any sensitive traffic (and any correspondingly sensitive information) sent between these devices.
Running a Man-in-the-Middle Attack with Ettercap
To compromise the traffic between the host computer and the router, we are going to use a program called Ettercap. As noted in its manual page, Ettercap is a "multi-purpose sniffer/content filter for man in the middle attacks." Ettercap can be run from the command line or through its graphical interface. To launch the graphical interface, type the following command into a terminal: sudo ettercap -G. The Ettercap graphical interface:
However, we're going to run Ettercap from the command line, as this conserves more resources on the host machine since it does not require excess RAM. Our plan is to use arp poisoning to capture traffic between the victim and the router. Reading through the Ettercap manual pages allows us to determine that we can use the following command to conduct our attack:
sudo ettercap -i eth0 -T -M arp /192.168.1.1/ /192.168.1.2/Before we run the command, let's take a closer look at what's going on here:
- sudo runs the command as a privileged user. This is necessary for Ettercap to conduct the packet capture.
- ettercap tells the shell to run the Ettercap program.
- -i eth0 tells Ettercap to run the capture on the eth0 interface inside Kali. This may be different for you depending on how you have your network adapters set up. If you try to run arp poisoning on an interface that is not enabled, Ettercap will likely complain that "No such device exists". If you run it on an interface that is enabled, but not connected to a network, Ettercap will complain that "ARP poisoning needs a non empty hosts list".
- -Tq tells Ettercap to run in text mode (-T), meaning it will print out any text characters found in its capture.
- -M tells Ettercap to run a man-in-the-middle attack.
- arp specifies that Ettercap should run an ARP poisoning man-in-the-middle attack.
- /192.168.1.1/ and /192.168.1.2/ specifies the two specific hosts we want to target.
Now run the Ettercap command above (with any necessary substitutions for your own network configuration) from a terminal in Kali. If successful, the Wireshark capture should now begin picking up the echo requests and replies between the victim and the router (as well as any other packets passing between them), and Ettercap will print to the terminal any text picked up in those packets. You can now stop the live capture, quit Ettercap and stop the ping from the host machine to analyze the results.
The next question is whether we can pick up any sensitive information, such as login credentials, passing between the victim and the router. For this, we'll slightly modify our Ettercap command:
sudo ettercap -i eth0 -Tq -M arp /192.168.1.1/ /192.168.1.2/As you can see, everything is the same here, except I've added a q to the -T option. This tells Ettercap to run in quiet mode, which means that it will not print any and all text it picks up in captured packets, but rather only text of potential significance, such as login credentials. For our test, we want to see if we can capture the victim's credentials when logging into the router.
Start a new Wireshark live capture in Kali. Run the Ettercap quiet mode command in a terminal. Now, on the host computer, use a web browser to navigate to the router and log in to the administrative interface. Here's the result in Ettercap when I ran this attack against the WNR 2000 router:
As you can see, Ettercap picked up the victim's user name (here: 'admin') as well as the password (here: 'supersecretstring'). Moreover, the router passed the login credentials over the network in plaintext six times when the victim logged in to the device! Obviously, 'supersecretstring' is not a very good password, but in the present case it doesn't really matter how secure the password is, since the router passes it over the network in plaintext.
The login credentials can also be found in the Wireshark packet capture run alongside the Ettercap ARP poisoning attack. My Wireshark capture picked up a lot of packets, so let's do a search for 'credentials':
Inspecting the first packet returned from this search, reveals the following under the HTTP section of the packet view:
And there they are, the user name and password, conveniently located under the authorization heading: 'admin:supersecretstring'. In fact, it turns out the login credentials are sent in plaintext every time the victim loads another page in the router web interface!
The victim's router admin account has now been compromised. After the victim logs out of the router, the attacker can immediately log in with admin privileges, change the password and lock out the victim, or make changes to the system's settings, turning it off, etc. The "Smart Wizard" on the WNR 2000 router isn't so smart or wizardly after all!
Now the question is: does this attack work against the router on your home lab? Let us know in the comments.
Reflecting on this attack, one would probably ask: Can't we detect this attack as it was going on? Does it not create a whole load of excess traffic on the network? Wouldn't it be clear from a packet capture on the victim machine that the intrusion took place? Wouldn't it even identify the ip and hardware addresses of the attacker? The answer to all those questions is in the affirmative, but you'd need to have been monitoring the network traffic over the whole course of the login session to know that. A simpler solution for the potential victim is to check the system's ARP cache before logging in to the router. This will identify whether there are two hosts on the network with the same hardware address. Since hardware addresses are supposed to be universally unique, this is a tell-tale sign that ARP spoofing is in progress.
Moving Forward
Now that you have your lab's local area network set up, what can you do with it moving forward? Well, that's up to you! At the very least, you can use it to test the security of any given networked device you like, whether it's your main computer, a secondary computer, a cell phone, a tablet, a network drive or fileserver, a television or gaming console, and so on. Do you know what precise information your cell phone or laptop broadcasts to the entire local area network when you connect to any wireless device?
That concludes part four of our tutorial series on setting up a home hacking and security testing lab. If you've followed along from the beginning, you now have a virtual network you can use to explore the vulnerabilities in Metasploitable, an isolated local area network to test the security of any device you wish, and some familiarity with a handful of the many tools that are bundled with Kali.
As always, questions, comments, suggestions and criticism are welcome in the comments. Happy hacking!
Hack Lab Part 3: Installing the Victim Machine on a Virtual Network and Basic Exploits
This post is part three in our tutorial series on how to set up a home hacking and security testing lab. If you followed along in parts one and two, you have installed a Kali virtual machine in VirtualBox on your primary computer, and have begun exploring your home computer network with nmap and Wireshark, both of which come bundled in Kali.
In the present article, we will walk through the creation and installation of our victim machine, a virtual instance of Metasploitable2, and then configure our first lab network: a completely virtual internal network inside VirtualBox. We'll place the Metasploitable2 victim machine and the Kali attack machine on the virtual network, and conclude by showing one way to begin exploring and exploiting Metasploitable's various vulnerabilities with Kali, and then provide some resources for further study.
On that note, it must be stated at the outset that Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an untrusted network. This is why we will connect it to a completely virtual network, one that cannot even be accessed by the host machine that is running VirtualBox.
Installing Metasploitable2 in VirtualBox
There are number of subtle differences between creating a Metasploitable virtual machine and creating a virtual instance of an everyday operating system such as Kali in VirtualBox, as wel shall see. Metasploitable2 is a prepackaged system intended for security testing and practicing common exploit techniques. Once the machine is set up, it does not require any updates or further configuration as was the case with Kali.
The first step, of course, is to download a copy of the Metasploitable2. Metasploitable2 was developed by Rapid7, the IT security group that created the Metasploit Framework, "a tool for developing and executing exploit code against a remote target machine," as noted at Wikipedia. The Metasploit Framework, as you may know, is also bundled in Kali, and the intentionally vulnerable Metasploitable2 system was created to provide a way to test the sorts of exploits that can be launched from Metasploit, among other tools.
You can download Metasploitable2 from Rapid7, but it is also available from other sources such as SourceForge. Once you've downloaded the file, unzip it, and place it wherever you prefer. I keep all my virtual machine .iso files and the like in a dedicated folder.
In the Metasploitable2 download, you'll notice a few differences from your Kali download. For Kali, we used the .iso disk image file to install the system on the machine. There is no .iso file for Metasploitable2. Instead we are instead going to install the Metasploitable.vmdk file, which stands for virtual machine disk format.
Start up VirtualBox and click "New" to begin setup of the victim system. Name the new virtual machine, select its type and version. I've just used the defaults here: Ubuntu, 32 bit. Click "Next".
Since we will not be using the Metasploitable system directly, but rather only interacting with it as a target, we can lower the amount of RAM we allocate for it. I've chosen 384 MB as the initial setting. After you get it up and running, you might find that you can reduce it even further. In my experience, response times begin to noticeably lag around 256MB of RAM. Click "Next".
We do not need to create a virtual hard drive for Metasploitable. Instead the .vmdk file will act as a virtual hard drive itself. Select "Use an existing virtual hard drive file", then click the file-browser icon, navigate to your Metasploitable download files, and select the .vmdk file. Click "Create".
The newly created instance should now appear in your VirtualBox interface. Notice I have grouped my kali1 instance and my Metasploitable2 instances inside a folder labeled 'lab'. Grouping becomes very helpful once you have more than a couple virtual machines set up.
Now we need to tweak a couple settings for our Metasploitalbe virtual machine. Open the Settings window. I uncheck 'Floppy' in the boot order under the System menu, though this is not very important. In the Network settings, you'll notice that the default is the same as it was for Kali: there is a single network adapter enabled with NAT, natural address translation.
We're going to change NAT to an internal VirtualBox network. In the "Attached to" drop down menu, change adapter one by attaching it to "Internal Network". You can also name your new virtual network. The default name is 'intnet'. I'm going to call mine 'labnet'. Click OK.
on_internal_network_11.png)
We're not quite ready to fire up our victim system just yet. Or at least, I'm not, because I've chosen a new name for my internal network. My experience with internal networks in VirtualBox has been a bit inconsistent. I clearly recall that the first time I used an internal network, it just worked and no further config was necessary. On another computer, I later found that the default internal network 'intnet' had to be configured as you would any custom internal network. If you fire up your Metasploitable virtual machine, log in and find that you have a functioning ip address, you're all set and can skip the following section. Otherwise, read on.
Configuring the VirtualBox Internal Network
I have to now enable the VirtualBox internal network 'labnet' to which I've just attached my Metasploitable virtual machine. If we take a look at the VirtualBox user manual section on Internal Networking, we read:
Run ip addr or ifconfig to confirm that the system has been given an ip address and make a note of it. The victim is prepped. Did I mention? Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an insecure network!
Now let's put our attack machine on the internal network. Network adapters can be changed in this manner even if the machine is running, though in my experience, this can also lead to minor glitches in the functioning of the VM, so I usually shut down if I'm going to change network settings for a VM.
Select your Kali instance in the VirtualBox application interface, click Settings, go to the Network settings. Change the adapter from Bridged to Internal Network, and select the name of your newly created internal network. I also "Allow All" in promiscuous mode under the advanced settings, as this allows the Kali network interface to detect any and all packets to and from the other virtual machine (as well as the host computer, if it were able to connect to the same network). Click OK.
Start up Kali and log in if the machine is not running. Check ip addr or ifconfig to make sure you have gotten an ip address from the virtual dchp server. If so, you're all good! Open up the Ice Weasel browser that comes bundled with Kali. In the address bar, enter the ip address of your Metasploitable instance. When the page loads, you should see the web interface that is pre-configred on the Metasploitable virtual machine. It comes packaged with 5 different websites/webapps that are intentionally insecure: TWiki, phpMyAdmin, Mutillidae, DVWA, WebDAV:
At this point, you now have a virtual internal lab network running on your host computer, and two virtual machines running on that network: your Kali attack machine and your Metasploitable victim machine. Remember, this network is completely internal to VirtualBox. Your virtual machines cannot communicate with the host computer over this network and the host computer cannot communicate with the virtual machines over this network. They are isolated.
Exploring Metasploitable's Vulnerabilities
Now the real fun begins! The first thing you might do here is passive network monitoring to see what kind of packets, if any, the victim machine is sending out over the network. Fire up Wireshark inside Kali, and start a capture on the appropriate interface for the lab network. (See part two of this series on how to configure Wireshark for live capture.)
From the packet capture, you'll soon notice that Metasploitable sends out workstation and workgroup announcements every couple of minutes for services that are running on it. If you inspect those packets more closely, you'll find that those packets contain a good deal of information about the host machine sending them, as well as about the services running on it.
An an exercise, confirm by inspecting the packets you've captured that Metasploitable is: 1) a workstation, 2) a server, 3) a print queue server, 4) a Xenix server, 5) an NT Workstation, 6) an NT Server, and 7) a Master Browser. You can doubly confirm that the machine is running such services by browsing its shares over the network in the file manager. But where can we find the network login credentials to view the shares?
Now that we have some idea of what we're dealing with, let's conduct a few port scans of the victim system to see what vulnerabilities that might expose. Let's just go through some of the various default scan types built in to Zenmap to see what they bring to light.
A ping scan reveals that the host is up. A quick scan identifies 18 open ports, among them the reserved ports for ftp, ssh, telnet, smtp, htttp, mysql and so on. A regular scan identifies 23 open ports. An intense scan also reveals 23 open ports, but it also provides operating system and version information, along with more detailed information about the services running on the various ports. For example, it notes that anonymous ftp login is allowed on port 21, identifies the SSH server's hostkey fingerprint, and so on. Run the more intensive scans to see what else you can find.
As an exercise, analyze the command options used in the various Zenmap scans to determine why those particular scans revealed that particular information.
It is worth noting here that a couple leads for tracking down Metasploitable's network login credentials are provided already in the simple quick scan. However, it is indicative of the system's complete insecurity that these leads make the question of determining the network login credentials moot. Can you identify any such lead and why it moots our earlier question?
If you've followed along this far, you're probably asking yourself: what's next? (That is, if you haven't jumped ahead already.) Well, you now have a fully functioning virtual hacking lab outfitted with one of the most powerful attack systems and one of the most vulnerable victim systems around. It's time to start exploring some of the more involved tools bundled in Kali and see what other kinds of weaknesses you can identify and exploit in the various services running on the victim machine, including in the five websites and applications running on the system. That, however, is beyond the scope of the present article, but here are some resources to help get started:
That concludes the present article. In part four of the series, we'll set up an external local area network and demonstrate how it is possible to steal login credentials from a victim machine logging in to a compromised router. As always, questions, comments, suggestions and criticism are welcome below.
In the present article, we will walk through the creation and installation of our victim machine, a virtual instance of Metasploitable2, and then configure our first lab network: a completely virtual internal network inside VirtualBox. We'll place the Metasploitable2 victim machine and the Kali attack machine on the virtual network, and conclude by showing one way to begin exploring and exploiting Metasploitable's various vulnerabilities with Kali, and then provide some resources for further study.
On that note, it must be stated at the outset that Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an untrusted network. This is why we will connect it to a completely virtual network, one that cannot even be accessed by the host machine that is running VirtualBox.
Installing Metasploitable2 in VirtualBox
There are number of subtle differences between creating a Metasploitable virtual machine and creating a virtual instance of an everyday operating system such as Kali in VirtualBox, as wel shall see. Metasploitable2 is a prepackaged system intended for security testing and practicing common exploit techniques. Once the machine is set up, it does not require any updates or further configuration as was the case with Kali.
The first step, of course, is to download a copy of the Metasploitable2. Metasploitable2 was developed by Rapid7, the IT security group that created the Metasploit Framework, "a tool for developing and executing exploit code against a remote target machine," as noted at Wikipedia. The Metasploit Framework, as you may know, is also bundled in Kali, and the intentionally vulnerable Metasploitable2 system was created to provide a way to test the sorts of exploits that can be launched from Metasploit, among other tools.
You can download Metasploitable2 from Rapid7, but it is also available from other sources such as SourceForge. Once you've downloaded the file, unzip it, and place it wherever you prefer. I keep all my virtual machine .iso files and the like in a dedicated folder.
In the Metasploitable2 download, you'll notice a few differences from your Kali download. For Kali, we used the .iso disk image file to install the system on the machine. There is no .iso file for Metasploitable2. Instead we are instead going to install the Metasploitable.vmdk file, which stands for virtual machine disk format.
Start up VirtualBox and click "New" to begin setup of the victim system. Name the new virtual machine, select its type and version. I've just used the defaults here: Ubuntu, 32 bit. Click "Next".
Since we will not be using the Metasploitable system directly, but rather only interacting with it as a target, we can lower the amount of RAM we allocate for it. I've chosen 384 MB as the initial setting. After you get it up and running, you might find that you can reduce it even further. In my experience, response times begin to noticeably lag around 256MB of RAM. Click "Next".
We do not need to create a virtual hard drive for Metasploitable. Instead the .vmdk file will act as a virtual hard drive itself. Select "Use an existing virtual hard drive file", then click the file-browser icon, navigate to your Metasploitable download files, and select the .vmdk file. Click "Create".
The newly created instance should now appear in your VirtualBox interface. Notice I have grouped my kali1 instance and my Metasploitable2 instances inside a folder labeled 'lab'. Grouping becomes very helpful once you have more than a couple virtual machines set up.
Now we need to tweak a couple settings for our Metasploitalbe virtual machine. Open the Settings window. I uncheck 'Floppy' in the boot order under the System menu, though this is not very important. In the Network settings, you'll notice that the default is the same as it was for Kali: there is a single network adapter enabled with NAT, natural address translation.
We're going to change NAT to an internal VirtualBox network. In the "Attached to" drop down menu, change adapter one by attaching it to "Internal Network". You can also name your new virtual network. The default name is 'intnet'. I'm going to call mine 'labnet'. Click OK.
on_internal_network_11.png)
We're not quite ready to fire up our victim system just yet. Or at least, I'm not, because I've chosen a new name for my internal network. My experience with internal networks in VirtualBox has been a bit inconsistent. I clearly recall that the first time I used an internal network, it just worked and no further config was necessary. On another computer, I later found that the default internal network 'intnet' had to be configured as you would any custom internal network. If you fire up your Metasploitable virtual machine, log in and find that you have a functioning ip address, you're all set and can skip the following section. Otherwise, read on.
Configuring the VirtualBox Internal Network
I have to now enable the VirtualBox internal network 'labnet' to which I've just attached my Metasploitable virtual machine. If we take a look at the VirtualBox user manual section on Internal Networking, we read:
Unless you configure the (virtual) network cards in the guest operating systems that are participating in the internal network to use static IP addresses, you may want to use the DHCP server that is built into VirtualBox to manage IP addresses for the internal network. Please see Section 8.35, “VBoxManage dhcpserver” for details.Rather than set up static ip addresses for our virtual machines on the virtual internal network, let's set up the virtual dhcp server. Reading through the VirtualBox user manual section on managing the dhcp server, we can conclude that running the following command in a terminal on the host computer will appropriately configure the internal labnet network.
VBoxManage dhcpserver add --netname labnet --ip 192.168.1.1 --netmask 255.255.255.0 --lowerip 192.168.1.2 --upperip 192.168.1.255 --enableWhat's going on here? Let's parse this command.
- There is the command for the VirtualBox dhcp server: VBoxManage dhcpserver
- We want to create a new network, therefore: add
- We indicate the name of the new network: --netname labnet
- We specify the ip address of the dhcp server itself: --ip 192.168.1.1
- We specify the subnet or netmask: --netmask 255.255.255.0
- We specify the lower ip address for the server: --lowerip 192.168.1.2
- We specify the upper ip address for the server --upperip 192.168.1.254
- Finally, we enable the network so it starts any time a machine on the network is started: --enable
Run ip addr or ifconfig to confirm that the system has been given an ip address and make a note of it. The victim is prepped. Did I mention? Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an insecure network!
Now let's put our attack machine on the internal network. Network adapters can be changed in this manner even if the machine is running, though in my experience, this can also lead to minor glitches in the functioning of the VM, so I usually shut down if I'm going to change network settings for a VM.
Select your Kali instance in the VirtualBox application interface, click Settings, go to the Network settings. Change the adapter from Bridged to Internal Network, and select the name of your newly created internal network. I also "Allow All" in promiscuous mode under the advanced settings, as this allows the Kali network interface to detect any and all packets to and from the other virtual machine (as well as the host computer, if it were able to connect to the same network). Click OK.
Start up Kali and log in if the machine is not running. Check ip addr or ifconfig to make sure you have gotten an ip address from the virtual dchp server. If so, you're all good! Open up the Ice Weasel browser that comes bundled with Kali. In the address bar, enter the ip address of your Metasploitable instance. When the page loads, you should see the web interface that is pre-configred on the Metasploitable virtual machine. It comes packaged with 5 different websites/webapps that are intentionally insecure: TWiki, phpMyAdmin, Mutillidae, DVWA, WebDAV:
At this point, you now have a virtual internal lab network running on your host computer, and two virtual machines running on that network: your Kali attack machine and your Metasploitable victim machine. Remember, this network is completely internal to VirtualBox. Your virtual machines cannot communicate with the host computer over this network and the host computer cannot communicate with the virtual machines over this network. They are isolated.
Exploring Metasploitable's Vulnerabilities
Now the real fun begins! The first thing you might do here is passive network monitoring to see what kind of packets, if any, the victim machine is sending out over the network. Fire up Wireshark inside Kali, and start a capture on the appropriate interface for the lab network. (See part two of this series on how to configure Wireshark for live capture.)
From the packet capture, you'll soon notice that Metasploitable sends out workstation and workgroup announcements every couple of minutes for services that are running on it. If you inspect those packets more closely, you'll find that those packets contain a good deal of information about the host machine sending them, as well as about the services running on it.
An an exercise, confirm by inspecting the packets you've captured that Metasploitable is: 1) a workstation, 2) a server, 3) a print queue server, 4) a Xenix server, 5) an NT Workstation, 6) an NT Server, and 7) a Master Browser. You can doubly confirm that the machine is running such services by browsing its shares over the network in the file manager. But where can we find the network login credentials to view the shares?
Now that we have some idea of what we're dealing with, let's conduct a few port scans of the victim system to see what vulnerabilities that might expose. Let's just go through some of the various default scan types built in to Zenmap to see what they bring to light.
A ping scan reveals that the host is up. A quick scan identifies 18 open ports, among them the reserved ports for ftp, ssh, telnet, smtp, htttp, mysql and so on. A regular scan identifies 23 open ports. An intense scan also reveals 23 open ports, but it also provides operating system and version information, along with more detailed information about the services running on the various ports. For example, it notes that anonymous ftp login is allowed on port 21, identifies the SSH server's hostkey fingerprint, and so on. Run the more intensive scans to see what else you can find.
As an exercise, analyze the command options used in the various Zenmap scans to determine why those particular scans revealed that particular information.
It is worth noting here that a couple leads for tracking down Metasploitable's network login credentials are provided already in the simple quick scan. However, it is indicative of the system's complete insecurity that these leads make the question of determining the network login credentials moot. Can you identify any such lead and why it moots our earlier question?
If you've followed along this far, you're probably asking yourself: what's next? (That is, if you haven't jumped ahead already.) Well, you now have a fully functioning virtual hacking lab outfitted with one of the most powerful attack systems and one of the most vulnerable victim systems around. It's time to start exploring some of the more involved tools bundled in Kali and see what other kinds of weaknesses you can identify and exploit in the various services running on the victim machine, including in the five websites and applications running on the system. That, however, is beyond the scope of the present article, but here are some resources to help get started:
- Metasploit Unleashed, an introduction the Metasploit Framework
- Burp Suite's introductory tutorial documentation
- OWASP-ZAP, the OWASP Zed Attack Proxy Project website
That concludes the present article. In part four of the series, we'll set up an external local area network and demonstrate how it is possible to steal login credentials from a victim machine logging in to a compromised router. As always, questions, comments, suggestions and criticism are welcome below.
Hack Lab Part 2: Exploring Your Home Computer Network with Kali Linux
This article is part two in our tutorial series on how to set up a home hacking and security testing lab. If you followed along in part one, installing a Kali Linux virtual machine in VirtualBox, you have installed VirtualBox on the primary computer for your home lab and created a Kali Linux virtual guest on this host machine. The Kali system has been fully updated and VirtualBox Guest Additions have been installed on it. Finally, your Kali VM has a single network adapter running in bridged mode and you have set up an administrator account on the Kali instance.
Creating and configuring the virtual network setup outlined in the introduction, which we will do in part three of this series, requires a few more steps: we still have to download and install Metasploitable, set up the virtual network, etc. But if you're like me, you're probably already itching to start playing with all the toys Kali has to offer, if you haven't already!
Home Network Analysis 101
This article will show how some of the tools that come bundled in Kali can be used to explore your existing home computer network, and test whether you can successfully identify all the devices that are connected to it. In particular, we'll take a look at a set of tools that come bundled in Kali that can be used for network analysis: nmap/Zenmap and dumpcap/Wireshark.
These will come in handy in our eventual testing lab, but they can obviously also be used to explore your home local area network as well. Nmap is a command line network scanner, and Zenmap is a graphical interface to nmap. Dumpcap is a command line network traffic monitor, and Wireshark provides a powerful and versatile graphical interface to monitor network traffic and analyze network packet capture files.
Here's a simple experiment. Do you happen to know how many devices are currently connected to your home network? Can you identify all of them off the top of your head? Try to do so, and make a list of them. At the very least, we know there will be at least three: the Kali guest, the host machine you are running Kali on, and your router. There may also be more computers or cell phones connected to it, and maybe even your television, refrigerator or coffee maker!
We are first going to use nmap to see if we can identify any such devices on the network, and perhaps detect one or two that we did not think or know were connected to it. We'll then configure Wireshark and run a packet captures to get a sense for the normal traffic on the network, and then run another capture to analyze just how an nmap network scan works.
Determining Your IP Address
Before we can scan the network with nmap, we need to identify the ip address range we would like to examine. There are a number of different ways to determine your ip address on a Linux distribution such as Kali. You could use, for example, the ip or ifconfig commands in a terminal: ip addr, or sudo ifconfig.
(Note that if you are using an administrator account inside Kali, which is considered a best practice, when a non-root user enters a command such as ifconfig into a terminal, the shell will likely respond by complaining "command not found". In Kali, sensitive system commands like ifconfig have to be run as root. To access it from your administrator account, all you need to do is add "sudo" to the front of the command: sudo ifconfig.)
These commands will provide you will a wealth of information about your network interfaces. Identify the interface that is connected to the LAN (likely eth0), and make a note of the ip address indicated after "inet" for the ip addr command, or after "int addr:" for the ifconfig command. That is your ip address on your local area network. Here are a couple ifconfig and ip addr outputs posted by the Ubuntu Journeyman:
As you can see here, the ip address for this machine is 192.168.1.4.5. Yours is likely something similar to this: for example, 192.168.1.123 or 10.0.0.56 etc. Notice in the ip addr output above, the ip address is: 192.168.4.5/24. That means 192.168.4.5 is the ip address of that specific machine, while the /24 at the end indicates the address space for the LAN's subnet, which in this case are all the addresses from 192.168.4.1 to 192.168.4.255.
If we were to scan this local area network with nmap, we would want to scope out all the addresses in the network's range, which means 192.168.4.1, 192.168.4.2, 192.168.4.3, 192.168.4.4, and so on, all the way to 192.168.4.255. One shorthand way of notating this is: 192.168.4.1-255. Another common shorthand is 192.168.4.0/24. Of course, if your address were 10.0.0.121, then the shorthand would be: 10.0.0.1-255 or 10.0.0.0/24.
Host Discovery
Let's assume your Kali VM has the ip address 192.168.1.5 on a subnet with possible host addresses from 192.168.1.1 to 192.168.1.255. Now that we know Kali's ip address and the address range we want to take a look at, open up a terminal and type: nmap. This will provide you with a long list of all the options available within the nmap program. Nmap is a powerful program and there are a lot of options! Perhaps the simplest possible network scan that can be conducted with nmap is a ping scan, for which we use the -sn option.
Now type nmap -sn 192.168.1.1-255 into your terminal and hit enter. (Don't forget to substitute the address range for your network if it is different from this!) This scan will tell you how many hosts nmap discovered by sending a ping echo request to each of the addresses in the range x.x.x.1-255, and provide you with a list of the ip addresses of the hosts that returned a ping reply. This is host discovery 101. Here is the ping scan output from nmap on a simple local area network I set up for the purpose:
The ping scan found 5 hosts up with the addresses: 192.168.1.1, .2, .3, .5 and .6. Note that in the wild, this method of discovery may not work, as it is becoming increasingly common for administrators to configure their systems so that they do not reply to simple ping echo requests, leaving a would-be ping scanner none-the-wiser about their existence.
Did your scan find the same number of hosts that you had presumed were on your network? Were there more or less?
We can use the default nmap scan to further investigate known hosts and any potential ghost hosts the ping scan may or may not have uncovered. For this, simply remove the -sn option from the command above: nmap 192.168.1-255. Here's the output of the default nmap scan on the same network as above:
Nmap has returned much more information. It found three open ports on the router at 192.168.1.1, as well as an open web server port on host 192.168.1.2. All scanned ports on the remaining hosts were closed.
You can also use nmap to further investigate known hosts. The -A option in nmap enables operating system detection and version detection. Pick out a couple of the hosts discovered by your nmap scans, for which you already know the operating system type and version. Now scan these hosts with nmap for OS and verstion detection by adding them to your host address target list, separated by commas. For example, if I would scan the router and web server discovered above for OS and version detection with the command: nmap -A 192.168.1.1,2. This will return more information, if any is determined, on those hosts.
You can obviously also run an OS and version detection scan over the whole network with the command: nmap -A 192.168.1.1-255. Depending on the number of hosts on your network, this scan could take a couple minutes to complete. If you press <Enter> while the scan is running, it will give you an update on its progress.
If there are more and a handful of hosts on your network, the output can be hard to parse in the terminal. You could send the output to a file with: nmap -A 192.168.1.1-255 > fileName.txt. Or you could use one of nmap's own built-in file output options.
But this is also where Zenmap comes in quite handy. Open up Zenmap from Applications->Kali Linux->Information Gathering->Network Scanners. If you are running as an administrator and not root, as you should be, you will get a message stating that not all of nmap's functionality can be accessed without root privileges. Root is not necessary for basic scans. However, you can run Zenmap as root by opening a terminal and typing: sudo zenmap. The Zenmap interface:
The Zenmap interface is pretty straightforward. Enter the target ip address or address range into the target field. Changing the scan profile from the drop down menu changes the scan command. You can also manually enter or edit commands in the command field. After you run a scan, Zenmap also helpfully breaks down the results for you, providing host details, port lists, network topology graphics and more.
Play around with the various built-in scan types. Can you identify all the hosts on your home network with a ping scan? a regular scan? an intense scan? Can you identify all the open ports on those hosts? If you have a laptop or another device that you frequently use to connect to the internet over public wi-fi hotspots, you can also do intensive scans of those devices to determine if there are any open ports that would represent a potential security vulnerability. Identifying open ports is important for vulnerability assessment, because these represent potential reconnaissance or attack vectors.
Network Traffic Capture and Analysis with Wireshark
Nmap scans a network and probes hosts by sending out ip packets to, and inspecting the replies from, its target at a given address. With 255 addresses to scan along with 1000 ports on all discovered hosts in the default scan of the subnet above, that's a lot of network traffic! What does the packet traffic generated by a scan look like on the network?
To answer this question, we can use Wireshark and dumpcap. Dumpcap, as its name implies, is a command line tool that dumps captured network traffic. Wireshark provides a graphical user interface to analyze these sorts of dump files, which are collections of all the network traffic to which the given network interface was privy.
If run with the proper privileges, Wireshark can capture live network traffic as well. In Kali, you can find Wireshark under: Applications->Kali Linux->Top 10 Security Tools. Unless you have already configured Wireshark with the appropriate settings, when you open it for the first time you will be informed by the "Capture" panel that "No interface can be used for capturing in this system with the current configuration."
In its documentation, Wireshark recommends appropriate settings to enable capture privileges. This also suggests confirming that Wireshark can also be run as root. To run Wireshark as root, you can log in as root, or run sudo wireshark in a terminal. When you run Wireshark as root, you will first be given a usage warning and provided with sources for how to set up proper privileges. This forum post on AskUbuntu boils the process down to three simple steps.
Now that you've enabled live captures in Wireshark, let's run one! Click "Interface List" in the Capture panel of the default view. Choose the interface that is connected to the network (it will indicate your ip address on that network), and click Start.
This will immediately begin a live capture of all the packets on the network to which the interface has access. At the very least, it will detect: 1) packets it sends out, 2) packets it receives directly, 3) packets it receives indirectly if they are broadcast to all the hosts on the network.
If you have never viewed a network packet capture before, you may be surprised what you can see, and what information is simply being broadcast over the network. You'll probably find messages from your router, you'll see internet traffic packets if you are viewing a webpage in a Kali browser, or on Kali's host computer (depending on whether or not Promiscuous Mode is enabled in the VirtualBox advanced network settings for your Kali machine). You might find that one device is especially chatty for no good reason. There might be devices pathetically sending out calls to other devices that have been removed from the network, such as a laptop searching for a printer that has been turned off, and so on.
The default Wireshark packet capture interface numbers each packet it captures, and then notes the time after the capture began that it received the packet, the ip address of the source of the packet, the ip address of the destination of the packet, the protocol, the packet's length and some info. You can double click an individual packet to inspect it more closely.
If you ping your router (which you should have been able to identify via nmap analysis) from Kali, you'll see all the requests and replies, obviously, since the Wireshark capture and the ping are running on the same machine. But the Kali guest shares its interface with the host machine. If you enable promiscuous mode in the advanced network settings inside VirtualBox for your Kali instance, when you ping your router from the host machine itself, the Wireshark capture will similarly allow you to see all requests and replies, they're going over the same interface! If you disable Promiscuous Mode, on this other hand, this will not be the case. In this case, packets to and from the host computer will not be picked up, as if it were a completely separate physical machine. Similarly, if you ping your router from a different computer, you will not see the request/reply traffic at all, though perhaps you might pick up an ARP if the requester does not already know the (hardware) address of the request's intended recipient.
After getting a feel for what the base level network traffic looks like on your network, start a new capture, and then run a simple scan from nmap or Zenmap, and watch the result in Wireshark. When the scan is finished, stop the capture and save the file. Capturing the simple nmap ping scan from above on my network resulted in a file with over 800 packets! Now you can analyze the network traffic generated by the scan itself. You'll probably want to play around with Wireshark for a bit to get a sense of what it offers. There are tons of menus and options in Wireshark that can be tweaked and optimized for your own ends.
Well, that's it for this article. In part three of our hack lab tutorial series, we'll install our victim machine, an instance of Metasploitable2, in VirtualBox and set up a completely virtual lab network to explore some more tools that are bundled in Kali. As always, comments, questions, corrections and the like are welcome below.
Creating and configuring the virtual network setup outlined in the introduction, which we will do in part three of this series, requires a few more steps: we still have to download and install Metasploitable, set up the virtual network, etc. But if you're like me, you're probably already itching to start playing with all the toys Kali has to offer, if you haven't already!
Home Network Analysis 101
This article will show how some of the tools that come bundled in Kali can be used to explore your existing home computer network, and test whether you can successfully identify all the devices that are connected to it. In particular, we'll take a look at a set of tools that come bundled in Kali that can be used for network analysis: nmap/Zenmap and dumpcap/Wireshark.
These will come in handy in our eventual testing lab, but they can obviously also be used to explore your home local area network as well. Nmap is a command line network scanner, and Zenmap is a graphical interface to nmap. Dumpcap is a command line network traffic monitor, and Wireshark provides a powerful and versatile graphical interface to monitor network traffic and analyze network packet capture files.
Here's a simple experiment. Do you happen to know how many devices are currently connected to your home network? Can you identify all of them off the top of your head? Try to do so, and make a list of them. At the very least, we know there will be at least three: the Kali guest, the host machine you are running Kali on, and your router. There may also be more computers or cell phones connected to it, and maybe even your television, refrigerator or coffee maker!
We are first going to use nmap to see if we can identify any such devices on the network, and perhaps detect one or two that we did not think or know were connected to it. We'll then configure Wireshark and run a packet captures to get a sense for the normal traffic on the network, and then run another capture to analyze just how an nmap network scan works.
Determining Your IP Address
Before we can scan the network with nmap, we need to identify the ip address range we would like to examine. There are a number of different ways to determine your ip address on a Linux distribution such as Kali. You could use, for example, the ip or ifconfig commands in a terminal: ip addr, or sudo ifconfig.
(Note that if you are using an administrator account inside Kali, which is considered a best practice, when a non-root user enters a command such as ifconfig into a terminal, the shell will likely respond by complaining "command not found". In Kali, sensitive system commands like ifconfig have to be run as root. To access it from your administrator account, all you need to do is add "sudo" to the front of the command: sudo ifconfig.)
These commands will provide you will a wealth of information about your network interfaces. Identify the interface that is connected to the LAN (likely eth0), and make a note of the ip address indicated after "inet" for the ip addr command, or after "int addr:" for the ifconfig command. That is your ip address on your local area network. Here are a couple ifconfig and ip addr outputs posted by the Ubuntu Journeyman:
If we were to scan this local area network with nmap, we would want to scope out all the addresses in the network's range, which means 192.168.4.1, 192.168.4.2, 192.168.4.3, 192.168.4.4, and so on, all the way to 192.168.4.255. One shorthand way of notating this is: 192.168.4.1-255. Another common shorthand is 192.168.4.0/24. Of course, if your address were 10.0.0.121, then the shorthand would be: 10.0.0.1-255 or 10.0.0.0/24.
Host Discovery
Let's assume your Kali VM has the ip address 192.168.1.5 on a subnet with possible host addresses from 192.168.1.1 to 192.168.1.255. Now that we know Kali's ip address and the address range we want to take a look at, open up a terminal and type: nmap. This will provide you with a long list of all the options available within the nmap program. Nmap is a powerful program and there are a lot of options! Perhaps the simplest possible network scan that can be conducted with nmap is a ping scan, for which we use the -sn option.
Now type nmap -sn 192.168.1.1-255 into your terminal and hit enter. (Don't forget to substitute the address range for your network if it is different from this!) This scan will tell you how many hosts nmap discovered by sending a ping echo request to each of the addresses in the range x.x.x.1-255, and provide you with a list of the ip addresses of the hosts that returned a ping reply. This is host discovery 101. Here is the ping scan output from nmap on a simple local area network I set up for the purpose:
The ping scan found 5 hosts up with the addresses: 192.168.1.1, .2, .3, .5 and .6. Note that in the wild, this method of discovery may not work, as it is becoming increasingly common for administrators to configure their systems so that they do not reply to simple ping echo requests, leaving a would-be ping scanner none-the-wiser about their existence.
Did your scan find the same number of hosts that you had presumed were on your network? Were there more or less?
We can use the default nmap scan to further investigate known hosts and any potential ghost hosts the ping scan may or may not have uncovered. For this, simply remove the -sn option from the command above: nmap 192.168.1-255. Here's the output of the default nmap scan on the same network as above:
Nmap has returned much more information. It found three open ports on the router at 192.168.1.1, as well as an open web server port on host 192.168.1.2. All scanned ports on the remaining hosts were closed.
You can also use nmap to further investigate known hosts. The -A option in nmap enables operating system detection and version detection. Pick out a couple of the hosts discovered by your nmap scans, for which you already know the operating system type and version. Now scan these hosts with nmap for OS and verstion detection by adding them to your host address target list, separated by commas. For example, if I would scan the router and web server discovered above for OS and version detection with the command: nmap -A 192.168.1.1,2. This will return more information, if any is determined, on those hosts.
You can obviously also run an OS and version detection scan over the whole network with the command: nmap -A 192.168.1.1-255. Depending on the number of hosts on your network, this scan could take a couple minutes to complete. If you press <Enter> while the scan is running, it will give you an update on its progress.
If there are more and a handful of hosts on your network, the output can be hard to parse in the terminal. You could send the output to a file with: nmap -A 192.168.1.1-255 > fileName.txt. Or you could use one of nmap's own built-in file output options.
But this is also where Zenmap comes in quite handy. Open up Zenmap from Applications->Kali Linux->Information Gathering->Network Scanners. If you are running as an administrator and not root, as you should be, you will get a message stating that not all of nmap's functionality can be accessed without root privileges. Root is not necessary for basic scans. However, you can run Zenmap as root by opening a terminal and typing: sudo zenmap. The Zenmap interface:
The Zenmap interface is pretty straightforward. Enter the target ip address or address range into the target field. Changing the scan profile from the drop down menu changes the scan command. You can also manually enter or edit commands in the command field. After you run a scan, Zenmap also helpfully breaks down the results for you, providing host details, port lists, network topology graphics and more.
Play around with the various built-in scan types. Can you identify all the hosts on your home network with a ping scan? a regular scan? an intense scan? Can you identify all the open ports on those hosts? If you have a laptop or another device that you frequently use to connect to the internet over public wi-fi hotspots, you can also do intensive scans of those devices to determine if there are any open ports that would represent a potential security vulnerability. Identifying open ports is important for vulnerability assessment, because these represent potential reconnaissance or attack vectors.
Network Traffic Capture and Analysis with Wireshark
Nmap scans a network and probes hosts by sending out ip packets to, and inspecting the replies from, its target at a given address. With 255 addresses to scan along with 1000 ports on all discovered hosts in the default scan of the subnet above, that's a lot of network traffic! What does the packet traffic generated by a scan look like on the network?
To answer this question, we can use Wireshark and dumpcap. Dumpcap, as its name implies, is a command line tool that dumps captured network traffic. Wireshark provides a graphical user interface to analyze these sorts of dump files, which are collections of all the network traffic to which the given network interface was privy.
If run with the proper privileges, Wireshark can capture live network traffic as well. In Kali, you can find Wireshark under: Applications->Kali Linux->Top 10 Security Tools. Unless you have already configured Wireshark with the appropriate settings, when you open it for the first time you will be informed by the "Capture" panel that "No interface can be used for capturing in this system with the current configuration."
In its documentation, Wireshark recommends appropriate settings to enable capture privileges. This also suggests confirming that Wireshark can also be run as root. To run Wireshark as root, you can log in as root, or run sudo wireshark in a terminal. When you run Wireshark as root, you will first be given a usage warning and provided with sources for how to set up proper privileges. This forum post on AskUbuntu boils the process down to three simple steps.
Now that you've enabled live captures in Wireshark, let's run one! Click "Interface List" in the Capture panel of the default view. Choose the interface that is connected to the network (it will indicate your ip address on that network), and click Start.
This will immediately begin a live capture of all the packets on the network to which the interface has access. At the very least, it will detect: 1) packets it sends out, 2) packets it receives directly, 3) packets it receives indirectly if they are broadcast to all the hosts on the network.
If you have never viewed a network packet capture before, you may be surprised what you can see, and what information is simply being broadcast over the network. You'll probably find messages from your router, you'll see internet traffic packets if you are viewing a webpage in a Kali browser, or on Kali's host computer (depending on whether or not Promiscuous Mode is enabled in the VirtualBox advanced network settings for your Kali machine). You might find that one device is especially chatty for no good reason. There might be devices pathetically sending out calls to other devices that have been removed from the network, such as a laptop searching for a printer that has been turned off, and so on.
The default Wireshark packet capture interface numbers each packet it captures, and then notes the time after the capture began that it received the packet, the ip address of the source of the packet, the ip address of the destination of the packet, the protocol, the packet's length and some info. You can double click an individual packet to inspect it more closely.
If you ping your router (which you should have been able to identify via nmap analysis) from Kali, you'll see all the requests and replies, obviously, since the Wireshark capture and the ping are running on the same machine. But the Kali guest shares its interface with the host machine. If you enable promiscuous mode in the advanced network settings inside VirtualBox for your Kali instance, when you ping your router from the host machine itself, the Wireshark capture will similarly allow you to see all requests and replies, they're going over the same interface! If you disable Promiscuous Mode, on this other hand, this will not be the case. In this case, packets to and from the host computer will not be picked up, as if it were a completely separate physical machine. Similarly, if you ping your router from a different computer, you will not see the request/reply traffic at all, though perhaps you might pick up an ARP if the requester does not already know the (hardware) address of the request's intended recipient.
After getting a feel for what the base level network traffic looks like on your network, start a new capture, and then run a simple scan from nmap or Zenmap, and watch the result in Wireshark. When the scan is finished, stop the capture and save the file. Capturing the simple nmap ping scan from above on my network resulted in a file with over 800 packets! Now you can analyze the network traffic generated by the scan itself. You'll probably want to play around with Wireshark for a bit to get a sense of what it offers. There are tons of menus and options in Wireshark that can be tweaked and optimized for your own ends.
Well, that's it for this article. In part three of our hack lab tutorial series, we'll install our victim machine, an instance of Metasploitable2, in VirtualBox and set up a completely virtual lab network to explore some more tools that are bundled in Kali. As always, comments, questions, corrections and the like are welcome below.
Hack Lab Part 1: Installing a Kali Linux Virtual Machine in Virtualbox
- run a live Kali session
- do a full install
- update the system
- install the VirtualBox Guest Additions
- configure appropriate user accounts
- and finally switch over to a bridged network adapter in preparation for the next tutorial in the series
Virtualization
There are a number of different free virtualization packages available online. For this tutorial series, we've chosen to go with VirtualBox because it's open source, beginner friendly, and there is a lot of documentation and support information that can be found for it online, especially regarding the systems that we will be installing. For example, since Kali and Metasploitable are derived from the Debian Linux distribution, support information on other Debian-based operating systems such as Ubuntu or Crunchbang is often also applicable to Kali and Metasploitable, as we shall see in this and subsequent articles.The first step is to download and install the VirtualBox software package onto the primary computer chosen for your lab setup. Make sure you download the right version for your operating system and hardware architecture (32 bit vs. 64 bit). Instructions for installation on various operating systems are readily available if you run into any snags. Also make sure to keep a handy copy of the VirtualBox user manual, which comes packaged with the software and can also be found online.
Once you install VirtualBox and run it for the first time, you'll be presented with the application's welcome prompt, which provides an orientation for the interface. Poke around in the menus to get a feel for the software.
Next, download a copy of the Kali Linux operating system .iso disc image. Again, make sure you download the proper ISO file for your computer's architecture. Depending on the speed of your internet connection, this may take some time, as both the 32 bit and 64 bit files are 3GB in size. Kali's documentation can be found here.
As Kali is a security sensitive system, once you have downloaded the file, it is recommended to check its SHA1SUM hash value against the one supplied on the download page to make sure the file had not been corrupted in transit. For more on how to check a file's hash value, follow the link to our previous article providing an overview of the process.
If you plan on playing around with a number of different virtual guests on your computer, it is probably a good idea to create a permanent folder somewhere on your system where you will keep all the necessary operating system .iso files.
Creating a Virtual Machine
Now let's return to VirtualBox and set up the virtual machine on which we will install the Kali operating system. Open VirtualBox and click "New". Provide a name for your Kali virtual guest system. Choose Linux as the type and Debian as the version, since Kali is derived from Debian Wheezy. As you can see below, I'm using the 32 bit version. Click Next.
Choose the amount of memory you want to allocate to the virtual instance once it is up and running. In my experience, Kali can use a lot of RAM, and the computer I'm running it on has a fair amount to spare, but for now I'm going to leave it at the default of 512MB. You can also adjust these settings later to optimize them for your own setup. In my experience, Kali runs pretty well in VirtualBox even on a laptop with only 4GB of RAM, though you may have to conserve by shutting down memory intensive applications running on the host computer. After you've set your memory size, click Next.
Choose whether you want to create a virtual hard drive for the virtual machine. We're going to need one for our home lab, so check "Create a virtual hard drive now", then click Create.
For the "Hard drive file type", check "VDI (VirtualBox Disk Image)", then click Next.
In the "Storage on physical hard drive" window, you'll probably want to choose "Dynamically allocated." This means that space will not be taken up on your physical hard drive until it is actually written to the virtual disk. If you choose "Fixed size" then the virtual disk drive will take up a set amount of space on your physical hard drive even if that space has not been written to by the virtual machine. Click Next.
In "File Location and Size," choose where you want the hard drive files for the virtual system to be stored by clicking on the folder icon. I just use the default folder. This is where VirtualBox will store all files related to your virtual machine. Also, on this screen you may increase or decrease the amount of hard drive space you want to be allocated for the virtual instance. 8 GB is the default. I'm going to push mine up to 10 GB. Click Create.
The new virtual system should now appear in your Virtualbox interface. As you can see I have three folders in my left sidebar, and have placed the kali1 instance I just created into a new "lab" group. In the main interface we can see the settings for the new systems, which are a mixture of defaults and configuration settings we determined ourselves in the creation phase. Before starting up the instance for the first time, I usually adjust a few settings first.
Click "Settings" for your new virtual machine. I'm going to add a description under the General menu, because I have other Kali instances on my computer.
In the System menu, under Motherboard, I uncheck "Floppy" in the boot order.
Also in the System menu, under the Processor sub-menu, we have to check "Enable PAE/NX" for Kali to operate properly.
Finally, under the Display menu, I add more Video Memory to the default 12MB, bumping it up here to 36 MB to start. Again, this can be adjusted later to optimize your particular setup.
That's it for now. Browse through the other menus. Notice in the Network setting we can add up to 4 different network adapters for our virtual machine. Later we will play around with the network setting, after we've fully installed the Kali operating system. For now, a single network adapter running on NAT (i.e. Natural Address Translation) will suffice for our purposes.
Click "OK" to save your changes.
Fire up your new machine by double clicking it, or single clicking it and then clicking Start. You will be prompted to "Select start-up disk". We now have to choose the startup disk for our new virtual machine. This is the Kali .iso file we downloaded earlier. Click the folder icon and navigate to the folder where you've stored the Kali .iso file on your host computer. Select it, then click start.
Booting into a Kali Live Session
Kali should boot as if you were booting a real physical machine from a cd with the Kali operating system file on it. Notice that if you click inside the guest window, your mouse pointer will be "captured" by the guest. From then on, your keyboard and mouse activity will control the virtual machine. To switch back to using your host machine, you have to hit the host key, which by default is Right-Control on my computer. It may be different depending on your operating system. The Virtualbox interface will tell you what the "Host Key" is in the bottom right of the window.
From this menu, you can boot into a number of different types of live session, or you can do a full install of Kali on the virtual hard drive we previously created inside Virtualbox. As we shall see, there are numerous advantages to doing a full install of Kali for the purposes of our home hacking lab, but one of the advantages of a live session is that we can jump right in without any further configuration. Let's select the default Live session. Here is the Kali Desktop after booting into live session (note the time and day, yes, this is how I prefer to spend Saturday evening):
You will soon notice that there are certain limitations to the virtual machine's interface. For example, your mouse wheel will not work, you cannot enlarge the size of the screen, or go full screen, there is no tab completion in the terminal, and there are other interace issues as well. This is not a limitation of the live session, or Kali itself, but rather of the virtual machine we've created. However, all these issues can be addressed by installing the Virtualbox Guest Additions, but we'll save that for our future full install of the system.
Notice also that there are limitations to the default NAT networking interface. Under NAT (natural address translation) the Kali guest is not treated as its own independent node on the wider local area network. It does not have an independent ip address on the local area network. Its virtual ip address is translated by the ip address of the host machine. This can be addressed by adding a second network adapter to the virtual system or changing the present one, as we shall see later on.
However, despite these limitations, you can already begin exploring the ridiculous number of tools that come bundled with Kali. Here are Kali's Top Ten Tools:
Since all appears to be working well, let's take a snapshot of the virtual machine. VirtualBox snapshots are a way to keep a log of your virtual machines in a given state. If you are experimenting with a new configuration, and everything suddenly goes to hell, you can always revert back to your previous snapshot like nothing happened. Go to the VirtualBox interface window, select your Kali guest, click "Snapshots" in the upper right. Take a snapshot by clicking on the camera icon. Name the snapshot, and give it a description. Now, if we seriously screw up something on the machine, we can always just revert to this prior state of the system.
Now let's reboot to do a full install. Click the root menu item in the top right of the Kali Desktop window. Then choose reboot or do a full shut down and boot from the VirtualBox interface. In the process, you will be prompted to remove the disk from the system. Of course, we are using a virtual disk image, so there is no physical disk that needs to be removed. Just click enter to continue. Now reboot . . . OH NO!!!!! "FATAL ERROR: No bootable medium found! System failed."
If you've been following along thus far, you've likely just been delivered this disturbing warning by your virtual machine upon reboot. It's a good thing we took that snapshot! Actually, this was only to be expected. Remember when you had to remove the virtual disk from the machine upon shutdown or reboot? Well, we now have to re-insert the virtual disk, that way we can reboot into Kali and move on to a full install of the operating system. So solve this "Fatal Error," with your virtual machine still running:
- Point your mouse toward the Oracle VM VirtualBox application menu on your host machine and find the Devices dropdown menu
- Select "CD/DVD devices"
- Select "Choose a Virtual CD/DVD disk file..."
- Select or navigate to your Kali .iso operating system file
- Close the virtual guest by exiting the window and powering off the machine
After the machine closes down, restart it from inside VirtualBox, it should boot into Kali from the newly inserted virtual disk.
Full Installation of Kali in VirtualBox
Now let's move on to our full installation of the Kali virtual instance. Once your system reboots into the main menu, choose the Install option and hit enter.
The installation process will begin straight away. Note that over the course of the installation, the various menus are not graphical interfaces. You cannot point and click, you have to enter info via the keyboard, and use the arrow keys to navigate. We're not going to do anything fancy here for the purposes of this simple home lab setup. In most cases the defaults will suffice. Simply follow the directions on each page. This process took about an hour on my computer. Here's the first screen:
- Choose your language.
- Select your location.
- Select your keymap.
- Enter the new host's name. It simplifies things to choose the same name you chose for your VM inside VirtualBox, but these need not be the same name. You can also always change both names later if you so wish.
- Enter a domain name. I'm going to leave it blank and hit enter.
- Enter a root password, then re-enter to confirm. These will be the credentials for the root super-user on the system. Be sure to make a note of the password you've chosen.
- Select your time zone.
- Partition Disks, select 'Guided - Use Entire Disk'. Not to worry, here 'Entire Disk' means the virtual hard drive we created upon initial setup of the VirtualBox machine. In my case, this will eventually claim up to 10GB on my harddrive, as this was the size I specified when I created the VM.
- Select disk. This is the virtual hard drive we configured earlier.
- Select partition scheme. Let's choose default, all files in one partition.
- Confirm selections, or go back if necessary.
- Select yes, to commit the changes by writing them to disk.
- Select network mirror if any. None is needed for this home lab setup.
- Select proxy if any. None is needed for this home lab setup.
- Install grub boot loader (default).
- Installation complete! Select continue.
Let the machine do its thing, and then reboot the system. Upon reboot, log into kali using 'root' as your username along with the password you chose for root during installation.
Congratulations, you now have a virtual instance of Kali Linux installed on your computer! But we're not done with our configuration of the new virtual machine just yet. We still have to update the software on the system, and then we're going to install the VirtualBox Guest Additions in order to enable full screen mode, tab completion in the terminal and so on. This process might take you another hour or so, depending on your internet connection.
Updating Kali and Prepping for Guest Additions
If your host computer is connected to the internet, you should have internet connectivity from inside your Kali VM over your NAT adapter. You can check this by opening up the bundled Ice Weasel browser and making sure you can get online. Ice Weasel can be opened by clicking the icon next to the Places drop down menu in Kali. You can also try pinging google.com or some other website from inside a terminal. You can open a terminal by clicking the terminal icon next to the Ice Weasel icon. We are going to need a working internet connection to update the system.
Let's update the system. Open a terminal in Kali and enter the following command:
apt-get updateThis will make sure Kali checks the most recent repository for any software updates. Once this process completes, enter:
apt-get dist-upgradeThis will update all software on the Kali system. Depending on your internet connection, this may take some time. The process lasted around 15 minutes for me this time around. Once that is complete, you now have a fully updated Kali virtual machine. But we are still lacking some basic functionality, so now we're going to install the VirtualBox Guest Additions.
Installing Guest Additions in VirtualBox can be tricky. To prepare the system to handle the Guest Additions, we have to run a couple more commands inside the terminal, so open up a new terminal shell and run the following series of commands, one after the other, after each completes:
apt-get cleanNotice that `uname -r` is inside backticks, not single quotes in the final command here. Yes, this matters. The backtick key should be located just above the tab key on your keyboard. This series of commands was suggested on this CrunchBang forum post, and it has yet to fail me in setting up Guest Additions for a Debian-based machine inside VirtualBox. Once this process has completed, we can now install the Guest Additions themselves.
apt-get autoclean
apt-get update
apt-get install build-essential linux-headers-`uname -r` dkms
Installing VirtualBox Guest Additions in Kali
While engaged in the Virtual system, in the Oracle VM application menu, go to the Devices dropdown menu again. Notice the "Insert Guest Additions CD" option. Select it. You will get a pop-up inside Kali asking you if you want to run the file. If it succeeds, great! If not, that's not a problem. In my experience, it has never worked off the bat, so I click cancel.
Selecting the "Insert Guest Additions CD" menu option has inserted a virtual disk into your virtual machine. The files on this disk can be found in the folder: /media/cdrom/. Confirm that they are there by navigating to this folder in the graphical file system manager or in a terminal.
To install the Guest Additions for Kali, we need to run the VBoxLinuxAdditions.run file on the Guest Additions cd. However, you cannot simply run the file from the /media/cdrom/ directory. First we need to copy it and change its permissions.
Copy the file to your Desktop from inside a terminal with the following command:
cp /media/cdrom/VBoxLinuxAdditions.run /root/DesktopYou should see a copy of the file appear on the Desktop. Change to the Desktop directory inside the terminal:
cd /root/DesktopChange the permissions on the file with the following command:
chmod 755 VBoxLinuxAdditions.runRun the additions file:
./VBoxLinuxAdditions.runSuccess? Success!
If you experience any snags along the way here, you'll have to do some trouble shooting. There is a ton of info online regarding installation of Guest Additions in VirtualBox VMs, likely in large part because the process can be tricky. Remember also, that support info for other Debian-based systems such as Ubuntu and CrunchBang will also apply to Kali in many cases. But the series of commands above has yet to fail me.
Upon successful installation of the Guest Additions, we have to shut down the machine for the updates to take effect. Reboot and log in as root again. Once the system reboots, the simplest way to confirm that the Guest Additions have been successfully installed is to see if you can maximize the window for the guest system. You should now also have code completion in the terminal, among other things. You can now eject the Guest Additions virtual CD from the Virtual cd drive. Click the Computer icon on the Desktop, then click eject under the devices menu.
We now have a fully updated fresh install of a Kali virtual machine with the VirtualBox Guest Additions installed. Let's shut down the machine, take a snapshot and switch the network adapter into bridged mode in preparation for the next tutorial.
Switching to Bridged Networking
After the VM has shut down and you've taken your snapshot, open up the settings of your new virtual system and go to the Network menu. Unless you've already chaned these settings, you should have network Adapter 1 enabled, and attached to NAT. Change the attachment to a bridged adapter. This will allow our guest to act as an independent host on our local network, rather than have its address translated by the host computer the virtualization software is running on.
Finally, the adapter Name has to connect up to the appropriate network adapter of the host machine, i.e. the one that is actually connected up to your local network, whether it is a wireless connection, an Ethernet connection, or whatever. The appropriate one should be selected by default. Click Okay.
Start up the guest. Open a terminal and ping a known website or host, or use a browser to visit a web page. If it works, CONGRATS! You're in bridged mode.
If you have no networking capability, and can't even ping other computers on your home network, let along a website. You have to do some trouble shooting. Here are some troubleshooting questions:
- Are your networking settings correct in VirtualBox?
- Is the adapter for the guest machine connected to the right interface on the host computer?
- Is Kali's /etc/network/interfaces file structured properly?
- Is the appropriate interface up as indicated by ifconfig?
- Have you tried restarting Kali's networking service?
- Is Kali's /etc/NetworkManager/NetworkManager.conf file structured properly?
- Have you tried restarting the network-manager service?
Setting up an Administrator Account
If you've followed along this far, you are now logged into your Kali VM as root, have a fully updated system, and the VirtualBox Guest Additions installed. It is not good to get into the habit of running everything in Kali as root. Best practices dictate setting up an administrator account and using sudo to run security-sensitive commands.
Create an administrator account by going to the root dropdown menu in the top right of the Kali Desktop. Then select: root => system settings -> user accounts -> create an administrator account. Create an administrator account with a separate password. Then log out, and log back in with your new admin account. Using an administrator account such as this creates a bit of extra work (ex. having to use sudo for otherwise everyday commands such as ifconfig, having do to a bit of extra configuration for applications such as Wireshark and Zenmap), but it is a good habit to get into so as to avoid becoming careless with the root account. After setting up an administrator account, shut down the machine and take another snapshot.
In part two, we will use two tools bundled in Kali to explore your home local area network. Thanks for following along. As always, leave any questions or comments below.
Subscribe to:
Posts (Atom)