About the Machine
WingData is an easy Linux machine on Hack The Box that demonstrates a full attack chain from unauthenticated service exploitation to root privilege escalation. The initial foothold was obtained by enumerating the web application and discovering a Wing FTP Server instance vulnerable to CVE-2025-47812, which allowed unauthenticated remote code execution and provided a shell as the wingftp service account.
Post-exploitation enumeration revealed stored user credential hashes within Wing FTP Server configuration files. After cracking the hash offline, I reused the recovered password to gain SSH access as a legitimate system user, wacky.
Further privilege escalation enumeration identified a misconfigured sudo permission allowing execution of a root-owned backup restoration script. By exploiting insecure tar archive extraction behavior (CVE-2025-4517), I was able to inject a malicious sudoers entry and escalate privileges to root.
This machine highlights practical skills in service enumeration, vulnerability research, remote code execution, credential harvesting and cracking, lateral movement, and privilege escalation through insecure backup handling mechanisms.
The first step in owning the WingData machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the WingData machine and I was assigned an IP address (10.129.6.225).
Nmap Enumeration
I began the enumeration process by running an Nmap scan to identify open ports, running services, and potential entry points on the target machine.
The scan confirmed that the host was reachable and revealed two open TCP ports: 22 (SSH) and 80 (HTTP), while the remaining ports were filtered, indicating that a firewall was actively restricting access to other services.
Port 22 was running OpenSSH 9.2p1 on Debian 12, confirming that the target was a Linux system. Since SSH provides remote system access, this service could potentially be used later if valid credentials were discovered during enumeration.
Port 80 was running Apache HTTP Server 2.4.66, also on Debian. Nmap revealed that the web server was redirecting requests to the hostname:
This indicated that the application was configured to use a virtual host, meaning that accessing the service via the IP address alone would not display the intended content. Based on this finding, I identified wingdata.htb as a valid domain associated with the target, which would need to be added to my local /etc/hosts file in order to properly interact with the web application.
The scan also confirmed that the target was running a Linux-based operating system, consistent with the observed SSH and Apache service versions.
Based on these results, the web service on port 80 presented the most promising attack surface, and I proceeded with web enumeration against the wingdata.htb virtual host.
Web Enumeration
After identifying the web service running on port 80 during the Nmap scan, I navigated to the target IP address using my browser to observe the application's behavior.
When I visited the following URL:
I was automatically redirected to:
This confirmed that the web application was configured to use a virtual host, and proper interaction with the application required resolving the wingdata.htb hostname locally.
The homepage presented a professional-looking website for a company called Wing Data Solutions, which appeared to offer secure file-sharing services. The navigation bar contained several sections, including Home, About Us, Services, Contact Us, and a Client Portal.
During manual enumeration of the application’s functionality, I clicked on the Client Portal button and observed that it redirected to a different subdomain:
This discovery was particularly interesting, as it revealed the existence of an additional subdomain that was likely hosting a separate service. Since this hostname was not yet resolvable from my attacking machine, I needed to add both discovered domains to my local /etc/hosts file to ensure proper name resolution.
To achieve this, I ran the following command:
This command manually mapped the target IP address to both wingdata.htb and ftp.wingdata.htb, allowing my system to correctly resolve and interact with both the main web application and the newly discovered subdomain.
The discovery of the ftp.wingdata.htb subdomain suggested the presence of an FTP-related service or file management portal, which aligned with the company's advertised file-sharing functionality. Since additional subdomains often expose new attack surfaces in CTF environments, I proceeded to further enumerate this newly discovered host to identify potential entry points.
Directory Enumeration
After confirming that the wingdata.htb virtual host was accessible, I proceeded to enumerate hidden directories and files on the web server. Web applications often expose sensitive endpoints, administrative panels, or development resources that are not directly linked on the main page. To identify such content, I used ffuf, a fast web fuzzing tool, along with a common directory wordlist.
In this command, I instructed ffuf to fuzz the FUZZ keyword in the URL using entries from the common.txt wordlist. I configured the scan to display responses with HTTP status codes 200 (OK), 301 (Redirect), 302 (Redirect), and 403 (Forbidden), as these responses often indicate the existence of valid resources. I also increased the number of threads to 40 to improve scanning speed.
The scan revealed several interesting directories and files.
The /assets directory returned a 301 redirect, confirming its existence. This directory typically contains static resources such as images, stylesheets, or JavaScript files used by the application frontend.
Similarly, the /vendor directory was also discovered with a 301 redirect response. This directory is commonly associated with dependency management systems such as Composer in PHP applications. The presence of a vendor directory strongly suggested that the application was built using a PHP framework or included third-party libraries, which could potentially contain vulnerable components.
The scan also identified several sensitive files, including .htaccess, .htpasswd, and .hta, all of which returned 403 Forbidden responses. This indicated that the files existed on the server but were access-restricted. These files are used by Apache for configuration and authentication purposes, and their presence confirmed that access controls were actively enforced.
Additionally, the /server-status endpoint was discovered but returned a 403 Forbidden response. This endpoint is part of Apache’s mod_status module and can sometimes expose detailed information about the web server, including active connections and server activity, if misconfigured.
The discovery of these directories and restricted files confirmed that the server was running a structured web application with backend dependencies. In particular, the presence of the /vendor directory suggested that the application relied on external libraries, making dependency enumeration and vulnerability research a promising next step in identifying potential attack vectors.
FTP Web Client Enumeration
After discovering the ftp.wingdata.htb subdomain during web enumeration, I navigated to it using my browser to investigate the service further.
Upon visiting the page, I was presented with a login interface for the Wing FTP Server Web Client, which appeared to provide browser-based access to the FTP service. The portal required an account name and password, indicating that authenticated users could access and manage files directly through this interface.
While analyzing the page, I observed a version disclosure at the bottom of the login portal, which revealed the exact software and version in use:
This information was particularly valuable, as identifying the precise version of a service allows for targeted vulnerability research. Since outdated or vulnerable software often provides a direct path to exploitation, I proceeded to search publicly available vulnerability databases for known issues affecting this version.
During my research, I discovered that Wing FTP Server version 7.4.3 is vulnerable to CVE-2025-47812, which allows unauthenticated remote code execution. This vulnerability indicated that it might be possible to execute arbitrary commands on the target system without requiring valid login credentials.
The presence of this vulnerable service significantly increased the attack surface and presented a promising entry point for initial access. Since the vulnerability allowed unauthenticated exploitation, I focused my efforts on identifying publicly available proof-of-concept exploits and understanding the vulnerability’s exploitation requirements in order to gain remote code execution on the target system.
Exploit Acquisition
After identifying that the target was running Wing FTP Server v7.4.3, which is vulnerable to CVE-2025-47812 (Unauthenticated Remote Code Execution), I proceeded to search for publicly available proof-of-concept (PoC) exploits that could be used to leverage this vulnerability.
During my research, I found a GitHub repository containing a working exploit for this CVE. To obtain the exploit code, I cloned the repository to my local machine using the following command:
The cloning process completed successfully, downloading the exploit files into a directory named CVE-2025-47812-poc. This repository contained the necessary resources to exploit the Wing FTP Server vulnerability.
Next, I navigated into the cloned directory to inspect its contents:
The directory contained the following files:
CVE-2025-47812.py- the main exploit script designed to trigger the remote code execution vulnerability.README.md- documentation providing usage instructions and technical details about the exploit.LICENSE- the licensing information for the repository.2025-07-01_18-22.png- a screenshot demonstrating successful exploitation.
The presence of a dedicated Python exploit script confirmed that the vulnerability could be exploited in a straightforward manner. Since this vulnerability allowed unauthenticated remote code execution, the exploit script presented a viable path to gaining initial access to the target system.
Exploitation - CVE-2025-47812 Remote Code Execution
After acquiring the proof-of-concept exploit for CVE-2025-47812, I prepared my environment to receive a reverse shell connection from the target system.
First, I set up a netcat listener on my attacking machine to listen for incoming connections on port 5555:
This command configured netcat to listen verbosely (-v), without DNS resolution (-n), on port 5555 (-p 5555). This would allow me to capture any reverse shell connection initiated by the exploit.
With the listener ready, I navigated to the exploit directory and executed the Python proof-of-concept script, specifying the target URL and a reverse shell payload:
In this command:
- The
-uflag specified the target Wing FTP Server URL. - The
-cflag defined the command to execute on the target, which initiated a reverse shell back to my attacking machine. - The
-vflag enabled verbose output, allowing me to monitor the exploitation process.
The exploit script sent a crafted POST request to the /loginok.html endpoint using the anonymous user and successfully extracted a valid session UID. It then attempted to trigger command execution via a request to /dir.html. Although the script reported a timeout during the final request, this behavior was expected, as the server was likely busy executing the reverse shell payload.
Shortly afterward, my netcat listener received an incoming connection from the target:
This confirmed that the exploit had successfully executed and established a reverse shell.
To verify the level of access obtained, I ran the id command:
The output showed that I had obtained a shell as the wingftp user:
This confirmed successful initial access to the target system through exploitation of the vulnerable Wing FTP Server.
To improve shell usability, I upgraded the shell to a fully interactive TTY using Python:
This provided a more stable and interactive shell environment, allowing for easier command execution.
With interactive access established, I began enumerating the system. I navigated to the root directory and listed its contents to better understand the system structure:
The output confirmed that I was operating within a Debian-based Linux system, with standard directories such as /home, /opt, /etc, and /root. The presence of /opt/wftpserver aligned with the Wing FTP Server installation, confirming that the exploitation path had successfully compromised the FTP service.
Post-Exploitation Enumeration - User Discovery and Credential Extraction
After gaining initial access as the wingftp user, I began enumerating the system to identify other users and potential privilege escalation opportunities.
I first navigated to the /home directory to check for additional user accounts:
The output revealed two entries: wingftp and another user named wacky. Since user home directories often contain sensitive files such as SSH keys, configuration files, or user flags, I attempted to access the wacky home directory:
However, access was denied, indicating that the wingftp user did not have sufficient permissions to access this directory. This suggested that wacky was likely a separate system user and a potential target for lateral movement.
Since the system was running Wing FTP Server, I shifted my focus toward its installation directory to look for configuration files and stored credentials. Based on the directory structure observed earlier, I navigated to the Wing FTP Server user configuration directory:
This directory contained several XML files corresponding to FTP user accounts:
These files appeared to store user account configurations, which often include authentication information. Since the wacky account was of particular interest, I opened its configuration file:
The XML file contained detailed account configuration data, including the username and an associated password hash:
This confirmed that Wing FTP Server stored user credentials locally in XML configuration files. Although the password was stored as a hash rather than plaintext, it represented a valuable target for offline cracking or credential reuse attacks.
Additionally, the presence of multiple user configuration files suggested that other valid accounts existed on the system, which could potentially be leveraged for further access.
At this stage, I had successfully identified a valid system user (wacky) and extracted the associated password hash from the Wing FTP Server configuration files. Since this user also had a home directory on the system, obtaining the corresponding plaintext password could allow me to authenticate as wacky and potentially gain access to additional sensitive files or escalate privileges further.
Credential Cracking - Recovering the Wacky User Password
After extracting the password hash for the wacky user from the Wing FTP Server configuration file, I proceeded to crack it offline in order to recover the plaintext password.
First, I created a file to store the hash in a format compatible with Hashcat:
Inside this file, I added the extracted hash along with the identifier WingFTP, which corresponds to the Wing FTP Server hashing format:
With the hash prepared, I used Hashcat to attempt cracking it using the popular rockyou.txt wordlist, which contains millions of commonly used passwords:
In this command:
- The
-m 1410flag specifies the hash mode for Wing FTP Server hashes. wacky_password.txtcontains the extracted hash./usr/share/wordlists/rockyou.txtis the password wordlist used for dictionary-based cracking.
Hashcat loaded the hash and began testing candidate passwords from the wordlist. After processing the keyspace, Hashcat successfully recovered the plaintext password:
The recovered password for the wacky user was:
This was a significant finding, as it provided valid credentials for the wacky account. Since this user also had a home directory on the system and was likely a legitimate system user, these credentials could potentially be reused to gain direct access via SSH or switch users locally.
With valid credentials successfully obtained, I proceeded to authenticate as the wacky user to continue enumeration and advance toward privilege escalation.
Lateral Movement - SSH Access as Wacky
After successfully cracking the password hash for the wacky user and recovering the plaintext password, I attempted to authenticate to the system via SSH using these credentials.
To automate the login process and avoid interactive password prompts, I used sshpass to supply the recovered password directly:
The sshpass utility allowed me to authenticate non-interactively by passing the plaintext password. I also disabled strict host key checking to prevent SSH from prompting for host verification confirmation during the first connection.
The authentication was successful, and I gained shell access to the target system as the wacky user:
This confirmed that the recovered credentials were valid system credentials and not limited to FTP access. Successfully authenticating via SSH provided a more stable and fully interactive shell under a legitimate user account.
Once logged in, I enumerated the contents of the user's home directory:
The output revealed the presence of the user.txt file, which typically contains the user flag in Hack The Box machines. I proceeded to read its contents:
The file contained the user flag:
Hurray!!! I got the user flag
This confirmed successful lateral movement from the compromised wingftp service account to a legitimate system user. At this stage, I had obtained the user flag and established a more privileged foothold on the system, allowing me to continue enumeration in search of privilege escalation vectors to obtain root access.
Privilege Escalation Enumeration - Sudo Permissions
After successfully authenticating as the wacky user, I began performing standard privilege escalation enumeration to identify any misconfigurations that could allow me to elevate my privileges. One of the most important checks at this stage was reviewing the sudo permissions assigned to the current user.
To do this, I ran the following command:
The output revealed the sudo configuration for the wacky user:
This indicated that the wacky user was allowed to execute the Python interpreter as the root user, specifically to run the script located at:
Importantly, this command could be executed without requiring a password due to the NOPASSWD directive. Additionally, the presence of the wildcard (*) at the end of the command meant that I could supply arbitrary arguments to the script.
This finding was highly significant, as it confirmed that I had the ability to execute a root-owned Python script with full root privileges. Since Python scripts often interact with the filesystem, process user input, or perform file extraction operations, any improper handling of input or file paths within the script could potentially be abused to execute arbitrary commands or modify privileged system files.
Based on this discovery, the backup restore script located at /opt/backup_clients/restore_backup_clients.py became the primary target for further analysis, as exploiting it could provide a direct path to obtaining root access on the system.
Privilege Escalation Enumeration - Backup Restore Script Analysis
After discovering that the wacky user could execute the backup restore script as root via sudo, I proceeded to inspect the script to understand its functionality and identify potential weaknesses that could be abused for privilege escalation.
I viewed the contents of the script using the following command:
The script was a Python-based backup restoration utility designed to extract client backup archives into a staging directory. From the source code, I observed that the script restored .tar backup files located in the following directory:
The extracted contents were placed into a staging directory under:
The script required two arguments:
-bor--backup: specifies the backup filename, which must follow the formatbackup_<client_id>.tar-ror--restore-dir: specifies the restore directory name, which must begin withrestore_and contain only alphanumeric characters and underscores
The script implemented validation checks to ensure that backup filenames followed a strict naming convention and that restore directory names met format requirements. These validation mechanisms appeared to be designed to prevent arbitrary file access or command injection through input parameters.
However, the most important functionality occurred during the extraction process:
This line instructed Python to extract the contents of the specified tar archive into the staging directory. Critically, this operation was performed with root privileges, since the script was executed via sudo.
This immediately presented a potential privilege escalation vector. When tar archives are extracted, they may contain symbolic links or specially crafted file paths that could result in files being written outside the intended directory. If not properly handled, this could allow overwriting sensitive system files or placing malicious files in privileged locations.
Although the script used the filter="data" parameter, which provides some level of protection, the extraction was still performed automatically and with root privileges. This made the script a strong candidate for abuse via a crafted tar archive containing malicious file structures.
Since I had permission to run this script as root, the next logical step was to create a specially crafted backup archive that could be processed by this script and leveraged to escalate privileges to root.
Privilege Escalation - Exploit Transfer and Preparation
After identifying that the wacky user could execute the backup restore script as root, I began preparing an exploit to leverage this misconfiguration. Since the exploit was not present on the target system, I needed to transfer it from my attacking machine to the compromised host.
First, on the target machine, I navigated to the /tmp directory, which is commonly used for temporary file storage and is writable by all users:
Next, on my Kali Linux machine, I cloned the publicly available proof-of-concept repository for CVE-2025-4517, which targets the vulnerable backup restore functionality used on the system:
The cloning process completed successfully, and I verified the contents of the repository:
The repository contained the exploit script CVE-2025-4517-POC.py along with a README file. This Python script was designed to abuse the backup restore functionality to escalate privileges.
To transfer the exploit script to the target system, I started a simple HTTP server on my Kali machine using Python:
This command launched a web server on port 80, allowing the target system to download files directly from my machine.
Returning to the shell on the target system as the wacky user, I used wget to download the exploit script from my attacking machine:
The download completed successfully, and the file was saved locally on the target system. On my Kali machine, I confirmed that the target had successfully retrieved the file, as the HTTP server logged the incoming request:
This confirmed that the exploit script had been successfully transferred from my attacking machine to the compromised system.
With the exploit now available locally on the target, I was ready to execute it and leverage the vulnerable backup restore functionality to escalate privileges to root.
Privilege Escalation - Exploiting CVE-2025-4517 and Obtaining Root
After successfully transferring the exploit script to the target system, I verified its presence in the /tmp directory:
The output confirmed that the exploit script CVE-2025-4517-POC.py was present and owned by the wacky user. Since /tmp is a world-writable directory, it was an ideal location to stage and execute the exploit.
With the exploit script in place, I executed it using Python:
The script began by creating a malicious tar archive designed to exploit a vulnerability in the backup restoration script. Specifically, it abused improper handling of symbolic links and hardlinks during archive extraction.
The exploit performed several automated steps:
- It created a nested directory structure to facilitate path traversal.
- It constructed a chain of symbolic links to escape the intended extraction directory.
- It created a hardlink targeting the sensitive system file
/etc/sudoers. - It injected a malicious sudoers entry granting full sudo privileges to the
wackyuser. - It deployed the crafted tar archive into the backup directory as
backup_9999.tar. - It then triggered the vulnerable restore script, which extracted the archive as root.
The restore script executed successfully and extracted the malicious archive:
As a result, the exploit successfully modified the /etc/sudoers file and added the following entry:
This granted the wacky user unrestricted sudo privileges.
The exploit script then prompted to spawn a root shell. I confirmed and executed the suggested command:
This immediately elevated my privileges, providing a root shell:
This confirmed that privilege escalation was successful and that I now had full administrative control over the system.
To complete the machine, I navigated to the root user’s home directory and retrieved the root flag:
The contents of the file revealed the root flag:
Hurray!!! I got the root flag.
This marked the successful completion of the privilege escalation phase and full compromise of the target system.
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Found this walkthrough helpful?
Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
wingdata htb write up
wingdata htb walkthrough
wingdata hack the box write up
wingdata hack the box walkthrough
owned wingdata from hack the box
pwned wingdata
hackthebox wingdata
wingdata.htb
ftp.wingdata.htb
HTB Season10
HTB-WingData
WingData
Hackthebox CTF writeups
Wingdata Htb Walkthrough
HTB Season 10
HTB Writeup - Interpreter
Week 3 Season 10 HackTheBox - WingData
HTB writeups
Owned WingData from Hack The Box!
Wingdata (HTB) write-up
HTB(Hack The Box)
WingData! (Linux | Easy)
Rooted WingData on HTB
WingData has been Pwned
YouhavesolvedWingData! have solved WingData! Congratulation
WingData is a Easy-difficulty Linux machine released as part of HTB season 10
Completed HTB WingData
Successfully pwned WingData Machine from Hack The Box
Exploit for CVE-2025-4517
CVE-2025-4517 Exploit - WingData HTB
WingData HTB Season 10 Machine created by WackyH4cker
HackTheBox 'WingData' machine walkthrough
HTB walkthroughs
#HackTheBox #HTB #CyberSecurity #EthicalHacking #InfoSec #PenTesting
WingData Machine | HackTheBox
WingD: exploit Wing FTP Server's RCE vulnerability, leverage CVE-2025-47812
AzureADTrent/CVE-2025-4517-POC-HTB-WingData
Rooted: WingData [HTB Season 10] Just finished WingData, a solid Linux box from the current Hack The Box season
Privilege Escalation script for Wingdata
WingData, an HTB Season 10 Machine
HTB Writeup - WingData
CVE-2025-4517 Exploit - WingData HTB
Exploit for CVE-2025-4517
HTB: WingData Writeup
Detailed writeup of Season 10 Hack The Box WingData machine
0 Comments