Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the CCTV machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.
You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.About the Machine
CCTV is an easy-difficulty Linux machine on Hack The Box that focuses on web application exploitation, credential extraction through SQL injection, and privilege escalation through a vulnerable CCTV management platform. The machine demonstrates how weaknesses in web applications, poor credential management, and insecure service configurations can lead to full system compromise.
The attack begins with web application discovery on the target host, which reveals a SecureVision CCTV monitoring website. Further exploration exposes a ZoneMinder surveillance management interface, where default credentials allow access to the administrative dashboard. Research into the deployed software version leads to the discovery of CVE-2024-51482, a time-based blind SQL injection vulnerability in the tid parameter.
Exploiting this vulnerability enables database enumeration via SQL injection, allowing extraction of credentials stored in the zm.Users table. The retrieved password hashes are then subjected to offline password cracking, revealing a weak password for the user mark. Using these credentials, SSH access is obtained, providing an initial foothold on the system.
During post-exploitation enumeration, analysis of system services reveals that motionEye, another surveillance management application, is installed and running with root privileges. Inspection of the motionEye configuration file exposes an administrator password hash and confirms that the web interface runs only on the localhost interface. Application logs further reveal that the system actively interacts with the motionEye API through a service account.
To interact with this restricted interface, SSH local port forwarding is used to expose the motionEye web UI on the attacker machine. Authentication to the interface is then achieved using the discovered administrator credentials.
Further vulnerability research identifies CVE-2025-60787, a command injection vulnerability in motionEye ≤ 0.43.1b4. By bypassing the application's client-side input validation and injecting a malicious payload into a configuration parameter, arbitrary commands can be executed when the Motion service reloads its configuration.
After preparing a reverse shell listener, the exploit is executed to trigger the command injection, resulting in a reverse shell running as root. This provides full administrative access to the system.
With root privileges established, the root flag is retrieved from the root user’s home directory, completing the compromise. Finally, exploration of the /home directory reveals another user account, sa_mark, where the user flag is located.
Overall, CCTV highlights the risks associated with web application vulnerabilities, weak credential practices, and insecure service configurations, demonstrating how attackers can chain multiple weaknesses together to escalate from initial access to full root compromise.
The first step in owning the CCTV 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 CCTV HTB machine and I was assigned an IP address (10.129.119.247).
Host Resolution Configuration
Before beginning enumeration, I configured local host resolution for the target machine. I added an entry to my /etc/hosts file mapping the IP address 10.129.119.247 to the hostname cctv.htb.
This step ensures that my system can resolve the domain name used by the target application. Many Hack The Box machines rely on virtual host routing, meaning the web server expects requests to be made using a specific hostname rather than the raw IP address.
By adding this entry, any requests I make to cctv.htb are automatically directed to the target machine. This allows the web application to behave as intended during enumeration and exploitation.
Full TCP Port Scan
After configuring host resolution, I began network enumeration by running a full TCP port scan using Nmap. I used the -p- option to scan all 65,535 TCP ports, ensuring that no exposed services were missed.
To accelerate the scan, I included --min-rate 5000, which forces Nmap to send packets at a minimum rate of 5000 per second. I also used -sS to perform a SYN scan, a commonly used reconnaissance technique that is both fast and relatively stealthy.
The scan revealed that the target host was reachable and exposed two open ports:
- 22/tcp - SSH
- 80/tcp - HTTP
All other ports were either filtered or closed, indicating that they were either protected by a firewall or not actively listening.
Since SSH typically requires valid credentials and does not provide an immediate unauthenticated attack surface, I shifted my focus to port 80, the web service. This indicated that the primary attack surface for this machine would likely involve web application enumeration, which would be the next step in the assessment.
Web Application Discovery
After identifying port 80 as the primary attack surface during the Nmap scan, I proceeded to interact with the web service directly through my browser.
I navigated to the target IP address in the browser:
Upon loading the page, the server automatically redirected my request to the hostname http://cctv.htb/, confirming that the application relies on virtual host routing. This validated the earlier step where I configured local host resolution in /etc/hosts, allowing the domain to resolve correctly.
The landing page presented a SecureVision CCTV monitoring website, advertising surveillance services such as camera monitoring, access control systems, installation, and maintenance. The page also contained a “Staff Login” option, suggesting that the application likely provides an internal management interface for employees.
During further enumeration, I manually explored additional paths on the web server and discovered a directory associated with a surveillance management platform. I accessed the following endpoint:
This page revealed a ZoneMinder login portal, specifically ZoneMinder v1.37.63, which is an open-source video surveillance management system commonly used for CCTV deployments.
Recognizing that many default installations of ZoneMinder ship with default administrative credentials, I attempted to authenticate using the widely known defaults:
The authentication attempt was successful, granting me access to the ZoneMinder administrative dashboard. This confirmed that the system was running with unchanged default credentials, exposing the internal surveillance management interface to unauthorized access.
Gaining access to the ZoneMinder dashboard significantly expanded the attack surface, as administrative access typically provides functionality for managing cameras, executing system actions, and interacting with backend services. This made the application a promising vector for further enumeration and potential exploitation.
Vulnerability Research - ZoneMinder SQL Injection (CVE-2024-51482)
After gaining access to the ZoneMinder dashboard, I began researching known vulnerabilities affecting ZoneMinder v1.37.63. During this process, I identified CVE-2024-51482, a vulnerability affecting the ZoneMinder web interface that allows Boolean/time-based blind SQL injection.
The vulnerability occurs in the tid parameter of the following endpoint:
The tid parameter is incorporated directly into a backend MySQL query without proper sanitization, allowing attackers to inject SQL statements. Because the application does not return query results directly in the response, the vulnerability is exploitable through time-based blind SQL injection, where database responses are inferred based on server response delays.
Although the vulnerability itself does not require authentication, the endpoint requires a valid ZoneMinder session, meaning a session cookie must be supplied with the request.
Database Enumeration via SQL Injection
After confirming the time-based blind SQL injection in the tid parameter, I proceeded to extract credential data directly from the backend database using sqlmap. Since the vulnerability allowed database interaction through delayed responses, sqlmap automated the process of reconstructing query results by measuring server response times.
I executed the following command to extract user credentials from the ZoneMinder database:
In this command, I instructed sqlmap to target the vulnerable endpoint and focus specifically on the Users table inside the zm database. I requested the extraction of the Username and Password columns, which commonly contain authentication credentials.
Since the injection method was time-based, I forced sqlmap to use the T technique (--technique=T) and configured a two-second delay (--time-sec=2) for response-time comparisons. I also included the ZMSESSID session cookie, which allowed sqlmap to perform authenticated requests against the ZoneMinder application.
During execution, sqlmap resumed the previously identified injection point and confirmed that the backend database management system was MySQL, running behind an Apache 2.4.58 web server on Ubuntu Linux.
Because the attack relied on time-based inference, data extraction occurred slowly and required many HTTP requests. This resulted in numerous HTTP 500 responses, which are common when exploiting blind SQL injection against unstable endpoints. Despite these interruptions, sqlmap was able to successfully reconstruct the database contents.
After completing the extraction process, sqlmap dumped the contents of the zm.Users table and revealed three user accounts along with their associated password hashes:
The password values were stored as bcrypt hashes, indicating that ZoneMinder uses a secure password hashing scheme. These hashes would need to be cracked offline in order to recover the original plaintext passwords.
At this stage, I had successfully extracted all user credential hashes from the ZoneMinder database, providing potential authentication material that could be leveraged in the next phase of the attack.
Password Hash Cracking
After successfully dumping the ZoneMinder Users table, I obtained three bcrypt password hashes associated with the accounts superadmin, mark, and admin. Since bcrypt hashes cannot be reversed directly, the next step was to attempt offline password cracking using a wordlist attack.
First, I created a text file to store the extracted hashes so they could be processed by a password cracking tool.
Inside the file, I pasted the hashes that were previously extracted from the database:
With the hashes stored locally, I used John the Ripper to perform a dictionary-based password cracking attempt using the widely used rockyou.txt wordlist.
John automatically detected that the hashes were using the bcrypt (Blowfish) algorithm and began testing candidate passwords from the wordlist against the hashes.
During the cracking process, John successfully recovered one of the passwords:
This indicated that one of the ZoneMinder user accounts was protected with a weak and commonly used password, making it vulnerable to a simple dictionary attack.
At this stage, I had recovered the plaintext password opensesame, which could now potentially be used to authenticate to other services on the target system, such as SSH or additional application accounts, in the next phase of the assessment.
Initial Access - SSH Authentication as Mark
After recovering the plaintext password opensesame from the cracked bcrypt hash, I attempted to determine whether the credential could be reused to access other services on the target system. Since port 22 (SSH) had been identified earlier during the Nmap scan, SSH authentication was a natural next step.
I attempted to authenticate to the host as the user mark using the recovered password.
Once prompted for the password, I entered the recovered credential opensesame, which successfully authenticated me to the system.
With a shell established on the target machine, I began performing initial filesystem enumeration within the user’s home directory.
The directory appeared empty at first glance, so I listed all files, including hidden ones.
This revealed several standard user configuration files such as .bashrc, .profile, and .bash_logout, along with directories like .cache, .gnupg, and .ssh. One notable observation was that the .bash_history file was symbolically linked to /dev/null, indicating that command history logging had been intentionally disabled for this account. This is sometimes done to prevent activity tracking on the system.
At this stage, I had successfully obtained initial shell access as the user mark, providing a foothold on the system and allowing me to begin post-exploitation enumeration to identify potential privilege escalation opportunities.
Post-Exploitation Enumeration - motionEye Service Analysis
After obtaining a shell as mark, I began performing local enumeration to identify running services and potential privilege escalation vectors. Since the machine appeared to be related to a CCTV infrastructure, I focused on configuration files and services that might be responsible for video monitoring.
During this process, I discovered a systemd service related to motionEye, a web-based surveillance management system.
The service configuration revealed that the motionEye server runs as the root user, which immediately caught my attention.
Running a service as root significantly increases the attack surface because any vulnerability within the application or its configuration could potentially lead to privilege escalation to root. The service also starts the motionEye server using the configuration file located at /etc/motioneye/motioneye.conf, making it a logical next target for inspection.
Inspecting motionEye Configuration
To gather additional information, I opened the motionEye configuration file.
Inside the configuration file, I discovered commented configuration parameters that included an administrator username and password hash.
The value associated with admin_password appeared to be a SHA-1 hash, which likely corresponds to the administrative password used by the motionEye interface. The configuration also indicated that the web control interface runs on port 7999, though it is restricted to the local interface:
This suggests that the motionEye management interface is not directly exposed externally and can only be accessed from the local system. However, since I already had shell access as mark, interacting with this service locally remained a viable option.
Investigating Application Logs
While continuing to explore the filesystem, I discovered a log file related to the video management system.
The log entries showed repeated API interactions performed by an account named sa_mark:
These entries indicated that the sa_mark account is actively interacting with the motionEye API, repeatedly issuing commands such as status and disk-info. The repeated authorization messages confirm that the account is used to interact with the service programmatically.
Key Observations
From this enumeration, I identified several important findings:
- The motionEye service (version 0.43.1b4) is configured to run as the root user, which could potentially allow privilege escalation if the service is compromised.
- The administrator password hash for the motionEye interface is stored in
/etc/motioneye/motion.conf. - The motionEye web control interface runs locally on port 7999, suggesting it may only be accessible from the system itself.
- Log files show that a service account named
sa_markregularly communicates with the motionEye API, indicating the service is actively used by system processes.
These discoveries suggested that the motionEye service could play a key role in the privilege escalation path, so I continued investigating how the service and its API could potentially be abused to gain higher privileges on the system.
Accessing the motionEye Web Interface via SSH Port Forwarding
During the enumeration of the motionEye configuration, I observed that the web control interface was configured to listen only on the local interface. This was confirmed in the configuration file where the webcontrol_localhost option was enabled. As a result, the motionEye web UI was not directly accessible from the network, even though it was running on the target system.
To interact with this internal service from my attacking machine, I used SSH local port forwarding. This technique allows traffic sent to a local port on the attacker machine to be forwarded through the SSH connection and delivered to a specified port on the remote host.
I established a new SSH connection to the target while forwarding the motionEye web interface port:
With this command, I instructed SSH to bind local port 8765 on my machine and forward any traffic received on that port to 127.0.0.1:8765 on the target system. Since the motionEye interface was restricted to the localhost interface, this tunnel allowed me to access the internal web service externally through the encrypted SSH connection.
After authenticating with the previously recovered credentials for the mark user, the SSH session was successfully established and the port forwarding tunnel became active.
Once the tunnel was in place, any requests sent to:
on my attacker machine would be transparently forwarded to the motionEye web interface running on the target system. This allowed me to interact with the otherwise restricted service as if I were accessing it locally on the host itself.
With the internal motionEye interface now reachable through the SSH tunnel, I proceeded to examine the web UI for potential misconfigurations or vulnerabilities that could lead to privilege escalation, especially considering that the service itself was configured to run with root privileges.
Accessing the motionEye Web Interface
With the SSH tunnel established, I proceeded to access the motionEye web interface from my attacker machine. Since the tunnel forwarded the remote service to my local system, I navigated to the following address in my browser:
The page loaded the motionEye login interface, confirming that the SSH port forwarding had successfully exposed the previously restricted internal service. The interface presented a standard authentication prompt requesting a username and password.
Earlier during local enumeration, I had identified an administrator credential within the motionEye configuration file located at /etc/motioneye/motion.conf. The configuration contained the following values:
Using this information, I attempted to authenticate to the motionEye interface with the admin username and the discovered password value.
The authentication attempt was successful, granting me access to the motionEye administrative dashboard.
This confirmed that the password stored in the configuration file was accepted directly by the application for authentication. Since the motionEye service runs as the root user, administrative access to this interface could potentially allow interaction with system-level functionality, making it a promising avenue for further privilege escalation.
Privilege Escalation - motionEye Command Injection (CVE-2025-60787)
After gaining administrative access to the motionEye web interface, I began researching vulnerabilities affecting motionEye ≤ 0.43.1b4. During this process, I identified CVE-2025-60787, a command injection vulnerability that occurs due to improper handling of user-supplied configuration values.
The issue arises because certain configuration fields such as image_file_name are written directly into the underlying Motion configuration file without proper sanitization. When the Motion service reloads its configuration, these values are interpreted by the shell, allowing arbitrary command execution. Since the motionEye service runs as root, any injected command is executed with root privileges.
Bypassing Client-Side Input Validation
Before exploiting the vulnerability, I needed to bypass input validation implemented in the motionEye web interface. The application performs validation entirely on the client side using JavaScript, meaning it can be bypassed directly from the browser.
I opened the browser developer console (F12 → Console) and overrode the validation function with the following statement:
This modification forces the validation function to always return true, effectively disabling all frontend input restrictions and allowing arbitrary values to be submitted through the interface.
Preparing the Exploit
To automate the exploitation process, I used a publicly available proof-of-concept exploit for CVE-2025-60787.
I first cloned the exploit repository to my attacker machine:
After cloning the repository, I navigated into the directory to inspect its contents:
The repository contained a Python exploit script along with documentation describing the vulnerability.
Preparing a Reverse Shell Listener
Since the exploit would execute commands on the target system, I prepared a Netcat listener on my attacker machine to receive a reverse shell.
This command instructed Netcat to listen on TCP port 4444 for incoming connections.
Executing the Exploit
With the listener running, I executed the exploit script to trigger the command injection and spawn a reverse shell back to my attacker machine.
The script authenticated to the motionEye web interface using the previously discovered admin credentials and began interacting with the API. It then enumerated the available cameras and selected the first configured camera as the target for payload injection.
During execution, the exploit modified a camera configuration parameter and inserted a reverse shell payload into the Motion configuration file. When the service processed the modified configuration, the injected command executed automatically.
The script confirmed successful payload delivery with the message:
Obtaining a Root Shell
Shortly after triggering the exploit, my Netcat listener received an incoming connection from the target system.
The connection provided a shell running as root, confirming that the injected payload executed with root privileges through the motionEye service.
At this stage, I had successfully escalated privileges from the mark user to root, achieving full control over the target system.
Root Access and Flag Retrieval
To verify the privilege level of the shell, I executed the id command.
The output confirmed that the shell was running with root privileges:
With confirmed administrative access, I navigated to the root user's home directory to search for the final flag.
I then listed the contents of the directory to identify any relevant files.
The listing revealed several files and directories, including the expected root.txt flag file.
Finally, I read the contents of the flag file.
The file contained the root flag, confirming full compromise of the system:
Hurray!!! I got the root flag!!!
At this point, I had successfully escalated privileges from an initial web application foothold to full root access, completing the compromise of the target machine.
Retrieving the User Flag
After obtaining root access, I continued exploring the system to locate the user flag associated with the machine. Although I already had full administrative control, I wanted to identify where the standard user flag was stored.
I began by navigating to the /home directory, which typically contains the home directories for user accounts on Linux systems.
I then listed the available user directories.
The output revealed two user accounts present on the system:
Earlier in the enumeration process, I had already authenticated to the system as mark, so I decided to investigate the sa_mark directory to see whether it contained additional artifacts or flags.
Once inside the directory, I listed its contents.
The directory contained two files:
The presence of the user.txt file indicated that this directory contained the user flag for the machine. I opened the file to read its contents.
The file revealed the user flag:
Hurray!!! I got the user flag.
With both the user flag and the root flag successfully retrieved, the compromise of the system was complete.
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 ☕
Comment below the machine you want me to drop next!!! You can buy me a $25 coffee for a year premium subscription with a weekly release on every active machine [you will get the HTB write ups two days after each machines are released]
Keywords:
cctv htb walkthrough
cctv htb write up
cctv hack the box walkthrough
cctv hack the box writeup
cctv.htb
hackthebox cctv
CCTV htb easy linux cctv.htb write up walkthrough
owned cctv from hack the box
eighteen htb writeup
eighteen htb walkthrough
eighteen htb
htb eighteen writeup
eighteen writeup
htb eighteen walkthrough
htb eighteen
hackthebox eighteen writeup
eighteen walkthrough
eighteen writeup htb
eighteen hackthebox writeup
gavel htb
eighteen hack the box
eighteen hackthebox
hack the box eighteen
hackthebox eighteen
eighteen walkthrough htb
gavel htb writeup
gavel writeup
htb gavel writeup
eighteen hack the box walkthrough
eighteen.htb writeup
hackthebox eighteen walkthrough
eighteen.htb
eighteen hackthebox walkthrough
dc01.eighteen.htb
rooted cctv on hack the box
hack the box eighteen walkthrough
eighteen htb machine
htb "eighteen" writeup
"eighteen.htb"
eighteen write up
htb gavel walkthrough
hack the box eighteen writeup
eighteen htb write up
htb gavel
hackthebox gavel writeup
"eighteen" hackthebox writeup
htb eighteen write up
eighteen machine htb
gavel htb walkthrough
"overwatch.htb"
"eighteen" htb writeup
eighteen hack the box writeup
signed htb
gavel hackthebox writeup
eighteen.htb walkthrough
gavel htb write up
"eighteen" htb walkthrough
htb "eighteen"
htb signed
gavel.htb
gavel hack the box
gavel walkthrough
overwatch htb walkthrough
eighteen writeup hackthebox
pterodactyl htb walkthrough
gavel writeup htb
writeup eighteen
hackthebox "eighteen"
"eighteen.htb" writeup
cctv htb machine
CCTV HTB
gavel hackthebox walkthrough
signed.htb
"giveback" htb writeup
"monitorsfour"
htb gavel sql injection payload inventory.php
htb gavel walkthrough sql injection payload inventory.php
hack the box gavel sql injection payload inventory.php
overwatch htb writeup
hack the box gavel sql injection payload 2025
hack the box gavel sql injection payload inventory.php 2025
htb machine editor xwiki simplistcode pro
htb gavel walkthrough sql injection inventory.php
htb gavel walkthrough sql injection inventory.php payload
htb gavel sql injection payload inventory.php sort
hack the box gavel walkthrough sql injection payload inventory.php
hack the box gavel walkthrough sql injection payload
gavel.htb/admin.php
nanocorp htb
"gavel.htb"
nanocorp walkthrough
htb gavel walkthrough pdo injection sort parameter
htb gavel walkthrough sql injection payload
eighteen.htb:5985
hack the box eighteen machine walkthrough
gavel 2.0 exploit
htb overwatch writeup
hackthebox overwatch writeup
"0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133" password
htb eighteen machine walkthrough
gavel.htb/includes
hercules htb writeup
nanocorp htb writeup
editor htb
htb overwatch walkthrough
gavel-util
signed htb walkthrough
hack the box gavel sql injection inventory.php payload 2025
"hack the box" "eighteen" writeup
hack the box gavel walkthrough pdo injection
monitorsfour.htb:5985
eighteen htb github
"eighteen" htb
hercules htb walkthrough
guardian htb writeup
overwatch writeup htb
pterodactyl htb writeup
htb eighteen admin password iloveyou1
gavel.htb/rules
htb eighteen privilege escalation walkthrough
editor htb walkthrough
hack the box gavel
hercules htb
gavel hackthebox
overwatch hack the box writeup
pterodactyl hack the box walkthrough
nanocorp writeup
conversor htb walkthrough
htb monitorsfour
"browsed" htb writeup
hackthebox hercules
htb browsed
"dc01.eighteen.htb"
ina2we6harj2gaw!
hackthebox gavel sql injection payload inventory.php
hackthebox "eighteen" writeup
hack the box gavel sql injection payload inventory.php sort
hackthebox eighteen machine walkthrough
"browsed.htb"
overwatch.htb:5985
"eighteen" hack the box writeup
gavel writeup hackthebox
gavel.htb/.git
giveback walkthrough
hackthebox gavel walkthrough
htb guardian writeup
hackthebox gavel
htb editor writeup
"overwatch" htb writeup
nanocorp htb walkthrough
overwatch hackthebox writeup
overwatch.htb writeup
hackthebox nanocorp writeup
overwatch writeup hackthebox
giveback htb writeup
htb nanocorp writeup
htb pterodactyl
htb artificial
htb topology writeup
topology htb writeup
"0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133"
signed walkthrough
htb gavel write up
"giveback.htb"
editor.htb:8080
htb 18
giveback htb
hackthebox eighteen machine
hercules writeup
wiki.editor.htb
monitorsfour.htb/robots.txt
monitorsfour htb writeup
editor.htb
conversor walkthrough
hackthebox pterodactyl walkthrough
htb edit
hack the box eighteen machine
overwatch walkthrough htb
giveback htb walkthrough
pterodactyl hack the box
browsed htb
htb hercules writeup
pterodactyl.htb walkthrough
overwatch hack the box walkthrough
planning htb
monitorsfour htb walkthrough
overwatch hackthebox
hackthebox monitorsfour
htb nanocorp
htb nanocorp walkthrough
nanocorp hackthebox
fluffy htb
htb overwatch
pterodactyl writeup htb
pterodactyl hackthebox walkthrough
overwatch htb
artificial htb
browsed htb write up
overwatch hackthebox walkthrough
pterodactyl htb
hackthebox pterodactyl
pterodactyl hackthebox writeup
htb pterodactyl writeup
browsed htb writeup
hackthebox nanocorp
pterodactyl walkthrough htb
htb planning
browsed htb walkthrough
browsed walkthrough
facts htb walkthrough
htb facts writeup
CCTV HTB - Complete Writeup
HackTheBox Season 10 CCTV
Hack The Box CCTV
Walkthroughs HTB season 10 machines Pterodactyl WingData Interpreter Pirate CCTV Facts
CCTV HTB - All Scripts
CCTV----HTB
I just solved CCTV on Hack The Box!
Pwned HTB Season 10 | Machine 6 | CCTV
rooted CCTV machine from Hack the Box season 10
#hackthebox #htbseason10 #cybersecurity #redteam #infosec
Mastering CCTV from HackTheBox
Hack The Box - Season 10 HTB CCTV Writeup
CCTV Linux machine ZoneMinder CCTV
HTB: CCTV Writeup
HackTheBox Season 10 CCTV
WEB01.pirate.htb
pirate.htb
pirate htb write up
pirate htb walkthrough
pirate hack the box write up
pirate hackthebox
0 Comments